perm filename COMSCH.2[SCH,LSP] blob
sn#873959 filedate 1989-06-01 generic text, type C, neo UTF8
COMMENT ⊗ VALID 01680 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00274 00002
C00275 00003 ∂26-Apr-86 0738 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU The generality of define
C00277 00004 ∂26-Apr-86 1816 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu variata
C00283 00005 ∂27-Apr-86 1455 @MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA variata
C00292 00006 ∂27-Apr-86 1607 @MC.LCS.MIT.EDU:dcj%jacksun@SUN.COM SCOOPS, and GNU support question
C00295 00007 ∂28-Apr-86 1155 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: variata
C00301 00008 ∂28-Apr-86 1340 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: SCOOPS, and GNU support question
C00304 00009 ∂29-Apr-86 0743 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU meaning of *global* define
C00308 00010 ∂30-Apr-86 1425 @MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA Questions from a newcomer
C00311 00011 ∂30-Apr-86 2156 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Questions from a newcomer
C00313 00012 ∂05-May-86 1142 @MC.LCS.MIT.EDU:amn@LOCUS.UCLA.EDU getting C-Scheme running on HP workstations
C00315 00013 ∂05-May-86 1402 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU one more message about CScheme
C00317 00014 ∂05-May-86 1910 @MC.LCS.MIT.EDU:serafini@ames-aero implementation roundup
C00318 00015 ∂05-May-86 1914 JAR@MC.LCS.MIT.EDU implementation roundup
C00321 00016 ∂22-May-86 0819 NET-ORIGIN@MC.LCS.MIT.EDU H, E, S, B, O, D, X
C00323 00017 ∂22-May-86 0900 NET-ORIGIN@MC.LCS.MIT.EDU LOAD
C00328 00018 ∂22-May-86 1016 @MC.LCS.MIT.EDU:andy@aids-unix Re: LOAD
C00332 00019 ∂22-May-86 1558 @MC.LCS.MIT.EDU:KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Notes about (↑ revised 3) report
C00338 00020 ∂23-May-86 0957 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: H, E, S, B, O, D, X
C00341 00021 ∂23-May-86 1013 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: LOAD
C00344 00022 ∂25-May-86 0923 @MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA Addition to Mailing-List
C00346 00023 ∂25-May-86 1237 @MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA Addition to Mailing-List
C00348 00024 ∂26-May-86 1555 @MC.LCS.MIT.EDU:JAR@MX.LCS.MIT.EDU R↑3RS draft
C00351 00025 ∂27-May-86 1120 NET-ORIGIN@MC.LCS.MIT.EDU Remaining questions & remarks (1)
C00363 00026 ∂27-May-86 1339 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA define (resend)
C00367 00027 ∂27-May-86 1844 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define (resend) (long)
C00375 00028 ∂28-May-86 0827 @MC.LCS.MIT.EDU,@KATHERINE.THINK.COM:gls@AQUINAS.THINK.COM Remaining questions & remarks (1)
C00377 00029 ∂28-May-86 0836 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA hash-consing
C00380 00030 ∂28-May-86 1137 @MC.LCS.MIT.EDU:andy@aids-unix Re: define
C00384 00031 ∂28-May-86 1241 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: define (resend) (long) (short)
C00386 00032 ∂28-May-86 1736 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define (resend) (long) (short)
C00392 00033 ∂28-May-86 2216 @MC.LCS.MIT.EDU:gls@Think.COM Embedded DEFINE forms
C00394 00034 ∂28-May-86 2243 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Notes about (↑ revised 3) report
C00399 00035 ∂29-May-86 1417 NET-ORIGIN@MC.LCS.MIT.EDU define
C00405 00036 ∂29-May-86 1438 NET-ORIGIN@MC.LCS.MIT.EDU schedule
C00408 00037 ∂29-May-86 1450 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA define
C00411 00038 ∂29-May-86 1454 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA R3RS draft -- procedural
C00413 00039 ∂29-May-86 1545 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R3RS draft -- procedural
C00415 00040 ∂29-May-86 1610 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA response to new draft report (long)
C00435 00041 ∂29-May-86 1610 @MC.LCS.MIT.EDU,@CSNET-RELAY.ARPA,@boethius.think.com:gls@AQUINAS.THINK.COM hash-consing
C00437 00042 ∂29-May-86 1706 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: global definitions
C00442 00043 ∂30-May-86 1432 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA definitions APPEND! etc
C00449 00044 ∂30-May-86 1650 @MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA Re: Embedded DEFINE forms
C00453 00045 ∂30-May-86 1703 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA procedure (Tnx)
C00454 00046 ∂30-May-86 1703 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA define -- a modest proposal
C00459 00047 ∂31-May-86 0108 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define -- a modest proposal
C00464 00048 ∂31-May-86 0331 NET-ORIGIN@MC.LCS.MIT.EDU wanted: teaching do's and dont's
C00466 00049 ∂31-May-86 0539 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU wanted: teaching do's and dont's
C00472 00050 ∂31-May-86 0738 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA sentiments
C00479 00051 ∂31-May-86 1608 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU sentiments
C00490 00052 ∂31-May-86 2319 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU define -- a modest proposal
C00513 00053 ∂01-Jun-86 0815 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define -- a modest proposal
C00523 00054 ∂01-Jun-86 2051 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU schedule
C00525 00055 ∂01-Jun-86 2343 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: sentiments
C00544 00056 ∂02-Jun-86 0730 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Another Can of Worms?
C00548 00057 ∂02-Jun-86 1558 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU sentiments
C00560 00058 ∂02-Jun-86 1604 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA DEFINE -- a concrete proposal
C00569 00059 ∂02-Jun-86 1803 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: definitions APPEND! etc
C00572 00060 ∂03-Jun-86 0853 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
C00574 00061 ∂03-Jun-86 0953 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU APPEND!
C00576 00062 ∂03-Jun-86 1010 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
C00584 00063 ∂03-Jun-86 1124 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA define
C00587 00064 ∂03-Jun-86 1441 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA SCOOPS source
C00589 00065 ∂03-Jun-86 1554 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Is BEGIN primitive?
C00592 00066 ∂03-Jun-86 2023 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU ftp-able r3rs.dvi
C00594 00067 ∂04-Jun-86 0554 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: portability
C00596 00068 ∂04-Jun-86 1049 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA Re: SCOOPS source
C00598 00069 ∂04-Jun-86 1623 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: portability
C00601 00070 ∂05-Jun-86 0546 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: portability
C00603 00071 ∂05-Jun-86 0935 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Will's proposal
C00604 00072 ∂05-Jun-86 0939 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA named-lambda and rec
C00605 00073 ∂05-Jun-86 1055 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU named-lambda and rec
C00607 00074 ∂06-Jun-86 0800 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
C00612 00075 ∂06-Jun-86 0806 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA add1 and sub1
C00614 00076 ∂06-Jun-86 1039 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU add1 and sub1
C00616 00077 ∂06-Jun-86 2038 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: portability
C00620 00078 ∂07-Jun-86 1658 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA macros.
C00621 00079 ∂07-Jun-86 1820 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: named-lambda and rec
C00623 00080 ∂07-Jun-86 1829 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: add1 and sub1
C00625 00081 ∂08-Jun-86 1652 @MC.LCS.MIT.EDU:Swenson.Multics@MIT-MULTICS.ARPA Re: SCOOPS source
C00627 00082 ∂09-Jun-86 1643 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
C00634 00083 ∂10-Jun-86 0744 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: portability
C00638 00084 ∂11-Jun-86 1021 @MC.LCS.MIT.EDU:TIM%upenn.csnet@CSNET-RELAY.ARPA Scheme for AI based CAI
C00645 00085 ∂11-Jun-86 1145 @MC.LCS.MIT.EDU:FAHLMAN@C.CS.CMU.EDU Scheme for AI based CAI
C00650 00086 ∂13-Jun-86 0956 @MC.LCS.MIT.EDU:mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Revised↑3 Draft Comment
C00652 00087 ∂15-Jun-86 1251 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA Logic Continuations (Abstract)
C00655 00088 ∂17-Jun-86 1621 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Number syntax
C00659 00089 ∂17-Jun-86 1909 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Number syntax
C00662 00090 ∂17-Jun-86 1912 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Policy on change-making
C00666 00091 ∂18-Jun-86 2144 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: Number syntax
C00668 00092 ∂20-Jun-86 0202 @MC.LCS.MIT.EDU:JINX@OZ.AI.MIT.EDU Policy on change-making
C00670 00093 ∂23-Jun-86 1412 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Bibliography
C00672 00094 ∂26-Jun-86 2114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Remaining questions & remarks (2)
C00694 00095 ∂27-Jun-86 0943 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA r3rs presentation
C00700 00096 ∂27-Jun-86 1115 @MC.LCS.MIT.EDU:gls@Think.COM Remaining questions & remarks (2)
C00705 00097 ∂27-Jun-86 1653 @MC.LCS.MIT.EDU:SGR@ELEPHANT-BUTTE.SCRC.Symbolics.COM [INGRIA@G.BBN.COM: Scheme for LISPM]
C00707 00098 ∂27-Jun-86 1930 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU typo
C00708 00099 ∂27-Jun-86 2142 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Grandfathering Responses
C00727 00100 ∂28-Jun-86 1511 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU variable vs. identifier
C00729 00101 ∂28-Jun-86 1511 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Grandfathering response
C00748 00102 ∂29-Jun-86 1205 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [INGRIA@G.BBN.COM: Scheme for LISPM]
C00751 00103 ∂29-Jun-86 2140 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
C00762 00104 ∂30-Jun-86 0741 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: r3rs presentation (long)
C00771 00105 ∂01-Jul-86 1040 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Call-with-current-continuation
C00775 00106 ∂01-Jul-86 1432 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
C00790 00107 ∂01-Jul-86 1446 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
C00812 00108 ∂02-Jul-86 0515 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: Remaining questions & remarks (2)
C00814 00109 ∂02-Jul-86 0557 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Call-with-current-continuation
C00818 00110 ∂02-Jul-86 1652 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Remaining questions & remarks (2)
C00821 00111 ∂07-Jul-86 0929 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU CL Compatiblity Package
C00823 00112 ∂07-Jul-86 1254 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA votes and things
C00829 00113 ∂08-Jul-86 0538 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA display and write-char
C00831 00114 ∂08-Jul-86 2347 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA remaining questions & remarks (2)
C00837 00115 ∂09-Jul-86 0340 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU mitch wand's comments
C00838 00116 ∂10-Jul-86 1015 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU number syntax
C00843 00117 ∂10-Jul-86 1016 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU call-with-*put-file --> call-with-*put-port
C00845 00118 ∂10-Jul-86 1228 @MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU How big would a "minimal" scheme interpreter be?
C00846 00119 ∂10-Jul-86 1300 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA My comments on the R↑RS
C00865 00120 ∂10-Jul-86 1313 @MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
C00868 00121 ∂10-Jul-86 1342 @MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
C00872 00122 ∂10-Jul-86 1540 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA My answers to your thirty questions on R↑RS
C00882 00123 ∂10-Jul-86 1941 @MC.LCS.MIT.EDU:whill%hplabsc@hplabs.HP.COM Re: [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
C00884 00124 ∂11-Jul-86 0336 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU MacScheme
C00886 00125 ∂11-Jul-86 0925 @MC.LCS.MIT.EDU:gls@Think.COM My comments on the R↑RS
C00895 00126 ∂11-Jul-86 0935 @MC.LCS.MIT.EDU:cscott@bfly-vax.bbn.com tiny scheme
C00897 00127 ∂11-Jul-86 1142 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: My comments on the R↑RS
C00903 00128 ∂11-Jul-86 1642 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test
C00904 00129 ∂12-Jul-86 1837 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Compatibility with Common Lisp: A meta comment
C00909 00130 ∂13-Jul-86 1528 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA Scheme's DO construct
C00925 00131 ∂14-Jul-86 0252 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Flaws of form
C00932 00132 ∂14-Jul-86 0325 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Flaws of form
C00939 00133 ∂14-Jul-86 0641 @MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA Re: Compatibility with Common Lisp: A meta comment
C00941 00134 ∂14-Jul-86 0741 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Common Lisp
C00944 00135 ∂14-Jul-86 1008 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ANDY: dedication]
C00946 00136 ∂14-Jul-86 1337 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Use of DO in Common Lisp Code
C00950 00137 ∂14-Jul-86 1448 @MC.LCS.MIT.EDU:goodhart%cod@nosc.ARPA Scheme Request
C00952 00138 ∂14-Jul-86 1514 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA Scheme vs. Common Lisp, #1: Politics
C00966 00139 ∂14-Jul-86 1607 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Politics
C00971 00140 ∂14-Jul-86 1702 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA call-with-xput-port vs. call-with-xput-file
C00976 00141 ∂14-Jul-86 1814 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme Request
C00979 00142 ∂14-Jul-86 2156 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA the colon (:) in identifier syntax
C00981 00143 ∂14-Jul-86 2159 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA exp versus expt
C00983 00144 ∂15-Jul-86 0951 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU convergence
C00985 00145 ∂15-Jul-86 1807 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Scheme's DO construct
C00996 00146 ∂15-Jul-86 2019 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU rrrs-authors
C01000 00147 ∂15-Jul-86 2105 @MC.LCS.MIT.EDU:jleech@sun6.ads the rrrs authors
C01002 00148 ∂16-Jul-86 1731 @MC.LCS.MIT.EDU:brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA Substring & friends
C01005 00149 ∂16-Jul-86 1732 @MC.LCS.MIT.EDU:Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA Re: number syntax
C01014 00150 ∂16-Jul-86 1921 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU July 15 draft sent
C01016 00151 ∂17-Jul-86 0851 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Substring & friends
C01019 00152 ∂17-Jul-86 1217 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: Substring & friends
C01021 00153 ∂17-Jul-86 1412 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [jtv%fingate.bitnet: Scheme Request]
C01023 00154 ∂17-Jul-86 1442 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Substring & friends
C01026 00155 ∂18-Jul-86 0012 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Substring & friends
C01029 00156 ∂18-Jul-86 1428 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [jtv%fingate.bitnet: Scheme Request]
C01031 00157 ∂21-Jul-86 0448 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA typos
C01034 00158 ∂21-Jul-86 0737 @MC.LCS.MIT.EDU:Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU Performance and Evaluation of Scheme Systems...
C01037 00159 ∂21-Jul-86 0808 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU schedule
C01040 00160 ∂21-Jul-86 0827 @MC.LCS.MIT.EDU:CLOWNEY@BLUE.RUTGERS.EDU Logic Continuations (Abstract)
C01042 00161 ∂21-Jul-86 1014 @MC.LCS.MIT.EDU:gls@Think.COM Scheme's DO construct
C01046 00162 ∂21-Jul-86 1057 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: Performance and Evaluation of Scheme Systems...
C01050 00163 ∂21-Jul-86 1143 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU Bobcat scheme
C01052 00164 ∂21-Jul-86 1228 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Logic Continuations (Abstract)
C01069 00165 ∂21-Jul-86 1325 @MC.LCS.MIT.EDU:gls@Think.COM Re: Scheme's DO construct
C01071 00166 ∂21-Jul-86 1357 @MC.LCS.MIT.EDU:YEKTA@AI.AI.MIT.EDU Bobcat scheme
C01073 00167 ∂22-Jul-86 0710 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU title wars
C01076 00168 ∂22-Jul-86 0717 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU title wars
C01077 00169 ∂22-Jul-86 1143 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU title wars
C01079 00170 ∂22-Jul-86 1157 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU title wars
C01081 00171 ∂22-Jul-86 1243 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: title wars
C01083 00172 ∂22-Jul-86 1252 @MC.LCS.MIT.EDU,@YALE-BULLDOG.ARPA:hudak@YALE.ARPA Re: Performance and Evaluation of Scheme Systems...
C01089 00173 ∂22-Jul-86 1529 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: title wars
C01092 00174 ∂22-Jul-86 1755 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU title
C01093 00175 ∂24-Jul-86 1244 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU call-with-xput-port vs. call-with-xput-file
C01098 00176 ∂25-Jul-86 0022 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: July 15 draft sent
C01107 00177 ∂25-Jul-86 1026 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: number syntax
C01116 00178 ∂25-Jul-86 1127 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (eqv? #e1 #i1)
C01119 00179 ∂25-Jul-86 1346 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA July 15th draft
C01125 00180 ∂26-Jul-86 2137 @MC.LCS.MIT.EDU:cth%iuvax.indiana.edu@CSNET-RELAY.ARPA corrections and suggestions
C01133 00181 ∂28-Jul-86 0810 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Fault logic in eq? comment
C01136 00182 ∂28-Jul-86 1616 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: corrections and suggestions
C01142 00183 ∂29-Jul-86 1331 @MC.LCS.MIT.EDU:dyb@iuvax.indiana.edu critical problems with call---file, with---file
C01149 00184 ∂29-Jul-86 1423 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU schedule
C01152 00185 ∂29-Jul-86 1814 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: critical problems with call---file, with---file
C01157 00186 ∂31-Jul-86 0732 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU rrrs authors meeting, lunch Tuesday
C01160 00187 ∂31-Jul-86 1111 @MC.LCS.MIT.EDU:fateman@DALI.BERKELEY.EDU Re: Performance and Evaluation of Scheme Systems...
C01162 00188 ∂04-Aug-86 0107 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
C01164 00189 ∂04-Aug-86 0158 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
C01166 00190 ∂06-Aug-86 0150 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
C01168 00191 ∂07-Aug-86 0136 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU non-list arguments
C01171 00192 ∂07-Aug-86 0301 @MC.LCS.MIT.EDU:Pase@DOCKMASTER.ARPA Scheme for the Atari ST
C01173 00193 ∂07-Aug-86 0730 @MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA Re: Scheme for the Atari ST
C01177 00194 ∂08-Aug-86 0819 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU
C01182 00195 ∂08-Aug-86 1230 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [Masinter.pa: synonym streams..]
C01184 00196 ∂08-Aug-86 1712 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA "Final" comments on RRRRS
C01187 00197 ∂11-Aug-86 0855 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:SRAUCH@UNBMVS1.BITNET Instructor's manual for S&ICP by Julie Sussman
C01189 00198 ∂13-Aug-86 0238 NET-ORIGIN@MC.LCS.MIT.EDU Re: define
C01192 00199 ∂14-Aug-86 1728 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Minutes from lunch 5 August 1986
C01202 00200 ∂14-Aug-86 1855 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: Minutes from lunch 5 August 1986
C01204 00201 ∂14-Aug-86 2053 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA substring indexes
C01207 00202 ∂14-Aug-86 2233 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA r-cubed syntax (nits)
C01210 00203 ∂15-Aug-86 0902 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA Re: Minutes from lunch 5 August 1986
C01211 00204 ∂15-Aug-86 1106 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU r-cubed syntax (nits)
C01214 00205 ∂15-Aug-86 1112 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU scheme report tar file
C01216 00206 ∂15-Aug-86 1223 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU "Final" comments on RRRRS
C01220 00207 ∂15-Aug-86 2150 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU "Final" comments on RRRRS
C01224 00208 ∂18-Aug-86 0051 @MC.LCS.MIT.EDU:ram@YALE.ARPA Re: The generality of define
C01229 00209 ∂18-Aug-86 1650 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA define syntax (an apology)
C01233 00210 ∂20-Aug-86 2002 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA numbers
C01241 00211 ∂22-Aug-86 0555 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA a few more comments
C01245 00212 ∂22-Aug-86 1208 @MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 1986 Lisp conference bibliography
C01284 00213 ∂23-Aug-86 1738 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: numbers
C01286 00214 ∂25-Aug-86 2008 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Another nit my favorite numbers
C01291 00215 ∂28-Aug-86 0849 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Minutes from lunch 5 August 1986
C01293 00216 ∂28-Aug-86 0908 @MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM Minutes/Standardize Graphics
C01295 00217 ∂28-Aug-86 2012 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: Minutes from lunch 5 August 1986
C01297 00218 ∂29-Aug-86 1503 @MC.LCS.MIT.EDU:andy@ads.ARPA graphics for Scheme
C01302 00219 ∂02-Sep-86 1519 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU substring-vector-null-fill!, colitis, etc.
C01310 00220 ∂03-Sep-86 0424 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA call-with-xxput-port
C01312 00221 ∂03-Sep-86 0625 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU substring-vector-null-fill!, colitis, etc.
C01316 00222 ∂04-Sep-86 0858 @MC.LCS.MIT.EDU:F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU Scheme Books?
C01318 00223 ∂04-Sep-86 1828 @MC.LCS.MIT.EDU:wecker%cookie.DEC@decwrl.DEC.COM Please delete me from this distribution list, thanks - dave
C01319 00224 ∂05-Sep-86 1947 @MC.LCS.MIT.EDU:mh@BU-CS.BU.EDU list
C01320 00225 ∂08-Sep-86 0330 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA Beginners question: Advising methods in TI scheme
C01323 00226 ∂08-Sep-86 0826 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA Re: [THOMAS: Scheme Books?]
C01325 00227 ∂08-Sep-86 0848 @MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa scoops
C01327 00228 ∂08-Sep-86 1334 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA Beginners question: Advising methods in TI scheme
C01330 00229 ∂08-Sep-86 1509 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Good & bad news
C01333 00230 ∂08-Sep-86 1614 @MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA substring-vector-null-fill!, coliti
C01335 00231 ∂08-Sep-86 2212 @MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Advising methods in TI Scheme
C01338 00232 ∂09-Sep-86 0429 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Slade's book in bib?
C01340 00233 ∂13-Sep-86 2054 @MC.LCS.MIT.EDU:fowler@rochester.arpa Re: Prolog in Scheme?
C01342 00234 ∂14-Sep-86 0204 @MC.LCS.MIT.EDU:MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU Prolog in Scheme?
C01344 00235 ∂15-Sep-86 0450 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Prolog in Scheme?
C01346 00236 ∂15-Sep-86 1223 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Begin in the Formal Semantics
C01348 00237 ∂15-Sep-86 1237 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Begin in the Formal Semantics
C01351 00238 ∂15-Sep-86 1243 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Begin in the Formal Semantics
C01353 00239 ∂15-Sep-86 1910 @MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Advising methods in TI Scheme
C01356 00240 ∂17-Sep-86 1224 @MC.LCS.MIT.EDU:prlb2!vauclair@seismo.CSS.GOV Request for information on new releases.
C01361 00241 ∂22-Sep-86 1441 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme
C01363 00242 ∂24-Sep-86 0739 @MC.LCS.MIT.EDU:DLW@ALDERAAN.SCRC.Symbolics.COM [MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?]
C01366 00243 ∂24-Sep-86 0936 @MC.LCS.MIT.EDU:searfus@lll-icdc.arpa please add me ...
C01367 00244 ∂25-Sep-86 0750 @MC.LCS.MIT.EDU:TIM@cis.upenn.edu prolog in scheme
C01370 00245 ∂25-Sep-86 1309 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU prolog in scheme
C01373 00246 ∂28-Sep-86 0818 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Prolog in Scheme
C01375 00247 ∂30-Sep-86 0507 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Refering to the Revised↑3 Report on Scheme
C01377 00248 ∂01-Oct-86 1416 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R↑3RS sources
C01379 00249 ∂02-Oct-86 0803 @MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA Lost mail
C01381 00250 ∂02-Oct-86 1013 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Lost mail
C01383 00251 ∂02-Oct-86 1114 @MC.LCS.MIT.EDU:mohammad%utah-orion@utah-cs.arpa Can anyone hear me?
C01385 00252 ∂02-Oct-86 1714 @MC.LCS.MIT.EDU:zorn@kim.Berkeley.EDU I am interested in gathering `significant' Scheme programs...
C01388 00253 ∂06-Oct-86 2336 @MC.LCS.MIT.EDU:dan%umass-boston.csnet@CSNET-RELAY.ARPA SCHEME implementations
C01390 00254 ∂15-Oct-86 0606 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Object-Oriented Schemes
C01393 00255 ∂16-Oct-86 1410 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Public Domain
C01396 00256 ∂20-Oct-86 0417 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Re: Public Domain
C01398 00257 ∂20-Oct-86 1205 @MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM [harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]]
C01400 00258 ∂27-Oct-86 1824 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values: A Survey
C01414 00259 ∂27-Oct-86 1859 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values
C01417 00260 ∂27-Oct-86 2205 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values: An Opinion
C01432 00261 ∂28-Oct-86 0556 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Multiple values
C01436 00262 ∂28-Oct-86 0615 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Multiple values
C01438 00263 ∂28-Oct-86 1358 @MC.LCS.MIT.EDU:andy@hobbes.ARPA Re: Multiple values
C01441 00264 ∂30-Oct-86 0139 @MC.LCS.MIT.EDU:harris%hplwhh@HPLABS.HP.COM Re: Multiple Values: An Opinion
C01449 00265 ∂30-Oct-86 1228 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA multiple values
C01452 00266 ∂30-Oct-86 1339 @MC.LCS.MIT.EDU:jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA Multiple Values: An Opinion
C01460 00267 ∂30-Oct-86 1520 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: multiple values
C01464 00268 ∂30-Oct-86 2204 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
C01474 00269 ∂31-Oct-86 1840 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
C01479 00270 ∂31-Oct-86 1916 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Journal of Lisp and Symbolic Computation -- call for papers
C01486 00271 ∂03-Nov-86 0855 @MC.LCS.MIT.EDU:gls@Think.COM Marvel?
C01490 00272 ∂03-Nov-86 1221 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU gls@AQUINAS/cc
C01494 00273 ∂05-Nov-86 0305 @MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA [Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]
C01496 00274 ∂07-Nov-86 0351 @MC.LCS.MIT.EDU:enea!tut!jh@seismo.CSS.GOV eval and orbit
C01499 00275 ∂07-Nov-86 1716 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Automatic removal from list...
C01502 00276 ∂07-Nov-86 1817 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU MIT AIM 848a
C01503 00277 ∂07-Nov-86 1839 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Hot off the press...
C01507 00278 ∂08-Nov-86 1121 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple
C01508 00279 ∂08-Nov-86 1303 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:REMARCK@UCLASSCF.BITNET This account is scheduled to be deleted soon...
C01510 00280 ∂09-Nov-86 0851 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU eval and orbit
C01513 00281 ∂10-Nov-86 1301 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@RELAY.CS.NET Re: multiple values
C01519 00282 ∂10-Nov-86 1904 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU silly multiple values
C01523 00283 ∂11-Nov-86 0853 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme errors?
C01526 00284 ∂13-Nov-86 0752 @MC.LCS.MIT.EDU:sieber-john@YALE.ARPA Add me to the list
C01528 00285 ∂15-Nov-86 1839 @MC.LCS.MIT.EDU:reddy@a.cs.uiuc.edu make-environment
C01530 00286 ∂15-Nov-86 1913 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET question: S&ICP teacher's manual and query language
C01532 00287 ∂15-Nov-86 1951 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET question: S&ICP teacher's manual and query language
C01535 00288 ∂16-Nov-86 1021 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU make-environment (long)
C01540 00289 ∂18-Nov-86 0915 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme reports information request
C01543 00290 ∂22-Nov-86 1845 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU truncate
C01545 00291 ∂25-Nov-86 1315 @MC.LCS.MIT.EDU:camp%home%ti-csl.csnet@RELAY.CS.NET PC Scheme Utilities
C01549 00292 ∂03-Dec-86 1055 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme redistribution for BITNET
C01551 00293 ∂08-Dec-86 0049 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Ambiguity in number syntax
C01553 00294 ∂08-Dec-86 0835 @MC.LCS.MIT.EDU:muller@BU-CS.BU.EDU IBM PC Scheme
C01555 00295 ∂08-Dec-86 0934 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU IBM PC Scheme
C01557 00296 ∂08-Dec-86 1016 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Ambiguity in number syntax
C01559 00297 ∂09-Dec-86 0812 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define foo)
C01563 00298 ∂17-Dec-86 0712 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET What is comma-dot?
C01565 00299 ∂31-Dec-86 1100 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU SCOOPS
C01568 00300 ∂31-Dec-86 1319 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU What is comma-dot?
C01570 00301 ∂31-Dec-86 1333 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [COMSAT: Msg of Monday, 22 December 1986 16:31-EST]
C01578 00302 ∂05-Jan-87 0803 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU SYMBOLIC COMPUTATION.
C01581 00303 ∂05-Jan-87 2047 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: What is comma-dot?
C01583 00304 ∂06-Jan-87 0824 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET What is comma-dot?
C01586 00305 ∂10-Jan-87 1130 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 2nd test
C01587 00306 ∂16-Jan-87 0850 @MC.LCS.MIT.EDU:dfried%iuvax.cs.indiana.edu@RELAY.CS.NET multiple values and T
C01594 00307 ∂16-Jan-87 1400 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: multiple values and T
C01598 00308 ∂16-Jan-87 1645 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
C01606 00309 ∂16-Jan-87 1656 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
C01612 00310 ∂18-Jan-87 2027 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Scheme time
C01615 00311 ∂25-Jan-87 1837 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [vanroggen%bach.DEC: Looking for Lisps...]
C01620 00312 ∂02-Feb-87 1040 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Time Scales
C01623 00313 ∂03-Feb-87 0433 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA X windows
C01625 00314 ∂04-Feb-87 0744 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA Re: X windows
C01628 00315 ∂05-Feb-87 0742 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Windows
C01630 00316 ∂20-Feb-87 0746 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [hay%ubc.csnet: no mail]
C01632 00317 ∂24-Feb-87 0834 @MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM help -- set command
C01635 00318 ∂26-Feb-87 0457 @MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM Re: help -- set command
C01637 00319 ∂04-Mar-87 0925 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MEDIA.MIT.EDU OOPSs for Scheme, MacScheme
C01639 00320 ∂04-Mar-87 1200 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU r↑2 vs. r↑3
C01645 00321 ∂04-Mar-87 1808 @MC.LCS.MIT.EDU:cpd@CS.UCLA.EDU Re: r↑2 vs. r↑3
C01659 00322 ∂05-Mar-87 1253 @MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET Re: OOPSs for Scheme, MacScheme
C01661 00323 ∂05-Mar-87 1955 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Tiny Object System
C01673 00324 ∂07-Mar-87 0351 @MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV distribution list
C01675 00325 ∂09-Mar-87 0055 @MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET Re: distribution list
C01677 00326 ∂10-Mar-87 1930 @MC.LCS.MIT.EDU:jar@ZURICH.AI.MIT.EDU test suite candidate
C01680 00327 ∂10-Mar-87 2309 @MC.LCS.MIT.EDU:cth%iucs.cs.indiana.edu@RELAY.CS.NET
C01686 00328 ∂11-Mar-87 2251 @MC.LCS.MIT.EDU:cth@IUCS.CS.INDIANA.EDU Scheme 84
C01692 00329 ∂12-Mar-87 0356 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Question: are theres ANY VIDEO TAPES available for Scheme ?
C01695 00330 ∂12-Mar-87 0608 @MC.LCS.MIT.EDU:dyb@IUVAX.CS.INDIANA.EDU Re: test suite candidate
C01698 00331 ∂16-Mar-87 1056 @MC.LCS.MIT.EDU:DAN@cis.upenn.edu Revised Revised Revised Report on Scheme
C01700 00332 ∂16-Mar-87 1517 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme administrivia
C01704 00333 ∂16-Mar-87 2003 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Request for public domain Scheme programs
C01706 00334 ∂17-Mar-87 0847 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme administrivia
C01708 00335 ∂17-Mar-87 1405 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU eqv?
C01710 00336 ∂17-Mar-87 1526 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Re: Question: are theres ANY VIDEO TAPES available for Scheme ?
C01712 00337 ∂22-Mar-87 1714 @MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV dump-world problem on 4.2BSD vax (version 4 C-scheme)
C01715 00338 ∂23-Mar-87 0752 @MC.LCS.MIT.EDU:muller@bu-cs.bu.edu Scheme mode in GNU Emacs
C01717 00339 ∂23-Mar-87 0850 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Scheme mode in GNU Emacs
C01720 00340 ∂23-Mar-87 2309 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Looking for comments on an introductory article about Scheme
C01724 00341 ∂24-Mar-87 1029 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Scheme mode in GNU Emacs
C01726 00342 ∂25-Mar-87 0925 @MC.LCS.MIT.EDU:mcvax!crcge1!adams@seismo.CSS.GOV scheme mailing list
C01728 00343 ∂26-Mar-87 0235 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Private message to Cynthia Mason. (mail problem)
C01730 00344 ∂26-Mar-87 0356 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Correction mistake: Looking for comments on an introductory article ..
C01733 00345 ∂27-Mar-87 1850 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET multiple return values
C01743 00346 ∂27-Mar-87 1858 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Let's get together again
C01747 00347 ∂27-Mar-87 2120 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
C01750 00348 ∂28-Mar-87 1146 @MC.LCS.MIT.EDU:KMP@YUKON.SCRC.Symbolics.COM Let's get together again
C01753 00349 ∂28-Mar-87 1400 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Let's get together again
C01755 00350 ∂28-Mar-87 2023 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU a modest macro proposal
C01796 00351 ∂29-Mar-87 1558 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU meeting
C01797 00352 ∂30-Mar-87 0917 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ALAN: multiple return values]
C01800 00353 ∂30-Mar-87 1023 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU [ALAN: multiple return values]
C01804 00354 ∂30-Mar-87 1136 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU almost scheme in common lisp
C01807 00355 ∂30-Mar-87 1455 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: multiple return values
C01810 00356 ∂30-Mar-87 1509 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: Let's get together again
C01813 00357 ∂30-Mar-87 1858 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Let's get together again
C01815 00358 ∂30-Mar-87 2026 @MC.LCS.MIT.EDU:adams%tekchips.tek.com@RELAY.CS.NET Re: multiple return values
C01818 00359 ∂30-Mar-87 2112 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU A Couple of Fun Programs
C01821 00360 ∂31-Mar-87 1146 @MC.LCS.MIT.EDU:gls@Think.COM A Couple of Fun Programs
C01824 00361 ∂31-Mar-87 1703 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
C01826 00362 ∂31-Mar-87 1743 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Scheme Numbers
C01828 00363 ∂31-Mar-87 1829 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values
C01835 00364 ∂31-Mar-87 2009 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
C01839 00365 ∂31-Mar-87 2025 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
C01841 00366 ∂31-Mar-87 2037 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU More on Fun Programs
C01843 00367 ∂01-Apr-87 0215 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:ETSTMOL@HDETUD1.BITNET NOTE from ETSTMOL
C01845 00368 ∂01-Apr-87 0546 @MC.LCS.MIT.EDU:kwh@ multiple return values
C01847 00369 ∂01-Apr-87 1030 @MC.LCS.MIT.EDU:gls@Think.COM A Couple of Fun Programs
C01849 00370 ∂01-Apr-87 1142 @MC.LCS.MIT.EDU:gls@Think.COM multiple return values
C01852 00371 ∂01-Apr-87 1158 @MC.LCS.MIT.EDU:gls@Think.COM Apologies
C01854 00372 ∂01-Apr-87 1907 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
C01857 00373 ∂01-Apr-87 1953 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
C01860 00374 ∂01-Apr-87 2232 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU multiple return values
C01863 00375 ∂01-Apr-87 2333 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU multiple return values (LONG)
C01876 00376 ∂02-Apr-87 0714 @MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA More bum code
C01878 00377 ∂02-Apr-87 1129 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values (LONG)
C01888 00378 ∂02-Apr-87 1138 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values
C01893 00379 ∂03-Apr-87 1043 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET optional arguments
C01906 00380 ∂03-Apr-87 1415 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU optional arguments
C01910 00381 ∂04-Apr-87 2028 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA TIPC windows
C01912 00382 ∂04-Apr-87 2330 @MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu scheme in prolog
C01917 00383 ∂06-Apr-87 0927 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Need consultant
C01919 00384 ∂06-Apr-87 1044 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET optional arguments
C01924 00385 ∂06-Apr-87 1232 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU Optionals
C01926 00386 ∂06-Apr-87 1241 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU current membership
C01931 00387 ∂06-Apr-87 1319 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU optional arguments
C01939 00388 ∂06-Apr-87 1404 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU Taste
C01943 00389 ∂06-Apr-87 1431 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Optionals
C01946 00390 ∂07-Apr-87 0542 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA macros
C01948 00391 ∂07-Apr-87 0825 @MC.LCS.MIT.EDU:gls@Think.COM Optionals
C01952 00392 ∂07-Apr-87 1337 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU macros
C01955 00393 ∂07-Apr-87 1710 @MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU scheme in prolog
C01962 00394 ∂07-Apr-87 1944 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Taste
C01968 00395 ∂08-Apr-87 0803 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU Concurrency in Scheme
C01970 00396 ∂08-Apr-87 0917 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET macros
C01974 00397 ∂08-Apr-87 1025 @MC.LCS.MIT.EDU:Kahn.pa@Xerox.COM Re: scheme in prolog
C01978 00398 ∂08-Apr-87 1532 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET towards an agenda
C01982 00399 ∂08-Apr-87 2121 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU multiple values
C01987 00400 ∂08-Apr-87 2219 @MC.LCS.MIT.EDU:munnari!goanna.oz!hal@seismo.CSS.GOV towards an agenda
C01989 00401 ∂08-Apr-87 2243 @MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu scheme in prolog
C01992 00402 ∂09-Apr-87 0052 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: scheme in prolog
C01996 00403 ∂09-Apr-87 0732 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU towards an agenda
C01998 00404 ∂09-Apr-87 1001 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU readers & tokenizers
C02005 00405 ∂09-Apr-87 1012 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU readers & tokenizers
C02007 00406 ∂09-Apr-87 1324 @MC.LCS.MIT.EDU:gls@Think.COM readers & tokenizers
C02010 00407 ∂09-Apr-87 1412 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM multiple return values
C02015 00408 ∂09-Apr-87 1420 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA readers & tokenizers
C02022 00409 ∂09-Apr-87 1638 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET number syntax
C02025 00410 ∂09-Apr-87 1648 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET readers & tokenizers
C02028 00411 ∂09-Apr-87 1803 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU number syntax
C02033 00412 ∂09-Apr-87 1848 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU yellow pages
C02036 00413 ∂09-Apr-87 1921 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU readers & tokenizers
C02043 00414 ∂09-Apr-87 2348 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA Re: readers & tokenizers
C02052 00415 ∂10-Apr-87 0734 @MC.LCS.MIT.EDU:jmiller@MEPHISTOPHELES.AI.MIT.EDU yellow pages
C02054 00416 ∂10-Apr-87 0944 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET macros
C02061 00417 ∂10-Apr-87 1000 @MC.LCS.MIT.EDU:gls@Think.COM number syntax
C02063 00418 ∂10-Apr-87 1238 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU number syntax
C02066 00419 ∂10-Apr-87 1637 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU macros
C02077 00420 ∂10-Apr-87 1646 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU meeting dates/times/places
C02080 00421 ∂10-Apr-87 1653 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET number syntax
C02083 00422 ∂10-Apr-87 2103 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: number syntax
C02092 00423 ∂11-Apr-87 0814 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU towards an agenda - yeller pages
C02096 00424 ∂12-Apr-87 1158 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:LISP@BROWNVM.BITNET Scheme85 interpreter from Indiana...
C02098 00425 ∂12-Apr-87 1724 @MC.LCS.MIT.EDU:harris%hplwhh@hplabs.HP.COM Re: number syntax
C02102 00426 ∂12-Apr-87 2125 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: meeting dates/times/places
C02104 00427 ∂13-Apr-87 0951 @MC.LCS.MIT.EDU:larus@paris.Berkeley.EDU Scheme programs
C02106 00428 ∂13-Apr-87 1346 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
C02115 00429 ∂13-Apr-87 2114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU towards an agenda - yeller pages
C02119 00430 ∂13-Apr-87 2343 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu meeting dates
C02122 00431 ∂14-Apr-87 0048 @MC.LCS.MIT.EDU:mcvax!inria!crcge1.cge.fr!adams@seismo.CSS.GOV Scheme85 interpreter from Indiana...
C02124 00432 ∂15-Apr-87 0952 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Pattern matching, not optional arguments
C02131 00433 ∂16-Apr-87 1319 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
C02143 00434 ∂16-Apr-87 1329 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
C02155 00435 ∂16-Apr-87 1646 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU meeting dates/times
C02158 00436 ∂20-Apr-87 0906 @MC.LCS.MIT.EDU:bartley%Home%ti-csl.csnet@RELAY.CS.NET Re: meeting dates/times
C02160 00437 ∂22-Apr-87 1357 @MC.LCS.MIT.EDU:unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc Please add ...
C02162 00438 ∂22-Apr-87 1510 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu match questions
C02168 00439 ∂22-Apr-87 1746 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU match questions
C02173 00440 ∂23-Apr-87 0957 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU match questions
C02175 00441 ∂23-Apr-87 1143 @MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA Re: match questions
C02178 00442 ∂23-Apr-87 1324 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: match questions
C02186 00443 ∂23-Apr-87 1343 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Scheme pattern matcher
C02196 00444 ∂23-Apr-87 1433 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu match questions
C02200 00445 ∂23-Apr-87 1726 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: match questions
C02205 00446 ∂23-Apr-87 2014 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU The verdict: 27-28 June
C02207 00447 ∂24-Apr-87 1720 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET match questions
C02214 00448 ∂24-Apr-87 1854 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: match questions
C02218 00449 ∂26-Apr-87 1256 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM match questions
C02222 00450 ∂27-Apr-87 1241 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU match questions
C02224 00451 ∂28-Apr-87 0645 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:MDEBAR@BNANDP11.BITNET Scoops
C02226 00452 ∂29-Apr-87 1108 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Engine operating system (long msg)
C02250 00453 ∂30-Apr-87 1603 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET another set of primitives for concurrency
C02256 00454 ∂30-Apr-87 1928 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu environment networks
C02258 00455 ∂09-May-87 1206 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU Re: Engine operating system (long msg)
C02260 00456 ∂14-May-87 1244 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Scheme for lisp machines
C02261 00457 ∂18-May-87 1745 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Should ":" be an extended alphabetic character?
C02264 00458 ∂18-May-87 1910 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Should ":" be an extended alphabetic character?
C02266 00459 ∂18-May-87 1929 @MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA Re: Should ":" be an extended alphabetic character?
C02270 00460 ∂19-May-87 0654 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Should ":" be an extended alphabetic character?
C02275 00461 ∂19-May-87 0818 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Should ":" be an extended alphabetic character?
C02278 00462 ∂19-May-87 0918 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Should ":" be an extended alphabetic character?
C02281 00463 ∂19-May-87 1645 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Should ":" be an extended alphabetic character?
C02287 00464 ∂19-May-87 2117 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU Should ":" be an extended alphabetic character?
C02289 00465 ∂20-May-87 1001 June meeting
C02291 00466 ∂20-May-87 1949 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
C02294 00467 ∂21-May-87 0900 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
C02297 00468 ∂21-May-87 1027 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU June meeting -- accommodations
C02302 00469 ∂21-May-87 1112 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU who will be there
C02306 00470 ∂21-May-87 1300 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU correction
C02307 00471 ∂21-May-87 2155 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
C02309 00472 ∂21-May-87 2314 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu Getting scoops... (Please give arpa pathway back.)
C02311 00473 ∂22-May-87 0732 @MC.LCS.MIT.EDU,@MIT-Multics.ARPA:NETWORK@FRSAC11.BITNET CScheme Rel 5
C02314 00474 ∂22-May-87 1043 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU CScheme Rel 5
C02317 00475 ∂23-May-87 2256 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu Scoops bug fix
C02319 00476 ∂25-May-87 0853 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu scoops bug found
C02321 00477 ∂26-May-87 1413 @MC.LCS.MIT.EDU,@RELAY.CS.NET:janeta@albatross.uss.tek.com Forwarded Mail
C02326 00478 ∂01-Jun-87 1824 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com customizable reader
C02336 00479 ∂03-Jun-87 0832 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU OOPSLA Lisp and Object-Oriented Programming Workshop
C02339 00480 ∂03-Jun-87 1121 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Edwin source
C02340 00481 ∂03-Jun-87 1622 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Edwin source
C02343 00482 ∂04-Jun-87 2032 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu error-handler
C02345 00483 ∂05-Jun-87 0703 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU message passing
C02349 00484 ∂05-Jun-87 1612 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu error handler for cscheme (MIT)
C02351 00485 ∂06-Jun-87 2108 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu scoops--bug fixes 6/6
C02355 00486 ∂08-Jun-87 1920 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET number syntax and exactness
C02366 00487 ∂09-Jun-87 0226 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU Better late than never
C02389 00488 ∂09-Jun-87 1603 @MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU Scheme Source
C02391 00489 ∂10-Jun-87 1945 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Agenda
C02398 00490 ∂10-Jun-87 2055 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU attending
C02401 00491 ∂11-Jun-87 1013 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU on-campus accommodations
C02402 00492 ∂11-Jun-87 1755 @MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU Compiling Scheme on a hp200
C02405 00493 ∂11-Jun-87 2347 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: number syntax and exactness
C02414 00494 ∂12-Jun-87 1204 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Compiling Scheme on a hp200
C02417 00495 ∂12-Jun-87 1501 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU no free lunch
C02419 00496 ∂12-Jun-87 1513 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU directions
C02421 00497 ∂12-Jun-87 2016 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU no free lunch
C02423 00498 ∂14-Jun-87 0942 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu SCOOPS bug-fixes
C02431 00499 ∂15-Jun-87 1132 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU Books on Scheme
C02433 00500 ∂15-Jun-87 1437 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Session chair
C02435 00501 ∂18-Jun-87 0452 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCOOPS newsgroup? RSVP
C02438 00502 ∂18-Jun-87 1908 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET number syntax and exactness
C02447 00503 ∂23-Jun-87 1955 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU sundry
C02452 00504 ∂30-Jun-87 1800 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros
C02457 00505 ∂01-Jul-87 0728 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros
C02462 00506 ∂01-Jul-87 0836 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Macros
C02464 00507 ∂01-Jul-87 1046 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message, ignore
C02466 00508 ∂03-Jul-87 0737 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros again: read first
C02474 00509 ∂06-Jul-87 0517 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
C02477 00510 ∂06-Jul-87 0530 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
C02479 00511 ∂06-Jul-87 0845 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Macros again: read first
C02482 00512 ∂06-Jul-87 1147 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Tigger on Scheme
C02484 00513 ∂08-Jul-87 1607 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com structures
C02493 00514 ∂09-Jul-87 0853 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU re: structures
C02495 00515 ∂09-Jul-87 1935 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU structures
C02497 00516 ∂09-Jul-87 2321 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU re: structures
C02501 00517 ∂10-Jul-87 2311 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Minutes of the Scheme meeting etc.
C02527 00518 ∂12-Jul-87 1702 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU (DELAYED? <obj>) predicate
C02528 00519 ∂12-Jul-87 1711 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU DELAYED? predicate
C02533 00520 ∂15-Jul-87 1303 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu optional arguments
C02556 00521 ∂21-Jul-87 1512 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Recognizing QUOTE deemed harmful to EVAL's laziness
C02585 00522 ∂21-Jul-87 1956 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Recognizing QUOTE deemed harmful to EVAL's laziness
C02589 00523 ∂22-Jul-87 0919 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA modules
C02597 00524 ∂22-Jul-87 1259 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Recognizing QUOTE deemed harmful to EVAL's laziness
C02609 00525 ∂23-Jul-87 0018 @MC.LCS.MIT.EDU,@RELAY.CS.NET:stevev@tekchips.tek.com
C02612 00526 ∂23-Jul-87 0905 @MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU Recognizing QUOTE deemed harmful to EVAL's laziness
C02617 00527 ∂23-Jul-87 1017 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Recognizing QUOTE deemed harmful to EVAL's laziness
C02620 00528 ∂23-Jul-87 1207 @MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu futures in cscheme
C02624 00529 ∂23-Jul-87 1420 @MC.LCS.MIT.EDU:pierson@multimax.ARPA futures in cscheme
C02675 00530 ∂23-Jul-87 2003 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Recognizing QUOTE deemed harmful to EVAL's laziness
C02677 00531 ∂24-Jul-87 0337 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Recognising QUOTE deemed harmful to EVAL's laziness
C02682 00532 ∂24-Jul-87 0415 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Recognising QUOTE deemed harmful to EVAL's laziness
C02703 00533 ∂24-Jul-87 2128 @MC.LCS.MIT.EDU:narain%pluto@rand-unix.ARPA Quotation regarding QUOTE
C02706 00534 ∂29-Jul-87 0642 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU backquote semantics
C02709 00535 ∂12-Aug-87 1601 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Gabriel benchmarks in Scheme
C02713 00536 ∂12-Aug-87 1648 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com MacScheme+Toolsmith Version 1.0
C02718 00537 ∂12-Aug-87 1853 @MC.LCS.MIT.EDU:fateman@renoir.Berkeley.EDU Re: Gabriel benchmarks in Scheme
C02721 00538 ∂12-Aug-87 2227 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Gabriel benchmarks in Scheme
C02723 00539 ∂13-Aug-87 0900 @MC.LCS.MIT.EDU:jrl@ZERMATT.LCS.MIT.EDU Re: MacScheme+Toolsmith Version 1.0
C02725 00540 ∂13-Aug-87 1041 @MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU C Scheme
C02727 00541 ∂13-Aug-87 1528 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU Gabriel benchmarks in Scheme
C02731 00542 ∂13-Aug-87 2355 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com FRPOLY philosophy of benchmarking
C02735 00543 ∂14-Aug-87 0034 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com selective linking in Lisp
C02740 00544 ∂14-Aug-87 0128 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Gabriel benchmarks in Scheme
C02743 00545 ∂14-Aug-87 1757 @MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU Re: FRPOLY philosophy of benchmarking
C02745 00546 ∂14-Aug-87 1847 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu Re: selective linking in Lisp
C02747 00547 ∂16-Aug-87 1804 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu Re: Gabriel benchmarks in Scheme
C02750 00548 ∂16-Aug-87 1931 @MC.LCS.MIT.EDU:masinter.pa@Xerox.COM Re: selective linking in Lisp
C02753 00549 ∂17-Aug-87 0257 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Pausing garbage collection
C02755 00550 ∂18-Aug-87 0759 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Pausing garbage collection
C02757 00551 ∂19-Aug-87 1233 @MC.LCS.MIT.EDU:DOMAHONY%IRLEARN.BITNET@MITVMA.MIT.EDU Scheme Instructors Guide
C02759 00552 ∂20-Aug-87 1019 @MC.LCS.MIT.EDU:KURT%sungod.nsc.syr.edu@amax.npac.syr.edu C Scheme
C02761 00553 ∂22-Aug-87 2122 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme tutorial
C02764 00554 ∂27-Aug-87 0956 @MC.LCS.MIT.EDU:JELROBN%YALEVM.BITNET@MITVMA.MIT.EDU Please remove me from the mailing list.
C02766 00555 ∂27-Aug-87 2006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On-line Documentation
C02768 00556 ∂28-Aug-87 0533 @MC.LCS.MIT.EDU:DEMOL%NUSVM.BITNET@MITVMA.MIT.EDU info file
C02770 00557 ∂28-Aug-87 1102 @MC.LCS.MIT.EDU:wtm@buengc.bu.edu Please remove me from the mailing list
C02772 00558 ∂01-Sep-87 1825 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu getting scheme up on a 3B1
C02776 00559 ∂02-Sep-87 2333 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Looking for Scheme implementation
C02778 00560 ∂03-Sep-87 0013 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Thanks for comments about S&ICP book
C02780 00561 ∂03-Sep-87 0409 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu
C02782 00562 ∂03-Sep-87 0623 @MC.LCS.MIT.EDU:alpert@bu-cs.bu.edu Please remove this address from the mailing list
C02784 00563 ∂03-Sep-87 0730 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Looking for Scheme implementation
C02786 00564 ∂03-Sep-87 1147 @MC.LCS.MIT.EDU:ab@bu-cs.bu.edu Please remove my address from the mailing list
C02788 00565 ∂08-Sep-87 0845 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Preemptive garbage collection
C02791 00566 ∂09-Sep-87 2235 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message, ignore
C02792 00567 ∂10-Sep-87 0549 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On-line documentation on T and/or CSCHEME.
C02794 00568 ∂10-Sep-87 1444 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: Cscheme5 (In English)
C02797 00569 ∂14-Sep-87 1121 @MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU subscription
C02799 00570 ∂15-Sep-87 0209 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: SCHEME/COMMON-LISP compiler documentation
C02803 00571 ∂15-Sep-87 2042 @MC.LCS.MIT.EDU:munnari!cidam.oz.au!mg@uunet.UU.NET prolog in scheme
C02805 00572 ∂21-Sep-87 1400 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Wanted: Cscheme5 (In English)
C02808 00573 ∂22-Sep-87 0121 @MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU scoop wanted
C02811 00574 ∂24-Sep-87 2114 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu using editors
C02813 00575 ∂25-Sep-87 2254 @MC.LCS.MIT.EDU,@RELAY.CS.NET:shneider@cui.unige.chunet Any Scheme for Atari and/or Amiga ?
C02816 00576 ∂28-Sep-87 0922 @MC.LCS.MIT.EDU:EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU Scheme on Atari
C02819 00577 ∂28-Sep-87 1109 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Any Scheme for Atari and/or Amiga ?
C02821 00578 ∂30-Sep-87 0121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted Scoops for MacSheme (or help in porting)
C02824 00579 ∂02-Oct-87 0818 @MC.LCS.MIT.EDU:STCS8004%IRUCCVAX.BITNET@MITVMA.MIT.EDU FreeWare Scheme - IBM PS/2 or AT
C02827 00580 ∂03-Oct-87 0411 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ibm-pc compatible CScheme compiler
C02829 00581 ∂03-Oct-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme needed for the VAX-780
C02833 00582 ∂04-Oct-87 1113 @MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU R↑3RS
C02835 00583 ∂05-Oct-87 0936 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Tex and Scheme
C02836 00584 ∂05-Oct-87 1941 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R↑3RS
C02838 00585 ∂06-Oct-87 0753 @MC.LCS.MIT.EDU:U04Z%CBEBDA3T.BITNET@MITVMA.MIT.EDU Re: TeX and Scheme
C02840 00586 ∂06-Oct-87 1808 @MC.LCS.MIT.EDU:RKIRCHNE%carleton.edu@RELAY.CS.NET R↑3RS
C02844 00587 ∂07-Oct-87 0031 NET-ORIGIN@MC.LCS.MIT.EDU Re: TeX and Scheme
C02846 00588 ∂08-Oct-87 2114 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: R↑3RS
C02850 00589 ∂09-Oct-87 1738 @MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu Some corrections
C02853 00590 ∂13-Oct-87 1006 @MC.LCS.MIT.EDU:esosun!vor!jackson@sdcsvax.ucsd.edu Tao, Sues...
C02855 00591 ∂14-Oct-87 1850 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET MultiScheme
C02858 00592 ∂16-Oct-87 0402 @MC.LCS.MIT.EDU,@RELAY.CS.NET:sasha@COLGATE.CSNET visit on 11/9?
C02860 00593 ∂17-Oct-87 2226 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu CScheme question
C02864 00594 ∂17-Oct-87 2324 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MultiScheme
C02867 00595 ∂19-Oct-87 1350 @MC.LCS.MIT.EDU:bartlett@decwrl.dec.com Type inference in Scheme
C02869 00596 ∂20-Oct-87 0023 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Type inference in Scheme
C02873 00597 ∂21-Oct-87 1244 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme84 and SPS ftp
C02874 00598 ∂21-Oct-87 1357 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Semantic Prototyping System
C02877 00599 ∂21-Oct-87 1831 @MC.LCS.MIT.EDU:bartlett@decwrl.dec.com Type Inference in Scheme Summary
C02881 00600 ∂22-Oct-87 2305 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where can I get C-Scheme?
C02883 00601 ∂23-Oct-87 0604 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where can I get C-Scheme?
C02885 00602 ∂23-Oct-87 1035 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU C Scheme
C02887 00603 ∂23-Oct-87 2121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme in the real world
C02890 00604 ∂25-Oct-87 1905 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme in the real world
C02893 00605 ∂26-Oct-87 0853 @MC.LCS.MIT.EDU:andy%hobbes@ADS.ARPA applicability of "syntax" constructs
C02899 00606 ∂26-Oct-87 1526 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU applicability of "syntax" constructs
C02908 00607 ∂26-Oct-87 1544 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Scheme in the real world
C02910 00608 ∂27-Oct-87 0814 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: applicability of "syntax" constructs
C02912 00609 ∂27-Oct-87 0947 @MC.LCS.MIT.EDU:gls@Think.COM applicability of "syntax" constructs
C02914 00610 ∂27-Oct-87 1039 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Tao, Sues...
C02917 00611 ∂27-Oct-87 1259 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU applicability of "syntax" constructs
C02919 00612 ∂27-Oct-87 1323 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
C02927 00613 ∂27-Oct-87 1414 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: applicability of "syntax" constructs
C02930 00614 ∂28-Oct-87 0937 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu FX-87 is born
C02935 00615 ∂28-Oct-87 1726 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu applicability of "syntax" constructs
C02937 00616 ∂28-Oct-87 1834 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU RE: applicability of "syntax" mumble
C02939 00617 ∂28-Oct-87 1857 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU CALL
C02941 00618 ∂28-Oct-87 1921 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU Where can I get C-Scheme?
C02943 00619 ∂29-Oct-87 1003 @MC.LCS.MIT.EDU:JAR@ML.AI.MIT.EDU policy
C02949 00620 ∂29-Oct-87 1654 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where can I get C-Scheme?
C02952 00621 ∂30-Oct-87 1014 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET portability of SCHEME
C02955 00622 ∂30-Oct-87 1138 @MC.LCS.MIT.EDU:jdevries@ads.arpa Extend-Syntax for MacScheme
C02959 00623 ∂30-Oct-87 1407 @MC.LCS.MIT.EDU:sas@bfly-vax.bbn.com Extend-Syntax for MacScheme
C02960 00624 ∂31-Oct-87 1650 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Revised(3) report: could MIT post tex source for it ??
C02963 00625 ∂01-Nov-87 0928 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Revised(3) report: could MIT post tex source for it ??
C02966 00626 ∂02-Nov-87 1048 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu documentation?
C02968 00627 ∂03-Nov-87 1812 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Source for Scheme?
C02970 00628 ∂03-Nov-87 2205 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
C02973 00629 ∂04-Nov-87 1702 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Tigger on Scheme / correction
C02976 00630 ∂05-Nov-87 0426 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme / correction
C02979 00631 ∂06-Nov-87 0655 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Need refs for low-level (c/pascal) implementation of scheme
C02983 00632 ∂07-Nov-87 1221 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU,@REAGAN.AI.MIT.EDU,@BU-CS.BU.EDU:gjc@bucsf.bu.edu low level "how to scheme"
C02985 00633 ∂08-Nov-87 0241 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: low level "how to scheme"
C02987 00634 ∂08-Nov-87 1737 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Re: low level "how to scheme"
C02989 00635 ∂09-Nov-87 0112 @MC.LCS.MIT.EDU:mcvax!tcdcs!omahony@uunet.UU.NET Solution to Exercise 1.9
C02991 00636 ∂09-Nov-87 0151 @MC.LCS.MIT.EDU:trainor@CS.UCLA.EDU Re: Solution to Exercise 1.9
C02993 00637 ∂09-Nov-87 1033 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:dan@mitre-bedford.ARPA Removal from mailing list
C02995 00638 ∂09-Nov-87 1920 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Text
C02997 00639 ∂10-Nov-87 0953 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: SCOOPS info
C03000 00640 ∂10-Nov-87 2257 @MC.LCS.MIT.EDU:lls@mimsy.umd.edu Please remove me from the mailing list
C03002 00641 ∂12-Nov-87 2255 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu What is Scheme?
C03004 00642 ∂15-Nov-87 0159 NET-ORIGIN@MC.LCS.MIT.EDU Extend-Syntax for Everybody!
C03028 00643 ∂23-Nov-87 1739 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [net%TUB.BITNET: Pretty printer]
C03031 00644 ∂23-Nov-87 1816 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [net%TUB.BITNET: Questions]
C03034 00645 ∂24-Nov-87 0006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SICP Sources
C03036 00646 ∂24-Nov-87 0415 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU [net%TUB.BITNET: Questions]
C03040 00647 ∂24-Nov-87 1018 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: [net%TUB.BITNET: Questions]
C03044 00648 ∂24-Nov-87 1414 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [dyb: [net%TUB.BITNET: Questions]]
C03047 00649 ∂27-Nov-87 2137 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCHEME interpreter in Common Lisp?
C03050 00650 ∂30-Nov-87 1451 @MC.LCS.MIT.EDU:MUSE@XX.LCS.MIT.EDU PC Scheme
C03051 00651 ∂01-Dec-87 1234 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:MUSE@OZ.AI.MIT.EDU PC Scheme hardware interfacing
C03054 00652 ∂01-Dec-87 1510 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu The mini-SCHEME interpreter I've sent to some people
C03057 00653 ∂01-Dec-87 1610 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp is Crisp! Lisp is Crisp! Lisp is Crisp! Lisp is Crisp!
C03059 00654 ∂01-Dec-87 1645 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com two questions
C03063 00655 ∂02-Dec-87 1640 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: (Lisp is Crisp!)↑4
C03066 00656 ∂02-Dec-87 1858 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu data structures <--> functions
C03070 00657 ∂02-Dec-87 1953 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu in reply to "nested parens - just say no"
C03073 00658 ∂02-Dec-87 2130 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
C03075 00659 ∂03-Dec-87 1405 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu scheme benchmarks
C03077 00660 ∂03-Dec-87 1534 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Applicative languages? Anyone?
C03083 00661 ∂04-Dec-87 0219 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp Re: (Lisp is Crisp!)↑4
C03086 00662 ∂04-Dec-87 0254 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp in reply to "nested parens - just say no"
C03089 00663 ∂04-Dec-87 0327 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp data structures <--> functions
C03093 00664 ∂04-Dec-87 0401 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp data structures <--> functions
C03096 00665 ∂04-Dec-87 0911 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Applicative languages? Anyone?
C03099 00666 ∂04-Dec-87 1400 @MC.LCS.MIT.EDU:sullivan@marge.math.binghamton.edu ML
C03101 00667 ∂04-Dec-87 1455 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@MITVMA.MIT.EDU:PS33@MCGILLA.NETNORTH
C03104 00668 ∂04-Dec-87 1544 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU ML implementations
C03108 00669 ∂05-Dec-87 0210 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: data structures <--> functions
C03111 00670 ∂05-Dec-87 1042 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
C03115 00671 ∂07-Dec-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML
C03118 00672 ∂07-Dec-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML
C03121 00673 ∂08-Dec-87 1620 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
C03125 00674 ∂09-Dec-87 0932 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU data structures <--> functions
C03128 00675 ∂10-Dec-87 0750 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Request for MacScheme source for SCOOPS
C03130 00676 ∂10-Dec-87 1152 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Request for MacScheme source for SCOOPS
C03132 00677 ∂14-Dec-87 2214 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Applicative languages? Anyone?
C03137 00678 ∂14-Dec-87 2316 @MC.LCS.MIT.EDU,@RELAY.CS.NET:scheme-request@mc.lcs.mit.edu Re: Applicative languages? Anyone?
C03142 00679 ∂14-Dec-87 2354 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Request for MacScheme source for SCOOPS
C03144 00680 ∂15-Dec-87 1839 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Looking for C-Scheme
C03146 00681 ∂17-Dec-87 0430 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Re: SCOOPS for MacScheme
C03148 00682 ∂17-Dec-87 0642 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:ZZZO@DHVRRZN1.BITNET NOTE from ZZZO
C03150 00683 ∂17-Dec-87 0958 @MC.LCS.MIT.EDU:brando%linus@mitre-bedford.ARPA SCOOPS for MacScheme
C03152 00684 ∂17-Dec-87 1215 @MC.LCS.MIT.EDU:Esler.Opus@BCO-MULTICS.ARPA "box" data type in Chez Scheme.
C03154 00685 ∂18-Dec-87 0715 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Byte code speed.
C03157 00686 ∂18-Dec-87 0830 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ericson: MacScheme]
C03159 00687 ∂18-Dec-87 1024 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Speed
C03163 00688 ∂18-Dec-87 1401 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com Byte code speed
C03168 00689 ∂19-Dec-87 0739 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Speed
C03170 00690 ∂19-Dec-87 0932 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu MacScheme SCOOPS Update
C03173 00691 ∂19-Dec-87 1310 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme Standard
C03181 00692 ∂19-Dec-87 1453 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Common Lisp in Scheme?
C03184 00693 ∂23-Dec-87 1553 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:U09254@UICVM.BITNET Scheme on CMS?
C03186 00694 ∂23-Dec-87 1554 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Quasiquotation
C03188 00695 ∂23-Dec-87 1555 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com Object oriented programming in Scheme
C03192 00696 ∂23-Dec-87 1555 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Object oriented programming in Scheme
C03199 00697 ∂23-Dec-87 1555 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme on CMS?
C03202 00698 ∂23-Dec-87 1556 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Byte code speed
C03206 00699 ∂23-Dec-87 1556 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Some Remarks on Standardization (by someone who has been there)
C03223 00700 ∂23-Dec-87 1555 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Quasiquotation
C03225 00701 ∂23-Dec-87 1555 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Speed (of byte code interpreters)
C03228 00702 ∂23-Dec-87 1556 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme on CMS?
C03231 00703 ∂23-Dec-87 1556 @MC.LCS.MIT.EDU,@RELAY.CS.NET:feeley%iro.udem.cdn@UBC.CSNET Small Scheme compiler in Prolog...
C03234 00704 ∂23-Dec-87 1553 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Byte code speed
C03236 00705 ∂23-Dec-87 1554 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET RE: Scheme on Atari ST.
C03240 00706 ∂23-Dec-87 2218 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Why are case implementations so slow?
C03243 00707 ∂24-Dec-87 0656 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA A vote against standardization
C03246 00708 ∂24-Dec-87 1105 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Why are case implementations so slow?
C03249 00709 ∂27-Dec-87 1007 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU skim (a low fat implementation of Scheme)
C03252 00710 ∂27-Dec-87 1406 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU A vote against standardization
C03256 00711 ∂27-Dec-87 2214 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU A vote against standardization
C03258 00712 ∂28-Dec-87 1109 @MC.LCS.MIT.EDU:KMP@Riverside.SCRC.Symbolics.COM My vote against standardization
C03264 00713 ∂31-Dec-87 0150 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu problem bringing up Scheme 6.1
C03268 00714 ∂31-Dec-87 1010 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Question about load.
C03272 00715 ∂02-Jan-88 1250 @MC.LCS.MIT.EDU:ericson@csd16.nyu.edu Optimizing tail-recursive operations using jumps
C03276 00716 ∂05-Jan-88 1540 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu standardization
C03281 00717 ∂06-Jan-88 1117 @MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com Scheme Standardization
C03305 00718 ∂06-Jan-88 1330 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu getting C-Scheme running on Sun-3 / want Scoops info
C03308 00719 ∂06-Jan-88 1913 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU who contributes?
C03313 00720 ∂07-Jan-88 0508 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MDEBAR@BNANDP11.BITNET Scoops ?
C03315 00721 ∂07-Jan-88 1732 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scoops ?
C03317 00722 ∂07-Jan-88 1848 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the Amiga
C03319 00723 ∂08-Jan-88 1659 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga
C03322 00724 ∂11-Jan-88 0520 @MC.LCS.MIT.EDU:AHAAS@G.BBN.COM leaving
C03323 00725 ∂11-Jan-88 1355 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Problem with MIT-Scheme
C03328 00726 ∂13-Jan-88 1724 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Request for C-Scheme info
C03331 00727 ∂13-Jan-88 1808 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0 ???
C03333 00728 ∂15-Jan-88 1911 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: SYSV Scheme was Re: Request for C-Scheme info
C03341 00729 ∂20-Jan-88 0207 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Problems bringing up CScheme 6.1
C03346 00730 ∂21-Jan-88 1949 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Question: Are the GABRIEL-benchmarks translated into SCHEME already?
C03349 00731 ∂22-Jan-88 0903 @MC.LCS.MIT.EDU:rnoss%isis.educ.lon.ac.uk@NSS.Cs.Ucl.AC.UK
C03351 00732 ∂22-Jan-88 1116 @MC.LCS.MIT.EDU,@RELAY.CS.NET:tjfs@HPLB.CSNET Problems bringing up CScheme 6.1
C03357 00733 ∂22-Jan-88 1428 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Are the GABRIEL-benchmarks translated into SCHEME already?
C03360 00734 ∂23-Jan-88 0008 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu suggestions for the next revision of scheme
C03363 00735 ∂23-Jan-88 1209 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Next R*RS meeting...
C03365 00736 ∂25-Jan-88 0040 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET Next R*RS meeting...
C03367 00737 ∂27-Jan-88 0648 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA T a dialect of Scheme
C03373 00738 ∂27-Jan-88 0912 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Cleanup needed.
C03376 00739 ∂27-Jan-88 1933 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Versions of Scheme
C03378 00740 ∂28-Jan-88 0842 @MC.LCS.MIT.EDU:allen@lisperanto.bbn.com Parallel Versions of Scheme
C03380 00741 ∂28-Jan-88 0951 @MC.LCS.MIT.EDU:SGR@STONY-BROOK.SCRC.Symbolics.COM Parallel Versions of Scheme
C03384 00742 ∂28-Jan-88 1633 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Some RRRS comments/corrections
C03386 00743 ∂29-Jan-88 1423 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Amiga?
C03388 00744 ∂30-Jan-88 0554 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU testing, please ignore
C03389 00745 ∂30-Jan-88 0652 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU "Well, Stanley,here's another nice mess you've gotten us into."
C03393 00746 ∂30-Jan-88 1239 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU forwarded message from Dick Gabriel
C03399 00747 ∂30-Jan-88 1252 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU questions about X3 and Scheme
C03401 00748 ∂30-Jan-88 1447 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Clarifications
C03411 00749 ∂30-Jan-88 1517 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
C03413 00750 ∂30-Jan-88 1739 RPG ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
C03415 00751 ∂30-Jan-88 1740 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Bizarre Story
C03418 00752 ∂01-Feb-88 1550 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message
C03419 00753 ∂01-Feb-88 1753 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com re: Next R*RS metting...
C03422 00754 ∂02-Feb-88 1809 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Re: ISO vs ANSI vs IEEE vs X3 vs The Sons of Hercules
C03434 00755 ∂02-Feb-88 2101 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Scheme Standardization
C03438 00756 ∂03-Feb-88 0445 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA [jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK: Scheme standardization]
C03443 00757 ∂03-Feb-88 0556 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA "Well, Stanley,here's another nice mess you've gotten us into."
C03445 00758 ∂03-Feb-88 0626 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Bizarre Story
C03448 00759 ∂03-Feb-88 1238 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu [camp@mips.csc.ti.com: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization
C03460 00760 ∂03-Feb-88 1537 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Scheme Standardization
C03466 00761 ∂03-Feb-88 2039 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Scheme Standardization
C03468 00762 ∂04-Feb-88 0649 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA I modify my vote on Scheme standardization
C03470 00763 ∂04-Feb-88 0736 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Standardization
C03473 00764 ∂04-Feb-88 1220 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Standardization
C03476 00765 ∂04-Feb-88 1310 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Little Lisper
C03479 00766 ∂04-Feb-88 1443 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu more from Clyde Camp
C03481 00767 ∂04-Feb-88 1449 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu from Clyde Camp
C03489 00768 ∂04-Feb-88 1709 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Standardization
C03496 00769 ∂05-Feb-88 0053 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga, size constraints
C03499 00770 ∂05-Feb-88 0743 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU different lisp implementations confused.
C03502 00771 ∂05-Feb-88 1249 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu from Clyde Camp
C03507 00772 ∂05-Feb-88 1503 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Standardization
C03513 00773 ∂05-Feb-88 1612 @MC.LCS.MIT.EDU:gls@Think.COM Standardization
C03519 00774 ∂05-Feb-88 1621 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com Standardization
C03527 00775 ∂05-Feb-88 1912 @MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com Critical summary
C03530 00776 ∂06-Feb-88 1715 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU Can we standardize Scheme without killing it?
C03544 00777 ∂06-Feb-88 1957 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: Standardization
C03552 00778 ∂06-Feb-88 2255 @MC.LCS.MIT.EDU:gls@Think.COM Can we standardize Scheme without killing it?
C03557 00779 ∂07-Feb-88 0849 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU can we properly standardize a philosophy?
C03562 00780 ∂07-Feb-88 0940 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu Minimal Standard
C03564 00781 ∂07-Feb-88 0951 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu A vote for a minimal standard
C03566 00782 ∂07-Feb-88 1554 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Yale T (compiling)
C03569 00783 ∂07-Feb-88 1839 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Standardization
C03571 00784 ∂07-Feb-88 1855 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Can we standardize Scheme without killing it?
C03573 00785 ∂08-Feb-88 0637 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Scheme number notation
C03575 00786 ∂08-Feb-88 0649 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Wording to fix for LETREC
C03577 00787 ∂08-Feb-88 1449 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU !
C03579 00788 ∂08-Feb-88 1552 @MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU Scheme number notation
C03583 00789 ∂08-Feb-88 1619 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com A Minimalist Standard
C03587 00790 ∂08-Feb-88 1652 @MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU Scheme number notation
C03589 00791 ∂08-Feb-88 1659 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com Scheme Standardization
C03594 00792 ∂08-Feb-88 1840 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU !
C03596 00793 ∂08-Feb-88 2203 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU !
C03599 00794 ∂08-Feb-88 2250 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Can we standardize Scheme without killing it?
C03602 00795 ∂09-Feb-88 0715 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Can we standardize Scheme without killing it?
C03606 00796 ∂09-Feb-88 1831 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com A Minimalist Standard
C03611 00797 ∂10-Feb-88 0125 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization (meetings and relation to CL)
C03618 00798 ∂10-Feb-88 0641 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization (A conservative approach)
C03621 00799 ∂10-Feb-88 0734 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com A Minimalist Standard
C03624 00800 ∂11-Feb-88 0758 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU call for standardization meeting
C03628 00801 ∂11-Feb-88 1020 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA call for standardization meeting
C03630 00802 ∂11-Feb-88 1101 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA Meeting
C03632 00803 ∂11-Feb-88 1543 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu meeting
C03633 00804 ∂11-Feb-88 1558 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu is make-environment really necessary for packages?
C03637 00805 ∂11-Feb-88 1631 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu is make-environment really necessary for packages?
C03641 00806 ∂11-Feb-88 1948 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Yale T (compiling)
C03644 00807 ∂12-Feb-88 0357 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU KMP's reply to standardizaiotn meeting note
C03646 00808 ∂12-Feb-88 1508 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com Re: call for standardization meeting
C03648 00809 ∂15-Feb-88 0756 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU [hudak-paul@YALE.ARPA: Re: call for standardization meeting]
C03654 00810 ∂15-Feb-88 1012 NET-ORIGIN@MC.LCS.MIT.EDU Re: call for standardization
C03656 00811 ∂15-Feb-88 1725 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com (rationalize x y)
C03661 00812 ∂15-Feb-88 2019 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga, size constraints
C03666 00813 ∂15-Feb-88 2156 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Gabriel benchmarks in Scheme
C03670 00814 ∂16-Feb-88 0252 @MC.LCS.MIT.EDU:iuvax!dyb@ee.ecn.purdue.edu Re: call for standardization meeting
C03672 00815 ∂16-Feb-88 1242 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU (rationalize x y)
C03682 00816 ∂16-Feb-88 1440 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU DO in Scheme
C03686 00817 ∂16-Feb-88 1721 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU Standardization meeting on March 26
C03688 00818 ∂16-Feb-88 1756 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU standardization meeting March 26
C03690 00819 ∂16-Feb-88 1839 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: DO in Scheme
C03692 00820 ∂16-Feb-88 1910 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Standardization meeting on March 26
C03694 00821 ∂16-Feb-88 1923 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU DO in Scheme
C03696 00822 ∂17-Feb-88 0606 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU Standardization meeting on March 26
C03699 00823 ∂17-Feb-88 0904 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Named-let
C03700 00824 ∂17-Feb-88 1031 @MC.LCS.MIT.EDU,@RELAY.CS.NET:brooks@mips.csc.ti.com standardization meeting March 26
C03702 00825 ∂17-Feb-88 1044 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com standardization meeting March 26
C03704 00826 ∂17-Feb-88 1103 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU standardization meeting March 26
C03706 00827 ∂17-Feb-88 1806 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: standardization meeting March 26
C03708 00828 ∂18-Feb-88 0025 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for a 3B15/3B2
C03710 00829 ∂18-Feb-88 0057 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Standardization meeting on March 26
C03712 00830 ∂18-Feb-88 0119 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com standardization meeting March 26
C03715 00831 ∂18-Feb-88 0742 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu standardization meeting March 26
C03717 00832 ∂18-Feb-88 0756 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu standardization meeting
C03719 00833 ∂18-Feb-88 1055 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standardization meeting vote
C03721 00834 ∂18-Feb-88 1207 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Common Lisp functions for Scheme?
C03723 00835 ∂19-Feb-88 0416 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization meeting on March 26 and teleconferencing
C03725 00836 ∂19-Feb-88 1431 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Common Lisp functions for Scheme?
C03728 00837 ∂20-Feb-88 0053 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp Innards Wanted!
C03734 00838 ∂21-Feb-88 1021 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting -- vote early, vote often
C03736 00839 ∂21-Feb-88 1124 @MC.LCS.MIT.EDU:rabin.pa@Xerox.COM Re: Lisp Innards Wanted!
C03738 00840 ∂22-Feb-88 1008 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU nonorthogonality among list/vector/string procedures
C03740 00841 ∂22-Feb-88 1756 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Amiga
C03743 00842 ∂23-Feb-88 0726 @MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM Lisp representation data.
C03746 00843 ∂23-Feb-88 0803 @MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM As I was saying (superseding letter)
C03749 00844 ∂23-Feb-88 1115 @MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu comments on recent remarks
C03757 00845 ∂23-Feb-88 1142 @MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu standardization mtg agenda
C03763 00846 ∂23-Feb-88 1233 @MC.LCS.MIT.EDU:iuvax!duba@ee.ecn.purdue.edu standardization meeting
C03764 00847 ∂23-Feb-88 1837 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Scheme as an introductory programming language
C03768 00848 ∂24-Feb-88 1722 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com Standardization Mtg
C03771 00849 ∂25-Feb-88 0940 @MC.LCS.MIT.EDU:kempf@Sun.COM New Address
C03773 00850 ∂25-Feb-88 1140 @MC.LCS.MIT.EDU:HAILPERIN@Sushi.Stanford.EDU SICP query lang. compiler
C03775 00851 ∂25-Feb-88 1244 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU New Address
C03777 00852 ∂25-Feb-88 1710 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lisp Innards Wanted!
C03779 00853 ∂25-Feb-88 2323 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme book request
C03782 00854 ∂26-Feb-88 0002 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Info needed on scheme research
C03788 00855 ∂26-Feb-88 0137 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Scheme for a 3B15/3B2
C03791 00856 ∂26-Feb-88 0938 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: !
C03794 00857 ∂26-Feb-88 1944 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting, March 26
C03796 00858 ∂26-Feb-88 2248 @MC.LCS.MIT.EDU:mcvax!crcge3.cge.fr!adams@uunet.UU.NET SICP query lang. compiler
C03798 00859 ∂27-Feb-88 0710 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCOOPS
C03800 00860 ∂27-Feb-88 1707 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu xscheme
C03802 00861 ∂28-Feb-88 0857 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Standards
C03806 00862 ∂28-Feb-88 1211 @MC.LCS.MIT.EDU:mhs@HT.AI.MIT.EDU Info needed on Scheme research
C03808 00863 ∂28-Feb-88 1857 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu standardization meeting---travel and local arrangements
C03813 00864 ∂28-Feb-88 2236 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu looking for Cscheme on 3b1
C03815 00865 ∂29-Feb-88 2146 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu CScheme5.0 Availability (Was: Scheme for Amiga)
C03818 00866 ∂01-Mar-88 0056 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu does c scheme support X windows?
C03820 00867 ∂03-Mar-88 1009 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU xscheme
C03822 00868 ∂05-Mar-88 0717 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu moderator
C03824 00869 ∂06-Mar-88 0647 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: SCOOPS
C03826 00870 ∂07-Mar-88 1603 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Scheme as an introductory programming language
C03852 00871 ∂07-Mar-88 2003 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Eugene Kohlbecker's net address
C03854 00872 ∂08-Mar-88 1605 @MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET standardization meeting
C03856 00873 ∂08-Mar-88 1624 @MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET next report on Scheme
C03860 00874 ∂10-Mar-88 0550 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu search for IBM-PC (compatible) scheme
C03863 00875 ∂10-Mar-88 1722 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com false
C03874 00876 ∂10-Mar-88 1747 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: false
C03877 00877 ∂11-Mar-88 0910 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU false
C03882 00878 ∂11-Mar-88 0953 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
C03888 00879 ∂11-Mar-88 1014 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [cmb%DERRZE0.BITNET: Clyde Camp's PC Scheme utilities?]
C03891 00880 ∂11-Mar-88 1053 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU false
C03893 00881 ∂11-Mar-88 1132 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: false
C03895 00882 ∂11-Mar-88 1203 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU next report on Scheme
C03903 00883 ∂11-Mar-88 1326 @MC.LCS.MIT.EDU:andy%hobbes@ads.com Re: (SYMBOL? #t) ==> ?
C03908 00884 ∂11-Mar-88 1543 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Paging Simon Kaplan <kaplan@kaplan.cs.uiuc.edu>
C03910 00885 ∂11-Mar-88 1855 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
C03914 00886 ∂11-Mar-88 1920 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (SYMBOL? #t) ==> ?
C03918 00887 ∂11-Mar-88 1943 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
C03920 00888 ∂11-Mar-88 2006 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (SYMBOL? #t) ==> ?
C03926 00889 ∂11-Mar-88 2208 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: (SYMBOL? #t) ==> ?
C03931 00890 ∂11-Mar-88 2218 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: false
C03934 00891 ∂12-Mar-88 0942 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme on IBM PC
C03936 00892 ∂12-Mar-88 1123 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu travel plans
C03939 00893 ∂12-Mar-88 1459 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme and C
C03941 00894 ∂14-Mar-88 0529 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme and C
C03943 00895 ∂14-Mar-88 1001 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Types in Scheme
C03946 00896 ∂14-Mar-88 1037 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU false
C03948 00897 ∂14-Mar-88 1055 @MC.LCS.MIT.EDU:daniel@mojave.stanford.edu Types in Scheme
C03951 00898 ∂14-Mar-88 1917 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Types in Scheme
C03956 00899 ∂16-Mar-88 1201 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Re: false, (symbol #t), etc
C03964 00900 ∂16-Mar-88 1201 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU t and nil
C03967 00901 ∂16-Mar-88 1201 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Types in Scheme
C03970 00902 ∂16-Mar-88 1230 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA t and nil
C03973 00903 ∂17-Mar-88 2338 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ML
C03975 00904 ∂18-Mar-88 0525 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting
C03977 00905 ∂18-Mar-88 0717 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU ML
C03979 00906 ∂18-Mar-88 0930 @MC.LCS.MIT.EDU:dbm%research@att.arpa ML compiler -- Standard ML of NJ
C03982 00907 ∂19-Mar-88 1104 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the PC
C03984 00908 ∂20-Mar-88 0847 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Scheme for the PC
C03986 00909 ∂20-Mar-88 1224 @MC.LCS.MIT.EDU:dybvig@silver.bacs.indiana.edu meeting
C03988 00910 ∂21-Mar-88 0956 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Meeting
C03992 00911 ∂21-Mar-88 1503 NET-ORIGIN@MC.LCS.MIT.EDU Read Macros's in Scheme ?
C03994 00912 ∂22-Mar-88 0647 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [OMAHONY: Clyde Camp's Utilities]
C03996 00913 ∂22-Mar-88 0722 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU editing
C03998 00914 ∂22-Mar-88 1235 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: xscheme
C04000 00915 ∂23-Mar-88 1510 NET-ORIGIN@MC.LCS.MIT.EDU How can you do things like ?X -> (*var* x) without Read Macros ?
C04003 00916 ∂24-Mar-88 0933 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [camp: [OMAHONY: Clyde Camp's Utilities]]
C04007 00917 ∂24-Mar-88 1009 @MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU Re: Scheme as an introductory programming language
C04010 00918 ∂24-Mar-88 1213 @MC.LCS.MIT.EDU:bh@ernie.Berkeley.EDU How many Schemes can your Vax take?
C04013 00919 ∂24-Mar-88 1420 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: How can you do things like ?X -> (*var* x) without Read Macros ?
C04015 00920 ∂24-Mar-88 1616 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@buita.BU.EDU How can you do things like ?X -> (*var* x) without Read Macros ?
C04019 00921 ∂26-Mar-88 1627 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Saving a continuation
C04021 00922 ∂26-Mar-88 1700 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MIT C-Scheme design info
C04024 00923 ∂27-Mar-88 1046 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: T operations, etc
C04028 00924 ∂27-Mar-88 1202 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where can I get Scheme?
C04030 00925 ∂27-Mar-88 1421 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu T operations, etc
C04035 00926 ∂28-Mar-88 0728 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU T discussion and newsgroups
C04039 00927 ∂28-Mar-88 1117 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU CLOS Error Terminology
C04048 00928 ∂28-Mar-88 1240 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM More for R4RS
C04051 00929 ∂30-Mar-88 1005 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT C Scheme design info
C04064 00930 ∂31-Mar-88 0022 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu availability of Scheme on Atari STs
C04066 00931 ∂31-Mar-88 0619 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MIKEMAC@UNB.BITNET Porting Scheme to our IBM3090 running MVS/XA
C04069 00932 ∂03-Apr-88 2327 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT C Scheme design info
C04083 00933 ∂05-Apr-88 1304 @MC.LCS.MIT.EDU:SCHREQ@AI.AI.MIT.EDU test message, ignore
C04085 00934 ∂05-Apr-88 1908 @MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu
C04087 00935 ∂05-Apr-88 1937 @MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu
C04089 00936 ∂06-Apr-88 1652 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU forwarded message from Clyde Camp
C04094 00937 ∂08-Apr-88 1544 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standarization
C04099 00938 ∂09-Apr-88 0911 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu emacs/scheme
C04102 00939 ∂10-Apr-88 2052 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Bibliography database (BIB/REFER format)
C04125 00940 ∂18-Apr-88 0629 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA SchemeTeX---Simple support for literate programming in Lisp.
C04128 00941 ∂19-Apr-88 0021 @MC.LCS.MIT.EDU:gleicher@cs.duke.edu Scheme Implementation for Macintosh 2
C04130 00942 ∂19-Apr-88 0905 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Scheme Implementation for Macintosh 2
C04132 00943 ∂20-Apr-88 0129 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Scheme on SysVr2
C04135 00944 ∂20-Apr-88 0932 @MC.LCS.MIT.EDU:mimsy!cvl!dolqci!irs3!spl1!richp1!richsun!craig@rutgers.edu Scheme Implementation for Macintosh 2
C04138 00945 ∂20-Apr-88 1149 @MC.LCS.MIT.EDU:eric%s3landrew@scubed.ARPA Read Macros in PC-Scheme??
C04140 00946 ∂20-Apr-88 1234 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Is there a new version of T ?
C04142 00947 ∂20-Apr-88 2027 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On Beyond Abelson & Sussman
C04145 00948 ∂20-Apr-88 2335 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Lisp according to one Pascal programmer
C04150 00949 ∂21-Apr-88 0010 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
C04154 00950 ∂21-Apr-88 1030 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu C Scheme Documentation
C04158 00951 ∂21-Apr-88 1121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Engines/SCOOPS in T?
C04161 00952 ∂21-Apr-88 1448 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Implementation for Macintosh 2
C04164 00953 ∂21-Apr-88 1548 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
C04167 00954 ∂21-Apr-88 2032 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where to mail bugs?
C04169 00955 ∂21-Apr-88 2339 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Where to mail bugs?
C04171 00956 ∂22-Apr-88 2216 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Followup to Stoy's book?
C04174 00957 ∂22-Apr-88 2249 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
C04178 00958 ∂23-Apr-88 2239 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU small scheme implementation.
C04182 00959 ∂24-Apr-88 1313 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu collect macro
C04184 00960 ∂25-Apr-88 1933 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU SIOD release 1.1
C04187 00961 ∂26-Apr-88 0510 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET SIOD 1.1
C04189 00962 ∂26-Apr-88 1435 SCHREQ@MC.LCS.MIT.EDU Cross mailing between UseNet and the ArpaNet
C04191 00963 ∂26-Apr-88 1525 ``Update functions'' in Scheme.
C04196 00964 ∂27-Apr-88 1109 ``Update functions'' in Scheme.
C04201 00965 ∂27-Apr-88 1607 @MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU SIOD release 1.1
C04202 00966 ∂27-Apr-88 1923 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM R3RS number syntax
C04206 00967 ∂27-Apr-88 1952 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Proposals for R4RS
C04209 00968 ∂27-Apr-88 2212 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
C04212 00969 ∂28-Apr-88 0247 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where to mail bugs?
C04215 00970 ∂28-Apr-88 0844 @MC.LCS.MIT.EDU:sdawkins%hpda@hplabs.HP.COM delete from list
C04217 00971 ∂28-Apr-88 1957 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU SIOD release 1.2 (28-APR-88).
C04220 00972 ∂29-Apr-88 1136 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM TI-scheme on PS/2
C04222 00973 ∂29-Apr-88 1733 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Extending the address space of MIT Cscheme
C04225 00974 ∂29-Apr-88 1828 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Questions on Scheme treatment of numbers
C04229 00975 ∂30-Apr-88 1352 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Biblio.
C04232 00976 ∂01-May-88 1340 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect macro
C04236 00977 ∂01-May-88 1918 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU siod release 1.3
C04239 00978 ∂02-May-88 0302 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SIOD release 1.1
C04242 00979 ∂02-May-88 0332 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: R3RS number syntax
C04247 00980 ∂02-May-88 1132 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Re: Extending the address space of MIT Cscheme
C04249 00981 ∂03-May-88 1121 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
C04252 00982 ∂03-May-88 2313 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Extending the address space of MIT Cscheme
C04255 00983 ∂04-May-88 0051 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Extending the address space of MIT Cscheme (long reply)
C04266 00984 ∂04-May-88 0808 @MC.LCS.MIT.EDU:mhwu@DUMBO.AI.MIT.EDU More flames about CScheme
C04271 00985 ∂04-May-88 0929 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ``Update functions'' in Scheme.
C04275 00986 ∂04-May-88 1506 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Extending the address space of MIT Cscheme (long reply)
C04293 00987 ∂04-May-88 1622 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: R3RS number syntax
C04296 00988 ∂04-May-88 1917 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Extending the address space of MIT Cscheme (long reply)
C04313 00989 ∂04-May-88 2010 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Unpleasantness
C04323 00990 ∂05-May-88 0713 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM Re: Extending the address space of MIT Cscheme (long reply)
C04329 00991 ∂05-May-88 0819 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM Extending the address space of MIT Cscheme (long reply)
C04332 00992 ∂05-May-88 0913 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Extending the address space of MIT Cscheme (long reply)
C04338 00993 ∂05-May-88 0947 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Extending the address space of MIT Cscheme
C04341 00994 ∂05-May-88 1025 @MC.LCS.MIT.EDU:gls@Think.COM Extending the address space of MIT Cscheme (semi-long reply)
C04346 00995 ∂05-May-88 1113 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Unpleasantness
C04350 00996 ∂05-May-88 1153 @MC.LCS.MIT.EDU:gls@Think.COM Extending the address space of MIT Cscheme (long reply)
C04354 00997 ∂05-May-88 1406 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
C04359 00998 ∂05-May-88 1447 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
C04368 00999 ∂05-May-88 1542 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Extending the address space of MIT Cscheme
C04371 01000 ∂05-May-88 1702 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Unpleasantness
C04375 01001 ∂05-May-88 1745 @MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU Thanks for CScheme I like it
C04377 01002 ∂05-May-88 2110 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Extending the address space of MIT Cscheme (semi-long reply)
C04382 01003 ∂05-May-88 2145 @MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu Extending the address space of MIT Cscheme (long reply)
C04387 01004 ∂05-May-88 2319 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU Maclisp revisited.
C04391 01005 ∂05-May-88 2353 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU C and Cscheme.
C04394 01006 ∂06-May-88 0151 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Extending the address space of MIT Cscheme (long reply)
C04396 01007 ∂06-May-88 0249 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu set in Scheme?
C04398 01008 ∂06-May-88 0326 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: compatibility/elegance & *theory*
C04407 01009 ∂06-May-88 0455 @MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
C04412 01010 ∂06-May-88 1130 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: set in Scheme?
C04416 01011 ∂06-May-88 1225 @MC.LCS.MIT.EDU:allen@LISPERANTO.BBN.COM Thanks for CScheme I like it
C04420 01012 ∂06-May-88 1408 @MC.LCS.MIT.EDU:fischer.pa@Xerox.COM Re: Declarations and speed
C04423 01013 ∂06-May-88 1521 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU set in Scheme?
C04426 01014 ∂07-May-88 0232 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : set in Scheme
C04429 01015 ∂07-May-88 1503 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : set in Scheme
C04432 01016 ∂07-May-88 1644 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: siod release 1.3
C04435 01017 ∂08-May-88 1917 @MC.LCS.MIT.EDU:cire@clash.cisco.com Please remove me.
C04437 01018 ∂09-May-88 1317 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
C04439 01019 ∂09-May-88 1537 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ``Update functions'' in Scheme.
C04444 01020 ∂09-May-88 1918 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
C04451 01021 ∂10-May-88 0109 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
C04455 01022 ∂10-May-88 0321 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU ``Update functions'' in Scheme.
C04460 01023 ∂10-May-88 0822 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ``Update functions'' in Scheme.
C04465 01024 ∂10-May-88 0925 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: set in Scheme?
C04471 01025 ∂10-May-88 1020 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
C04479 01026 ∂10-May-88 1111 @MC.LCS.MIT.EDU,@WAIKATO.S4CC.Symbolics.COM,@JEWEL-CAVE.S4CC.Symbolics.COM:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
C04482 01027 ∂10-May-88 1203 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET Re: ``Update functions'' in Scheme.
C04486 01028 ∂10-May-88 1716 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: Update functions in Scheme.
C04492 01029 ∂10-May-88 1917 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
C04496 01030 ∂10-May-88 1953 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
C04501 01031 ∂10-May-88 2256 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU ``Update functions'' in Scheme.
C04503 01032 ∂11-May-88 0506 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:IS7397@JPNSUT30.BITNET
C04505 01033 ∂11-May-88 1331 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
C04509 01034 ∂11-May-88 1913 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU ``Update functions'' in POP2.
C04511 01035 ∂11-May-88 2010 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU cells
C04515 01036 ∂11-May-88 2149 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU ``Update functions'' in Scheme.
C04519 01037 ∂12-May-88 0004 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: cells
C04522 01038 ∂12-May-88 0225 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Meeting 24 July 1988
C04526 01039 ∂12-May-88 0418 @MC.LCS.MIT.EDU:sas@alice.bbn.com ``Update functions'' in POP2.
C04528 01040 ∂12-May-88 0721 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Meeting 24 July 1988
C04531 01041 ∂12-May-88 0848 @MC.LCS.MIT.EDU:mac@uvacs.cs.virginia.edu Re: ``Update functions'' in Scheme.
C04534 01042 ∂12-May-88 1138 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU CPS
C04536 01043 ∂12-May-88 1545 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: ``Update functions'' in POP2.
C04543 01044 ∂12-May-88 1732 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Cells
C04547 01045 ∂12-May-88 1815 @MC.LCS.MIT.EDU:aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK updaters in POP-11/POP-2
C04557 01046 ∂12-May-88 1915 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU Cells
C04561 01047 ∂12-May-88 2106 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Updaters in Pop (reply to query)
C04566 01048 ∂13-May-88 0358 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu Snowbird
C04567 01049 ∂13-May-88 0732 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET readable code to SET recordfields
C04571 01050 ∂13-May-88 0840 @MC.LCS.MIT.EDU:gls@Think.COM cells
C04575 01051 ∂13-May-88 1052 @MC.LCS.MIT.EDU:gls@Think.COM Cells
C04577 01052 ∂13-May-88 1202 @MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU Cells
C04579 01053 ∂13-May-88 1418 @MC.LCS.MIT.EDU:gls@Think.COM Cells
C04582 01054 ∂13-May-88 1503 @MC.LCS.MIT.EDU:edsel!jlm@labrea.stanford.edu Cells
C04584 01055 ∂13-May-88 1617 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Change proposals
C04587 01056 ∂15-May-88 0019 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MIT Scheme for Unix
C04589 01057 ∂15-May-88 1750 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT Scheme for Unix
C04592 01058 ∂16-May-88 1258 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: cells
C04595 01059 ∂16-May-88 1337 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
C04599 01060 ∂16-May-88 1446 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU MIT Scheme for Unix
C04602 01061 ∂16-May-88 1446 @MC.LCS.MIT.EDU:probertson@MEAD.SCRC.Symbolics.COM Re: cells
C04604 01062 ∂16-May-88 1645 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU Re : set in Scheme
C04607 01063 ∂17-May-88 1336 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Uses of SET
C04612 01064 ∂17-May-88 1336 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT Scheme for Unix
C04615 01065 ∂17-May-88 1542 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standardization meeting
C04620 01066 ∂17-May-88 2034 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu scheme on AIX
C04622 01067 ∂18-May-88 1932 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@bostonu.BITNET Boston Sigplan Seminar on Continuation Semantics
C04630 01068 ∂19-May-88 0832 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: Cells
C04632 01069 ∂19-May-88 0908 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: ''Update functions'' in Scheme.
C04635 01070 ∂20-May-88 0959 @MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM Re: ''Update functions'' in Scheme.
C04638 01071 ∂20-May-88 1146 @MC.LCS.MIT.EDU:gls@Think.COM ''Update functions'' in Scheme.
C04641 01072 ∂20-May-88 1224 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM A Proposal for Environments in Scheme
C04671 01073 ∂20-May-88 1305 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:WROGERS@UDCVAX.BITNET Sources to C-Scheme
C04673 01074 ∂23-May-88 0824 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com A Proposal for Environments in Scheme
C04678 01075 ∂23-May-88 1101 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu first class variables.
C04682 01076 ∂23-May-88 1147 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04688 01077 ∂23-May-88 1210 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04713 01078 ∂23-May-88 1315 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU A Proposal for Environments in Scheme
C04716 01079 ∂23-May-88 1323 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [Pavel.pa: A Proposal for Environments in Scheme]
C04746 01080 ∂23-May-88 1349 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU A Proposal for Environments in Scheme
C04748 01081 ∂23-May-88 1404 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04752 01082 ∂23-May-88 1421 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04755 01083 ∂23-May-88 1508 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Floyd-Hoare Verification Harmful??
C04759 01084 ∂23-May-88 1620 @MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM Floyd-Hoare Verification Harmful??
C04765 01085 ∂23-May-88 1717 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: A Proposal for Environments in Scheme
C04771 01086 ∂23-May-88 1807 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU "Same Problem all these years" in Floyd-Hoare Verification
C04774 01087 ∂23-May-88 1904 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04777 01088 ∂24-May-88 0906 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA A Proposal for Environments in Scheme
C04780 01089 ∂24-May-88 1019 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Proposed modifications to R3RS
C04788 01090 ∂25-May-88 0554 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com Proposed modifications to R3RS
C04793 01091 ∂25-May-88 0758 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu HELP ME!!!
C04797 01092 ∂25-May-88 0901 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Proposed modifications to R3RS
C04800 01093 ∂25-May-88 0924 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: HELP ME!!!
C04806 01094 ∂25-May-88 2134 @MC.LCS.MIT.EDU:gls@Think.COM [wand@corwin.ccs.northeastern.edu: ''Update functions'' in Scheme.]
C04809 01095 ∂26-May-88 0053 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET Macros lexcial scope
C04813 01096 ∂26-May-88 0207 @MC.LCS.MIT.EDU:gls@Think.COM Proposed modifications to R3RS
C04816 01097 ∂26-May-88 0257 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Omission in R↑3.5 LETREC description?
C04819 01098 ∂26-May-88 0307 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Proposed modifications to R3RS
C04826 01099 ∂26-May-88 0930 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Macros lexcial scope
C04829 01100 ∂26-May-88 1045 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Macros lexcial scope
C04834 01101 ∂26-May-88 1140 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: Proposed modifications to RRRS
C04838 01102 ∂26-May-88 1151 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: Proposed modifications to R3RS
C04841 01103 ∂26-May-88 1207 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Proposed modifications to RRRS
C04844 01104 ∂26-May-88 1329 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
C04855 01105 ∂26-May-88 2005 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU A Proposal for Environments in Scheme
C04860 01106 ∂27-May-88 0025 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU modules
C04871 01107 ∂27-May-88 0529 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: HELP ME!!!
C04873 01108 ∂27-May-88 0628 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Proposed modifications to RRRS
C04876 01109 ∂27-May-88 1422 @MC.LCS.MIT.EDU:reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu Floyd-Hoare Verification Harmful??
C04881 01110 ∂27-May-88 1614 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Miranda (functional programming system)
C04884 01111 ∂30-May-88 1727 @MC.LCS.MIT.EDU:amgreene@athena.MIT.EDU PLEASE remove me from this list
C04886 01112 ∂31-May-88 0901 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu collect special form for streams
C04889 01113 ∂31-May-88 1340 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:C24880RL@WUVMD.BITNET Request for information
C04891 01114 ∂31-May-88 2124 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Macros in lexically scoped lisps
C04896 01115 ∂31-May-88 2206 @MC.LCS.MIT.EDU:howell%community-chest.mitre.org@gateway.mitre.org Miranda
C04898 01116 ∂01-Jun-88 0016 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
C04901 01117 ∂01-Jun-88 1417 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
C04906 01118 ∂01-Jun-88 1525 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Bug in R3RS
C04909 01119 ∂01-Jun-88 1925 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C04913 01120 ∂01-Jun-88 1943 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C04915 01121 ∂02-Jun-88 1252 @MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: A Proposal for Environments in Scheme
C04925 01122 ∂03-Jun-88 0738 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Oaklisp
C04927 01123 ∂03-Jun-88 1114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
C04932 01124 ∂03-Jun-88 1227 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C04937 01125 ∂03-Jun-88 1650 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
C04941 01126 ∂03-Jun-88 1726 @MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: opaque type proposal
C04946 01127 ∂03-Jun-88 1741 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C04948 01128 ∂03-Jun-88 2338 @MC.LCS.MIT.EDU:jrl@VX.LCS.MIT.EDU Re: Re: opaque type proposal
C04951 01129 ∂04-Jun-88 0132 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU sleazoid programming
C04953 01130 ∂04-Jun-88 0850 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
C04956 01131 ∂04-Jun-88 1236 ALAN@MC.LCS.MIT.EDU opaque type proposal
C04958 01132 ∂06-Jun-88 1151 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C04963 01133 ∂06-Jun-88 1904 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU report sources
C04965 01134 ∂06-Jun-88 1935 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
C04975 01135 ∂06-Jun-88 2011 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM On Modules in Scheme: Principles and Proposals
C04991 01136 ∂06-Jun-88 2049 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM R(3.5)RS Question
C04993 01137 ∂07-Jun-88 1433 @MC.LCS.MIT.EDU:gls@Think.COM Re: opaque type proposal
C04997 01138 ∂07-Jun-88 2046 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: opaque type proposal
C05002 01139 ∂07-Jun-88 2046 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
C05006 01140 ∂08-Jun-88 1126 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU report sources
C05008 01141 ∂08-Jun-88 1519 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Call for publishable code!
C05012 01142 ∂09-Jun-88 0417 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU siod-v1.3 now in comp.sources.unix
C05015 01143 ∂09-Jun-88 1443 @MC.LCS.MIT.EDU:Leo_Vetter.WBST207V@Xerox.COM Remove from Distribution
C05017 01144 ∂11-Jun-88 1953 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Scheme modules using HERALD, MODULE, and IMPORT.
C05024 01145 ∂13-Jun-88 0756 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
C05026 01146 ∂13-Jun-88 0945 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com (define x)
C05028 01147 ∂13-Jun-88 1235 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (define x)
C05030 01148 ∂13-Jun-88 1420 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu Full Specification
C05039 01149 ∂13-Jun-88 1446 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
C05042 01150 ∂13-Jun-88 1650 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com Full Specification
C05046 01151 ∂13-Jun-88 1946 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Full Specification
C05051 01152 ∂14-Jun-88 0108 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Full Specification
C05057 01153 ∂14-Jun-88 1104 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: Full Specification
C05063 01154 ∂14-Jun-88 1204 @MC.LCS.MIT.EDU:Stever@IVORY.S4CC.Symbolics.COM Online copy of the RR..R report?
C05065 01155 ∂14-Jun-88 1250 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Scheme modules using HERALD, MODULE, and IMPORT.
C05068 01156 ∂14-Jun-88 2031 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu char-ready? => read-char-ready?
C05070 01157 ∂15-Jun-88 0643 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU (define x)
C05073 01158 ∂15-Jun-88 0711 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU char-ready? => read-char-ready?
C05075 01159 ∂15-Jun-88 0755 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA seconds-after-J2000.0
C05077 01160 ∂15-Jun-88 0911 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU seconds-after-J2000.0
C05081 01161 ∂15-Jun-88 1044 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
C05084 01162 ∂15-Jun-88 1259 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu More on Full Specification
C05092 01163 ∂15-Jun-88 1614 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM alternate track on the char-ready? issue
C05097 01164 ∂15-Jun-88 1645 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU alternate track on the char-ready? issue
C05100 01165 ∂15-Jun-88 1658 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
C05104 01166 ∂15-Jun-88 1850 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM A couple more details
C05110 01167 ∂15-Jun-88 1952 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: More on Full Specification
C05115 01168 ∂15-Jun-88 2004 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU days-after-J2000.0
C05118 01169 ∂16-Jun-88 0216 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
C05122 01170 ∂16-Jun-88 0653 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Dependency analysis on internal DEFINE's
C05126 01171 ∂16-Jun-88 1058 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP 88 Registration Forms
C05130 01172 ∂16-Jun-88 1131 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
C05133 01173 ∂16-Jun-88 1316 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: More on Full Specification
C05137 01174 ∂16-Jun-88 1332 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com new wording for eqv?
C05145 01175 ∂16-Jun-88 1346 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com formal semantics of numeric constants
C05154 01176 ∂16-Jun-88 1422 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
C05157 01177 ∂17-Jun-88 0530 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
C05160 01178 ∂17-Jun-88 0811 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU parallel argument evaluation
C05164 01179 ∂17-Jun-88 0833 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: parallel argument evaluation
C05167 01180 ∂17-Jun-88 0908 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU parallel argument evaluation
C05170 01181 ∂17-Jun-88 0946 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: parallel argument evaluation
C05172 01182 ∂17-Jun-88 1005 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU char-ready? => read-char-ready?
C05174 01183 ∂17-Jun-88 1017 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Online copy of the RR..R report?
C05176 01184 ∂17-Jun-88 1056 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU Re: parallel argument evaluation
C05179 01185 ∂17-Jun-88 1148 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU new wording for eqv?
C05183 01186 ∂17-Jun-88 1204 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: char-ready? => read-char-ready?
C05185 01187 ∂17-Jun-88 1214 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: char-ready? => read-char-ready?
C05188 01188 ∂17-Jun-88 1314 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM new wording for eqv?
C05195 01189 ∂17-Jun-88 1350 @MC.LCS.MIT.EDU:gls@Think.COM days-after-J2000.0
C05198 01190 ∂17-Jun-88 1537 @MC.LCS.MIT.EDU:gls@Think.COM new wording for eqv?
C05201 01191 ∂17-Jun-88 1718 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Re: Dependency analysis on internal DEFINE's
C05207 01192 ∂17-Jun-88 1729 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Re: More on Full Specification
C05215 01193 ∂17-Jun-88 1740 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl Re: days-after-J2000.0
C05217 01194 ∂18-Jun-88 0057 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Lisps for Parallel Machines
C05224 01195 ∂18-Jun-88 0417 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: Dependency analysis on internal DEFINE's
C05230 01196 ∂20-Jun-88 0810 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Meetings
C05231 01197 ∂21-Jun-88 0943 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Optionals, version 1
C05237 01198 ∂21-Jun-88 0953 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Multiple values, version 1
C05242 01199 ∂21-Jun-88 1004 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com eqv? version 2
C05252 01200 ∂21-Jun-88 1713 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Oaklisp
C05255 01201 ∂22-Jun-88 0030 @MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu Re: Oaklisp
C05258 01202 ∂22-Jun-88 1348 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com More on Full Specification
C05265 01203 ∂22-Jun-88 1400 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com (define x)
C05268 01204 ∂22-Jun-88 1629 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com List of attendees (tentative)
C05272 01205 ∂22-Jun-88 1934 @MC.LCS.MIT.EDU,@HELIOS.NORTHEASTERN.EDU:wand@corwin.ccs.northeastern.edu new wording for eqv?
C05276 01206 ∂23-Jun-88 0006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Oaklisp
C05279 01207 ∂23-Jun-88 0853 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: (define x)
C05281 01208 ∂23-Jun-88 0934 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
C05283 01209 ∂24-Jun-88 0733 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu formal proposal: A Modified Procedural Interface
C05302 01210 ∂24-Jun-88 0745 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu informal proposal: A Modified Procedural Interface
C05316 01211 ∂25-Jun-88 1451 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU (define x)
C05319 01212 ∂25-Jun-88 1519 @MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu FTPing Oaklisp
C05322 01213 ∂26-Jun-88 0233 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@cs.brandeis.edu More on Full Specification
C05326 01214 ∂27-Jun-88 0847 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM (define x)
C05330 01215 ∂29-Jun-88 0121 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:UHRZB001@DBIUNI11.BITNET
C05332 01216 ∂29-Jun-88 1135 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Production quality Scheme compilers
C05334 01217 ∂02-Jul-88 1304 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu ML info
C05336 01218 ∂03-Jul-88 1328 @MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu Scheme for SUN 386i
C05338 01219 ∂04-Jul-88 1653 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML info
C05341 01220 ∂04-Jul-88 2357 @MC.LCS.MIT.EDU:goldberg@goldberg.cs.nyu.edu Re: ML info
C05343 01221 ∂06-Jul-88 0938 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Miranda (correction)
C05345 01222 ∂06-Jul-88 1439 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl sanity check: <=, >=
C05348 01223 ∂06-Jul-88 1543 @MC.LCS.MIT.EDU:gls@Think.COM sanity check: <=, >=
C05351 01224 ∂07-Jul-88 1929 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: Multiple values, Version 1
C05353 01225 ∂08-Jul-88 0047 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU informal proposal: A Modified Procedural Interface (LONG)
C05362 01226 ∂10-Jul-88 1405 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: Multiple values, Version 1
C05364 01227 ∂11-Jul-88 1011 @MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU duplicated formals
C05366 01228 ∂11-Jul-88 1416 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Documentation for T
C05368 01229 ∂12-Jul-88 0947 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP Registration -- FINAL CALL
C05373 01230 ∂14-Jul-88 1526 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com agenda
C05392 01231 ∂14-Jul-88 2021 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Proposals compendium
C05394 01232 ∂14-Jul-88 2043 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com time & place of R*RS authors' meeting
C05397 01233 ∂15-Jul-88 0457 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Replace LETREC with "relaxed" internal DEFINES.
C05400 01234 ∂15-Jul-88 1855 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu OBJ3 Release
C05410 01235 ∂16-Jul-88 1003 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme shellscripts
C05418 01236 ∂16-Jul-88 2044 @MC.LCS.MIT.EDU:aab@CADDR.AI.MIT.EDU RE: agenda
C05420 01237 ∂17-Jul-88 1252 @MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU agenda
C05422 01238 ∂18-Jul-88 0712 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Extended local defines.
C05451 01239 ∂18-Jul-88 1111 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Extended local defines.
C05456 01240 ∂18-Jul-88 1231 @MC.LCS.MIT.EDU:james@ZERMATT.LCS.MIT.EDU Re: Scheme shellscripts
C05460 01241 ∂18-Jul-88 1757 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl Re: Replace LETREC with "relaxed" internal DEFINES.
C05466 01242 ∂19-Jul-88 0018 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA
C05469 01243 ∂20-Jul-88 1120 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP Transportation
C05472 01244 ∂20-Jul-88 2359 @MC.LCS.MIT.EDU,@RELAY.CS.NET:shin@carcvax.uconn
C05475 01245 ∂21-Jul-88 0442 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
C05484 01246 ∂21-Jul-88 0613 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Replace LETREC with "relaxed" internal definitions.
C05488 01247 ∂21-Jul-88 1526 @MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU rec definition
C05491 01248 ∂21-Jul-88 1705 @MC.LCS.MIT.EDU:wagle@iuvax.cs.indiana.edu RE: lisp conf scheme agenda
C05536 01249 ∂22-Jul-88 0738 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Making local definitions more like top-level definitions.
C05540 01250 ∂22-Jul-88 0937 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA On Modules in Scheme: Principles and Proposals
C05543 01251 ∂24-Jul-88 1517 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Non-upward-compatibility of Chez Scheme versions
C05547 01252 ∂24-Jul-88 1848 @MC.LCS.MIT.EDU:Olin.Shivers@centro.soar.cs.cmu.edu Non-upward-compatibility of Chez Scheme versions
C05549 01253 ∂25-Jul-88 1422 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Non-upward-compatibility of Chez Scheme versions
C05552 01254 ∂26-Jul-88 0917 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu binding and assignment
C05559 01255 ∂27-Jul-88 0035 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
C05562 01256 ∂27-Jul-88 2000 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
C05565 01257 ∂28-Jul-88 0358 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET Re: binding and assignment
C05574 01258 ∂29-Jul-88 2328 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Amiga C-Scheme?
C05576 01259 ∂31-Jul-88 0001 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Amiga C-Scheme?
C05580 01260 ∂02-Aug-88 0539 @MC.LCS.MIT.EDU:gls@Think.COM Continuations and multiple values
C05588 01261 ∂09-Aug-88 1520 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu "rabbit" report needed.
C05591 01262 ∂10-Aug-88 0212 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the Mac?
C05593 01263 ∂10-Aug-88 1029 @MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu Scheme for the Mac?
C05595 01264 ∂10-Aug-88 1318 @MC.LCS.MIT.EDU:maddox@renoir.Berkeley.EDU XSCHEME
C05597 01265 ∂12-Aug-88 0333 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: XSCHEME
C05601 01266 ∂14-Aug-88 0033 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Mac?
C05603 01267 ∂14-Aug-88 1102 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:SCHREQ@MC.LCS.MIT.EDU Periodic noise message list policy reiterated
C05609 01268 ∂16-Aug-88 1356 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu A Quick Note on the Last L&FP Conference
C05612 01269 ∂17-Aug-88 0426 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Bibliography (Aug. 1988)
C05679 01270 ∂19-Aug-88 0335 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme biblio. (acknowledgements)
C05682 01271 ∂20-Aug-88 0350 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Rabbit report. (NTIS)
C05685 01272 ∂22-Aug-88 1135 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Bibliography (Aug. 1988)
C05687 01273 ∂22-Aug-88 1622 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Snowbird minutes?
C05689 01274 ∂22-Aug-88 2107 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Scheme(Lisp) on Sequent
C05692 01275 ∂23-Aug-88 0808 SCHREQ@MC.LCS.MIT.EDU info-cscheme-request
C05694 01276 ∂24-Aug-88 0731 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let -> ???
C05696 01277 ∂24-Aug-88 0951 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
C05698 01278 ∂24-Aug-88 1416 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
C05699 01279 ∂24-Aug-88 1454 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Named LET -> RECLET
C05701 01280 ∂24-Aug-88 1612 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: named let -> ???
C05703 01281 ∂24-Aug-88 1703 @MC.LCS.MIT.EDU:markf@montreux Re: named let -> ???
C05704 01282 ∂24-Aug-88 1703 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: named let -> ???
C05706 01283 ∂24-Aug-88 1750 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
C05709 01284 ∂24-Aug-88 1933 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Named LET -> RECLET
C05711 01285 ∂25-Aug-88 0817 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
C05714 01286 ∂25-Aug-88 0835 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com named let -> ???
C05719 01287 ∂25-Aug-88 0901 @MC.LCS.MIT.EDU,@STONY-BROOK.SCRC.Symbolics.COM,@GRYPHON.SCRC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM Re: named let -> ???
C05721 01288 ∂25-Aug-88 0917 @MC.LCS.MIT.EDU:markf@montreux named let -> ???
C05723 01289 ∂25-Aug-88 0930 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu named-let proposal
C05726 01290 ∂25-Aug-88 0948 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU named let -> ???
C05728 01291 ∂25-Aug-88 1040 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
C05730 01292 ∂25-Aug-88 1239 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU Yet more Named Let flamage
C05732 01293 ∂25-Aug-88 1301 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: named LET -> RECLET
C05733 01294 ∂25-Aug-88 1741 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Summarizing the named-let debate
C05737 01295 ∂25-Aug-88 2350 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Clarification on named let
C05742 01296 ∂26-Aug-88 0623 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Clarification on named let
C05745 01297 ∂26-Aug-88 0917 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Named-let squabble: Kiss and make up!
C05748 01298 ∂26-Aug-88 0943 @MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU Summarizing the named-let debate
C05751 01299 ∂26-Aug-88 1137 @MC.LCS.MIT.EDU:gls@Think.COM Clarification on named let
C05755 01300 ∂26-Aug-88 1149 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Why named LET anyway?
C05758 01301 ∂26-Aug-88 1213 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Clarification on named let
C05763 01302 ∂26-Aug-88 1233 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Why named LET anyway?
C05767 01303 ∂28-Aug-88 0839 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu named-let proposal
C05771 01304 ∂29-Aug-88 2324 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu named let again
C05775 01305 ∂29-Aug-88 2337 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named-let proposal
C05778 01306 ∂31-Aug-88 1634 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Bibliography (Aug. 1988)
C05780 01307 ∂31-Aug-88 1748 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Bibliography database
C05806 01308 ∂31-Aug-88 1749 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Gabriel benchmarks in Scheme
C05808 01309 ∂01-Sep-88 0852 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let -> ???
C05811 01310 ∂01-Sep-88 1146 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU named let -> ???
C05813 01311 ∂01-Sep-88 1221 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA NAMED-LET sounds good to me.
C05816 01312 ∂01-Sep-88 1254 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU NAMED-LET sounds good to me, too.
C05818 01313 ∂01-Sep-88 1838 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
C05821 01314 ∂02-Sep-88 1048 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
C05824 01315 ∂02-Sep-88 1145 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let ::: call it A-LET-NAMED
C05826 01316 ∂03-Sep-88 1329 NET-ORIGIN@MC.LCS.MIT.EDU Scheme Bibliography (Sept. 1988) Notes, Additions.
C05842 01317 ∂04-Sep-88 1112 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU named let -> ???
C05844 01318 ∂04-Sep-88 1124 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU problems with named-let
C05847 01319 ∂04-Sep-88 2249 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: problems with named-let
C05851 01320 ∂04-Sep-88 2312 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme standard group: anything happening ??
C05854 01321 ∂05-Sep-88 1345 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu problems with named-let
C05856 01322 ∂05-Sep-88 1530 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: problems with named-let
C05859 01323 ∂05-Sep-88 1708 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu minutes from Utah
C05861 01324 ∂06-Sep-88 1402 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@buacca.BITNET Seminar announcement
C05870 01325 ∂06-Sep-88 1937 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Compromise
C05873 01326 ∂07-Sep-88 0720 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU demur on recur
C05877 01327 ∂09-Sep-88 0204 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu Compromise
C05880 01328 ∂09-Sep-88 0204 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Intermediate Lambda Calculus --> Machine code
C05883 01329 ∂09-Sep-88 0205 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Intermediate Lambda Calculus --> Machine code
C05886 01330 ∂09-Sep-88 0352 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Intermediate Lambda Calculus --> Machine code
C05890 01331 ∂09-Sep-88 1444 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU "DEFLET"?
C05893 01332 ∂10-Sep-88 0231 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:adams@tekchips.crl re- named-let
C05896 01333 ∂11-Sep-88 1353 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Re: "DEFLET"?
C05898 01334 ∂12-Sep-88 0523 @MC.LCS.MIT.EDU,@RELAY.CS.NET:SEB1525@draper.com Lambda Calculus Books
C05900 01335 ∂12-Sep-88 0744 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Lambda Calculus Books
C05902 01336 ∂12-Sep-88 0852 @MC.LCS.MIT.EDU:windley@cheetah.ucdavis.edu Re: Lambda Calculus Books
C05904 01337 ∂12-Sep-88 1809 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Question on Combinator Reduction
C05907 01338 ∂13-Sep-88 0215 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Proceedings on Lisp and Functional Programming
C05910 01339 ∂13-Sep-88 1332 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lambda Calculus Books
C05916 01340 ∂13-Sep-88 1605 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Implementation of functional languages
C05941 01341 ∂14-Sep-88 1334 @MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu "DEFLET"?
C05945 01342 ∂14-Sep-88 1516 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Implementation of functional languages
C05949 01343 ∂14-Sep-88 1800 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lambda Calculus Books
C05951 01344 ∂14-Sep-88 1840 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU "DEFLET"?
C05954 01345 ∂14-Sep-88 2014 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Functional Programming Implementation
C05957 01346 ∂15-Sep-88 1238 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu dynamic compilation for scheme, with inlining, etc?
C05962 01347 ∂15-Sep-88 1715 @MC.LCS.MIT.EDU:larus%paris.Berkeley.EDU@ginger.Berkeley.EDU Plea for Scheme Code
C05965 01348 ∂15-Sep-88 1902 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Plea for Scheme Code
C05968 01349 ∂16-Sep-88 0902 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: "DEFLET"?
C05971 01350 ∂16-Sep-88 1542 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Errata for Simon Peyton Jones' book
C05980 01351 ∂17-Sep-88 1517 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Functional Programming Implementation
C05983 01352 ∂19-Sep-88 1413 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu IEEE Scheme Standardization Meeting
C05988 01353 ∂21-Sep-88 0109 @MC.LCS.MIT.EDU:tyan@gwusun.gwu.edu scheme ATT 5
C05990 01354 ∂21-Sep-88 1010 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: dynamic compilation for scheme, with inlining, etc?
C05998 01355 ∂21-Sep-88 1354 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu request for info on scheme (or subset) for MVS (or portable)
C06001 01356 ∂21-Sep-88 1433 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu Status of XScheme
C06003 01357 ∂22-Sep-88 0755 @MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM Re: dynamic compilation for scheme, with inlining, etc?
C06006 01358 ∂22-Sep-88 0838 @MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM Re: dynamic compilation for scheme, with inlining, etc?
C06008 01359 ∂22-Sep-88 1209 @MC.LCS.MIT.EDU:hbs@lucid.com dynamic compilation for scheme, with inlining, etc?
C06011 01360 ∂24-Sep-88 0353 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu space/time in byte code/native code (was dynamic compilation)
C06015 01361 ∂24-Sep-88 0622 @MC.LCS.MIT.EDU:bard@THEORY.lcs.mit.edu space/time in byte code/native code (was dynamic compilation)
C06017 01362 ∂01-Oct-88 1803 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Re: Status of XScheme
C06020 01363 ∂01-Oct-88 2153 NET-ORIGIN@MC.LCS.MIT.EDU Scheme for a Sun 4/280 OS 4.0
C06023 01364 ∂01-Oct-88 2319 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mjk@jupiter.risc.com Plea for Scheme Code
C06026 01365 ∂02-Oct-88 0736 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.bu.edu Plea for Scheme Code
C06028 01366 ∂02-Oct-88 1645 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu example of dynamic optimization
C06034 01367 ∂02-Oct-88 1708 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu dynamic compilation/optimization II
C06040 01368 ∂03-Oct-88 0127 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu unwind-protect
C06042 01369 ∂03-Oct-88 0230 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : unwind-protect
C06045 01370 ∂03-Oct-88 0456 @MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM Re : unwind-protect
C06048 01371 ∂04-Oct-88 0322 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : unwind-protect
C06051 01372 ∂04-Oct-88 1530 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu scheme-standard mailing list
C06053 01373 ∂07-Oct-88 1237 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu self reproducing code
C06055 01374 ∂07-Oct-88 1411 @MC.LCS.MIT.EDU:stoller%morgan@cs.utah.edu Re: self reproducing code
C06057 01375 ∂07-Oct-88 1445 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU self reproducing code
C06059 01376 ∂07-Oct-88 1529 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing code
C06062 01377 ∂07-Oct-88 1650 @MC.LCS.MIT.EDU,@IVORY.S4CC.Symbolics.COM:Zippy@QUABBIN.SCRC.Symbolics.COM self reproducing code
C06065 01378 ∂08-Oct-88 0042 NET-ORIGIN@MC.LCS.MIT.EDU re: Unwind-Protect and Continuations
C06067 01379 ∂08-Oct-88 0429 NET-ORIGIN@MC.LCS.MIT.EDU Scheme for 386/ix?
C06070 01380 ∂08-Oct-88 0430 @MC.LCS.MIT.EDU:hal@murren.ai.mit.edu 1989 Conference on Lisp and History of Lisp -- Advance Notice
C06074 01381 ∂08-Oct-88 1500 @MC.LCS.MIT.EDU:mcvax!diku.dk!danvy@uunet.UU.NET Re: self reproducing code
C06076 01382 ∂08-Oct-88 2020 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM Re: self reproducing code
C06079 01383 ∂09-Oct-88 0739 NET-ORIGIN@MC.LCS.MIT.EDU Re: Unwind-Protect and Continuations (Ref)
C06082 01384 ∂09-Oct-88 1330 @MC.LCS.MIT.EDU:cti@mimsy.umd.edu Scheme mailing list
C06084 01385 ∂10-Oct-88 0629 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Self replicating code
C06086 01386 ∂10-Oct-88 0711 @MC.LCS.MIT.EDU:cti@mimsy.umd.edu Scheme Mailing List
C06088 01387 ∂11-Oct-88 0425 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE self-replicating code
C06093 01388 ∂11-Oct-88 0807 @MC.LCS.MIT.EDU:jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: self reproducing code
C06095 01389 ∂11-Oct-88 2055 NET-ORIGIN@MC.LCS.MIT.EDU Re: self reproducing code
C06100 01390 ∂11-Oct-88 2055 NET-ORIGIN@MC.LCS.MIT.EDU Re: Scheme mailing list
C06103 01391 ∂11-Oct-88 2056 NET-ORIGIN@MC.LCS.MIT.EDU Re: self-replicating code
C06107 01392 ∂12-Oct-88 0224 @MC.LCS.MIT.EDU:gyro@kestrel.arpa self reproducing code
C06109 01393 ∂12-Oct-88 0917 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE Self-reproducing code (correction)
C06113 01394 ∂12-Oct-88 1002 @MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU self reproducing messages.
C06115 01395 ∂12-Oct-88 1042 NET-ORIGIN@MC.LCS.MIT.EDU Re: Self-reproduction
C06118 01396 ∂13-Oct-88 1256 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing messages.
C06120 01397 ∂13-Oct-88 1327 @MC.LCS.MIT.EDU:hoey@aic.nrl.navy.mil Automatic programming
C06122 01398 ∂13-Oct-88 1819 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
C06146 01399 ∂13-Oct-88 1903 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
C06170 01400 ∂13-Oct-88 1934 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
C06194 01401 ∂13-Oct-88 1946 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
C06218 01402 ∂13-Oct-88 2044 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu self reproducing messages.
C06221 01403 ∂13-Oct-88 2126 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
C06245 01404 ∂14-Oct-88 0056 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Self-reproducing code
C06248 01405 ∂14-Oct-88 0126 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Help!
C06251 01406 ∂17-Oct-88 1725 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing messages.
C06253 01407 ∂17-Oct-88 1805 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu Regularization of Procedures in Scheme
C06265 01408 ∂19-Oct-88 1407 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Self reference in objects
C06268 01409 ∂19-Oct-88 1516 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE Unknown host
C06270 01410 ∂19-Oct-88 1556 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Limitation with lambda
C06273 01411 ∂19-Oct-88 1633 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06275 01412 ∂19-Oct-88 1723 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06277 01413 ∂19-Oct-88 1742 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06279 01414 ∂19-Oct-88 1805 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06281 01415 ∂19-Oct-88 1816 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06283 01416 ∂19-Oct-88 1958 NET-ORIGIN@MC.LCS.MIT.EDU case-lambda syntax in Chez Scheme
C06288 01417 ∂19-Oct-88 2044 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06290 01418 ∂19-Oct-88 2122 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Self reference in objects
C06293 01419 ∂19-Oct-88 2206 @MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM Self reference in objects (Adventure)
C06295 01420 ∂19-Oct-88 2236 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06297 01421 ∂20-Oct-88 0405 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Limitation with lambda
C06301 01422 ∂20-Oct-88 1416 @MC.LCS.MIT.EDU:FWHITE@G.BBN.COM Re: Limitation with lambda
C06303 01423 ∂20-Oct-88 1457 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06305 01424 ∂20-Oct-88 1557 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp, Xlisp, Prolog and Scheme
C06307 01425 ∂20-Oct-88 1939 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06309 01426 ∂20-Oct-88 2005 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06311 01427 ∂21-Oct-88 1420 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where/how to get Scheme for Suns?
C06313 01428 ∂21-Oct-88 1502 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu case-lambda and interpreter environments
C06317 01429 ∂21-Oct-88 1655 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where/how to get Scheme for Suns?
C06320 01430 ∂21-Oct-88 2031 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Regularization of Procedures in Scheme
C06323 01431 ∂21-Oct-88 2043 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Regularization of Procedures in Scheme
C06331 01432 ∂21-Oct-88 2142 @MC.LCS.MIT.EDU,@RELAY.CS.NET:stumpf@cogsys.psychologie.uni-freiburg.dbp.de Re: self reproducing messages.
C06334 01433 ∂22-Oct-88 1219 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Limitation with lambda
C06338 01434 ∂22-Oct-88 1543 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:jar@void.ai.mit.edu Where/how to get Scheme for Suns?
C06341 01435 ∂22-Oct-88 1617 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Regularization of Procedures in Scheme
C06349 01436 ∂22-Oct-88 1959 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
C06351 01437 ∂24-Oct-88 1546 @ZERMATT.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU previously failed mail
C06358 01438 ∂25-Oct-88 0824 @MC.LCS.MIT.EDU:kranz@WHEATIES.AI.MIT.EDU Where/how to get Scheme for Suns?
C06361 01439 ∂25-Oct-88 0824 NET-ORIGIN@MC.LCS.MIT.EDU Re: Wanted: most recent xscheme
C06364 01440 ∂25-Oct-88 0825 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu Regularization of Procedures in Scheme
C06368 01441 ∂25-Oct-88 0846 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu null begin forms
C06370 01442 ∂25-Oct-88 1541 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET Re: self-replicating-code, self-replicating-messages
C06375 01443 ∂26-Oct-88 0440 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu -------------------------- call for votes -------------------
C06378 01444 ∂26-Oct-88 1020 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET self-replicating-code, self-replicating-messages
C06383 01445 ∂27-Oct-88 1318 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
C06385 01446 ∂27-Oct-88 1333 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
C06388 01447 ∂27-Oct-88 1344 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
C06391 01448 ∂27-Oct-88 1415 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: self-replicating-code, self-replicating-messages
C06394 01449 ∂27-Oct-88 1513 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MacScheme Manual!
C06396 01450 ∂27-Oct-88 2059 @MC.LCS.MIT.EDU:jinx@altdorf.ai.mit.edu Regularization of Procedures in Scheme (pair setters)
C06398 01451 ∂27-Oct-88 2244 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
C06401 01452 ∂28-Oct-88 0455 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Regularization of Procedures in Scheme (pair setters)
C06403 01453 ∂28-Oct-88 0526 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MacScheme Manual!
C06405 01454 ∂28-Oct-88 0915 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU Regularization of Procedures in Scheme (pair setters)
C06408 01455 ∂28-Oct-88 1517 @MC.LCS.MIT.EDU:gls@Think.COM Regularization of Procedures in Scheme (pair setters)
C06411 01456 ∂28-Oct-88 1716 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MacScheme Manual!
C06413 01457 ∂31-Oct-88 0946 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu debuggers for teaching
C06416 01458 ∂31-Oct-88 1812 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Internal definitions as a combination of LETREC's and LET*'s.
C06422 01459 ∂31-Oct-88 1946 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Internal definitions as a combination of LETREC's and LET*'s.
C06427 01460 ∂01-Nov-88 0550 @MC.LCS.MIT.EDU:ramsdell%linus@MITRE-BEDFORD.ARPA Regularization of Procedures in Scheme (pair setters)
C06430 01461 ∂02-Nov-88 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #1
C06432 01462 ∂03-Nov-88 2157 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #2
C06437 01463 ∂04-Nov-88 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #3
C06439 01464 ∂06-Nov-88 1500 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu R4RS number syntax
C06445 01465 ∂08-Nov-88 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #4
C06449 01466 ∂09-Nov-88 2158 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #5
C06453 01467 ∂10-Nov-88 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #6
C06455 01468 ∂12-Nov-88 0008 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #7
C06532 01469 ∂14-Nov-88 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #8
C06538 01470 ∂15-Nov-88 2211 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #9
C06561 01471 ∂17-Nov-88 0200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #10
C06573 01472 ∂17-Nov-88 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #11
C06606 01473 ∂18-Nov-88 2110 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #12
C06616 01474 ∂19-Nov-88 2212 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #13
C06628 01475 ∂22-Nov-88 0200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #14
C06632 01476 ∂22-Nov-88 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #15
C06637 01477 ∂23-Nov-88 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #16
C06640 01478 ∂24-Nov-88 2153 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #17
C06647 01479 ∂25-Nov-88 2137 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #18
C06649 01480 ∂29-Nov-88 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #19
C06651 01481 ∂30-Nov-88 2202 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #20
C06656 01482 ∂01-Dec-88 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #21
C06659 01483 ∂02-Dec-88 2119 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #22
C06663 01484 ∂03-Dec-88 2155 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #23
C06671 01485 ∂04-Dec-88 2112 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #24
C06674 01486 ∂05-Dec-88 2202 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #25
C06677 01487 ∂06-Dec-88 2339 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #26
C06688 01488 ∂07-Dec-88 2300 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #27
C06701 01489 ∂08-Dec-88 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #28
C06705 01490 ∂09-Dec-88 2146 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #29
C06713 01491 ∂10-Dec-88 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #30
C06718 01492 ∂12-Dec-88 2121 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #31
C06720 01493 ∂13-Dec-88 2220 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #32
C06723 01494 ∂14-Dec-88 2123 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #33
C06736 01495 ∂15-Dec-88 2143 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #34
C06754 01496 ∂16-Dec-88 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #35
C06761 01497 ∂17-Dec-88 2116 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #36
C06764 01498 ∂19-Dec-88 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #37
C06767 01499 ∂22-Dec-88 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #38
C06771 01500 ∂24-Dec-88 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #39
C06773 01501 ∂30-Dec-88 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #40
C06779 01502 ∂01-Jan-89 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #41
C06784 01503 ∂03-Jan-89 2110 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #42
C06787 01504 ∂04-Jan-89 2112 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #43
C06790 01505 ∂06-Jan-89 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #44
C06795 01506 ∂09-Jan-89 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #45
C06797 01507 ∂10-Jan-89 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #46
C06803 01508 ∂11-Jan-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #47
C06811 01509 ∂12-Jan-89 1351 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com R4RS Number Syntax
C06814 01510 ∂12-Jan-89 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #48
C06819 01511 ∂13-Jan-89 2240 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #49
C06826 01512 ∂15-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #50
C06828 01513 ∂18-Jan-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #51
C06830 01514 ∂19-Jan-89 2215 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #52
C06833 01515 ∂20-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #53
C06837 01516 ∂22-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #54
C06840 01517 ∂24-Jan-89 2203 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #55
C06849 01518 ∂28-Jan-89 0240 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #56
C06852 01519 ∂30-Jan-89 2126 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #57
C06855 01520 ∂31-Jan-89 0756 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu truth of '()
C06857 01521 ∂31-Jan-89 0950 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
C06862 01522 ∂31-Jan-89 1202 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com Re: truth of '()
C06865 01523 ∂31-Jan-89 1234 @MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu Quoting vectors?
C06867 01524 ∂31-Jan-89 1244 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
C06869 01525 ∂31-Jan-89 1732 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Quoting vectors?
C06871 01526 ∂31-Jan-89 1748 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06874 01527 ∂31-Jan-89 1840 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06877 01528 ∂31-Jan-89 1850 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06880 01529 ∂31-Jan-89 1901 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
C06885 01530 ∂31-Jan-89 1911 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
C06890 01531 ∂31-Jan-89 1921 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
C06895 01532 ∂31-Jan-89 1931 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06898 01533 ∂31-Jan-89 1943 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06901 01534 ∂31-Jan-89 1954 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
C06904 01535 ∂31-Jan-89 2017 @MC.LCS.MIT.EDU:cph@murren.ai.mit.edu comments on draft IEEE std
C06907 01536 ∂31-Jan-89 2250 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #58
C06911 01537 ∂01-Feb-89 0622 @MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu Quoting vectors?
C06913 01538 ∂01-Feb-89 0907 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Quoting vectors?
C06915 01539 ∂01-Feb-89 0920 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
C06917 01540 ∂01-Feb-89 0932 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: truth of '()
C06919 01541 ∂01-Feb-89 0944 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
C06922 01542 ∂01-Feb-89 1018 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Quoting vectors?
C06924 01543 ∂01-Feb-89 1207 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Quoting vectors?
C06926 01544 ∂01-Feb-89 1219 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
C06930 01545 ∂01-Feb-89 1235 @MC.LCS.MIT.EDU:gls@Think.COM Quoting vectors?
C06934 01546 ∂01-Feb-89 1255 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06938 01547 ∂01-Feb-89 1319 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06942 01548 ∂01-Feb-89 1508 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com Re: Quoting vectors?
C06945 01549 ∂01-Feb-89 1534 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: truth of '()
C06948 01550 ∂01-Feb-89 1703 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06952 01551 ∂01-Feb-89 1716 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu apology for flamage concerning WITH-INPUT-FROM-PORT etc
C06955 01552 ∂01-Feb-89 1923 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
C06957 01553 ∂01-Feb-89 2015 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu Quoting vectors?
C06959 01554 ∂01-Feb-89 2032 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu truth of '()
C06962 01555 ∂01-Feb-89 2056 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
C06965 01556 ∂01-Feb-89 2107 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: truth of '()
C06968 01557 ∂01-Feb-89 2125 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu apology for flamage concerning WITH-INPUT-FROM-PORT etc
C06971 01558 ∂01-Feb-89 2136 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06975 01559 ∂01-Feb-89 2146 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06979 01560 ∂01-Feb-89 2156 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
C06983 01561 ∂01-Feb-89 2209 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu with-input-from-file and co.
C06986 01562 ∂01-Feb-89 2230 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #59
C06992 01563 ∂02-Feb-89 1054 @MC.LCS.MIT.EDU:andy@polya.Stanford.EDU Quoting vectors?
C06996 01564 ∂02-Feb-89 1303 @MC.LCS.MIT.EDU,@LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
C06999 01565 ∂02-Feb-89 1348 @MC.LCS.MIT.EDU,@LCS.MIT.EDU:jinx@chamartin.ai.mit.edu Quoting vectors?
C07002 01566 ∂02-Feb-89 1359 @MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu truth of '()
C07005 01567 ∂02-Feb-89 1618 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu rrrs-authors vs. scheme-standard
C07010 01568 ∂02-Feb-89 2126 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #60
C07016 01569 ∂04-Feb-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #61
C07020 01570 ∂07-Feb-89 1319 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
C07024 01571 ∂07-Feb-89 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #62
C07026 01572 ∂08-Feb-89 2037 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com Portability
C07033 01573 ∂08-Feb-89 2215 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #63
C07074 01574 ∂10-Feb-89 2128 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #64
C07077 01575 ∂11-Feb-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #65
C07079 01576 ∂13-Feb-89 2125 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #66
C07083 01577 ∂14-Feb-89 2127 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #67
C07085 01578 ∂17-Feb-89 2200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #68
C07102 01579 ∂18-Feb-89 1808 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu ... should be a peculiar identifier
C07106 01580 ∂18-Feb-89 2155 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #69
C07110 01581 ∂20-Feb-89 1050 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com Re: ... should be a peculiar identifier
C07113 01582 ∂20-Feb-89 1141 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU ... should be a peculiar identifier
C07115 01583 ∂20-Feb-89 1158 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: ... should be a peculiar identifier
C07117 01584 ∂20-Feb-89 1244 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu ... should be a peculiar identifier
C07121 01585 ∂20-Feb-89 1441 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%coconut@cs.brandeis.edu ... should be a peculiar identifier
C07124 01586 ∂20-Feb-89 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #70
C07126 01587 ∂21-Feb-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #71
C07130 01588 ∂23-Feb-89 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #72
C07134 01589 ∂24-Feb-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #73
C07139 01590 ∂26-Feb-89 2224 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #74
C07149 01591 ∂27-Feb-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #75
C07152 01592 ∂01-Mar-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #76
C07154 01593 ∂02-Mar-89 2139 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #77
C07165 01594 ∂03-Mar-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #78
C07168 01595 ∂05-Mar-89 1344 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@LCS.MIT.EDU Wired numeric predicates?
C07171 01596 ∂07-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #79
C07174 01597 ∂08-Mar-89 2133 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #80
C07177 01598 ∂09-Mar-89 2206 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #81
C07184 01599 ∂10-Mar-89 1559 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Wired numeric predicates?
C07188 01600 ∂10-Mar-89 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #82
C07191 01601 ∂12-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #83
C07194 01602 ∂13-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #84
C07199 01603 ∂19-Mar-89 1256 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #86
C07201 01604 ∂19-Mar-89 1433 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Weird numeric predicates?
C07205 01605 ∂19-Mar-89 1822 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Exactness contagion and wired numeric predicates
C07210 01606 ∂19-Mar-89 1823 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07241 01607 ∂19-Mar-89 1823 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Wired numeric predicates?
C07245 01608 ∂19-Mar-89 1824 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07255 01609 ∂19-Mar-89 2143 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #87
C07258 01610 ∂20-Mar-89 2135 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #88
C07260 01611 ∂21-Mar-89 0325 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Weird numeric predicates?
C07268 01612 ∂21-Mar-89 1840 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07286 01613 ∂21-Mar-89 1956 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Portability (long)
C07305 01614 ∂21-Mar-89 2143 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Weird numeric predicates?
C07310 01615 ∂21-Mar-89 2255 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #89
C07389 01616 ∂22-Mar-89 0450 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Weird numeric predicates?
C07394 01617 ∂22-Mar-89 0946 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07405 01618 ∂22-Mar-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #90
C07407 01619 ∂22-Mar-89 2245 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07417 01620 ∂23-Mar-89 0934 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07422 01621 ∂23-Mar-89 1709 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:ziggy@VX.LCS.MIT.EDU Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07425 01622 ∂23-Mar-89 1715 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Portability (long)
C07438 01623 ∂23-Mar-89 1737 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Portability (long)
C07442 01624 ∂23-Mar-89 1841 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Portability (long)
C07452 01625 ∂23-Mar-89 2118 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #91
C07455 01626 ∂24-Mar-89 0348 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Standardization of libraries
C07463 01627 ∂24-Mar-89 0721 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
C07471 01628 ∂24-Mar-89 1409 @MC.LCS.MIT.EDU,@polya.Stanford.EDU:mkatz@sesame Standardization of libraries
C07481 01629 ∂24-Mar-89 2123 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #92
C07485 01630 ∂25-Mar-89 0550 @MC.LCS.MIT.EDU:jh@tut.fi Standardization of libraries
C07487 01631 ∂25-Mar-89 2128 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #93
C07510 01632 ∂26-Mar-89 1910 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: Portability (long)
C07520 01633 ∂27-Mar-89 1400 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Portability (long)
C07528 01634 ∂27-Mar-89 2021 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: Portability (long) ...(now short)
C07535 01635 ∂28-Mar-89 1308 @MC.LCS.MIT.EDU:ramsdell@huxley.MITRE.ORG copyrights
C07537 01636 ∂28-Mar-89 1541 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu transitive arithmetic comparisons
C07541 01637 ∂28-Mar-89 1559 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu yellow pages
C07548 01638 ∂28-Mar-89 1624 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU yellow pages
C07552 01639 ∂04-Apr-89 2002 @MC.LCS.MIT.EDU:ziggy@hx.lcs.mit.edu Consistency
C07554 01640 ∂07-Apr-89 0749 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu ftp'able R3.95RS
C07556 01641 ∂07-Apr-89 0750 @MC.LCS.MIT.EDU:ziggy@hx.LCS.MIT.EDU R↑3.95 non-idealities (anal)
C07558 01642 ∂07-Apr-89 0754 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #95
C07574 01643 ∂07-Apr-89 2125 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #96
C07578 01644 ∂12-Apr-89 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #97
C07581 01645 ∂16-Apr-89 1329 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #98
C07591 01646 ∂17-Apr-89 1605 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
C07615 01647 ∂17-Apr-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #99
C07621 01648 ∂18-Apr-89 2134 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
C07624 01649 ∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
C07631 01650 ∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
C07634 01651 ∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Conusion with peek-char and char-ready
C07639 01652 ∂19-Apr-89 0145 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #100
C07652 01653 ∂19-Apr-89 0711 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
C07657 01654 ∂19-Apr-89 0723 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
C07660 01655 ∂19-Apr-89 0814 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu Confusion with peek-char and char-ready
C07664 01656 ∂19-Apr-89 1247 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu test message
C07665 01657 ∂19-Apr-89 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #101
C07677 01658 ∂20-Apr-89 2205 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #102
C07694 01659 ∂22-Apr-89 1248 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #103
C07708 01660 ∂22-Apr-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #104
C07725 01661 ∂23-Apr-89 0150 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Why the interest
C07728 01662 ∂23-Apr-89 0201 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Rebinding of standard functions
C07732 01663 ∂23-Apr-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #105
C07737 01664 ∂24-Apr-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #106
C07745 01665 ∂25-Apr-89 2156 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #107
C07753 01666 ∂29-Apr-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #108
C07756 01667 ∂30-Apr-89 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #109
C07761 01668 ∂01-May-89 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #110
C07771 01669 ∂02-May-89 2207 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #111
C07784 01670 ∂03-May-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #112
C07802 01671 ∂04-May-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #113
C07812 01672 ∂07-May-89 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #114
C07816 01673 ∂08-May-89 2129 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #115
C07829 01674 ∂09-May-89 2127 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #116
C07833 01675 ∂10-May-89 2137 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #117
C07841 01676 ∂12-May-89 2121 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #118
C07845 01677 ∂13-May-89 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #119
C07850 01678 ∂14-May-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #120
C07853 01679 ∂15-May-89 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #121
C07858 01680 ∂16-May-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #122
C07861 ENDMK
C⊗;
∂26-Apr-86 0738 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU The generality of define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Apr 86 07:38:32 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86 10:38:14 EST
Date: 26 Apr 1986 10:38 EST (Sat)
Message-ID: <JINX.12201925541.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: andy@AIDS-UNIX.ARPA (Andy Cromarty)
Cc: SCHEME@MC.LCS.MIT.EDU
Subject: The generality of define
In-reply-to: Msg of 23 Apr 1986 19:09-EST from andy at aids-unix (Andy Cromarty)
(define square (lambda (x) (* x x)))
at all, but rather to
(define square (rec square (lambda (x) (* x x))))
The new version of RRRS changes this.
(define (square x) (* x x))
will be equivalent to
(define square (lambda (x) (* x x)))
The self recursive form can be obtained by explicitely using LETREC or
wRECk.
∂26-Apr-86 1816 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu variata
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Apr 86 18:15:50 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 26 Apr 86 21:16:52 EST
Received: from 5400000012 by CSNET-RELAY.ARPA id a000769; 26 Apr 86 21:04 EST
Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Apr 86 10:33-EST
Date: 26 Apr 1986 10:33 EST (Sat)
Message-ID: <JINX.12201924643.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu>
To: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Cc: JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: variata
In-reply-to: Msg of 25 Apr 1986 19:04-EST from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
To summarize:
-- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
are valid.
-- I feel that (BEGIN) should have the same meaning as (COND), but I
won't push the point.
I don't like this. Unfortunately JAR did not give me choice c (status
quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I
like best. I object pretty strongly to (BEGIN) and somewhat less
strongly to (COND). The usual rationale is that it makes macros
easier to write, but this is just laziness of the same sort as using
(cdr (assq <something> <some-list>)) in a Lisp where (cdr '()) -> '().
(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE
clause is empty, which should be an error, but we agree on this).
-- We agree on using EQV? for CASE.
I like JAR's proposal too.
-- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry
about confusion when I mix Scheme and Common LISP programs.
I'm worried about gratuitous differences between EQ? and EQV?. I
would object (although not terribly strongly) to making
(eq? '#() '#()) be #T, but I think it is silly to have EQ? and EQV?
behave differently on this. The reason I object to (eq? '#() '#())
being #T is that inline coding of make-vector would become more
expensive. Make-vector is very cheap in our implementation and a good
candidate for inline coding (although we don't currently do it), and
having it intern 0 length vectors (strings) would make it more
expensive.
-- I like warning messages for things like (MAKE-VECTOR 0 exp) more
than you do. We can probably agree to provide declarations so you
won't refuse to buy my system!
I agree with JAR. I think that (MAKE-VECTOR 0 exp) is reasonable and
no error (warning) message should be given. I don't understand why
you object to it. Why not warn about reversing a list with less than 2
elements also?
-- I'm not apologetic about trying to avoid ``gratuitous''
differences with Common LISP, but I don't want to burden the
description of Scheme with constant references to it either.
I agree. Unless there is strong reason to do otherwise, we should not
differ from Common Lisp. This should probably be stated early (if we
all agree, of course), and assumed afterwards. A reference to this
remark in various places might be appropriate.
∂27-Apr-86 1455 @MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA variata
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Apr 86 14:55:43 PDT
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 27 Apr 86 17:56:56 EDT
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473339; Sun 27-Apr-86 17:54:24-EDT
Date: Sun, 27 Apr 86 17:55 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: variata
To: JAR@MIT-MC.ARPA
cc: RRRS-AUTHORS@MIT-MC.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].895280.860425.JAR>
References: The message of 24 Apr 86 10:43-EST from Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-ID: <860427175526.2.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>
I am absolutely opposed to making (COND) or (COND (ELSE)) or (BEGIN) or
(LAMBDA ()) illegal. I am content to make them return undefined values but
I insist that, for example, (LAMBDA () (BEGIN) 3) is a completely well-formed
expression that should neither cause the compiler to say anything nor cause
an error at runtime.
I am very opposed to requiring ELSE to be the last clause in a COND. It seems
to me that
(COND ((FOO)) (ELSE #T) ((BAR)))
is like like
(OR (FOO) #T (BAR)).
I hope no one is going to insist that the previous form should also be illegal
and/or that it should be warned about by a compiler. The call to BAR is
obviously not going to get reached for pragmatic reasons, but there may be
legitimate situations where program-writing programs could want to construct
something like this and I think we'd be shooting ourselves in the foot to
disallow such things. Also, I think it tends to make the grammar look more
graceful if ELSE can occur anyway. The particular case of interest is:
`(COND ,@FORMS (ELSE FOO))
where FORMS may be allowed to contain an ELSE clause. I object to having to
write:
`(COND ,@FORMS ,@(IF (AND FORMS (NOT (EQ (CAR (LAST FORMS)) 'ELSE)))
`((ELSE FOO))
`()))
If you decide to make any of the above forms legal, I wish to have my
reasons for disagreement cited.
I think CASE should be changed to use EQUAL?, which I think is in agreement
with a recent suggestion by you. This will get around a lot of confusion that
could otherwise result from the recent trend toward wanting to intern quoted
structure.
I'm fairly satisfied with the way things seem to be going in the EQ? and
EQV? discussion so will mostly decline from any comment for now on that
subject.
JAR: If people believe that it's important to be able to parse Scheme's
read syntax using only standard Common Lisp reader features, then by all
means we must allow (eq? '#() '#()) to be false, but we also have to
change the syntax of numbers, and make colon not be a constituent
character. But Scheme's eqv? could still deal with #() and "" as I
propose even if eq? doesn't.
Right.
JAR: It looks like I'll lose on this point, so I won't push it too hard.
I'm just resisting adding yet another clause which basically says "we
did this for compatibility with Common Lisp."
I am sympathetic to this position.
I strongly oppose requiring APPEND to do gratuitous copying. It's trivial to
adopt
Bartley (about APPEND): ... I'd like some discussion on this. It sounds
like something a LISP programmer could trip up on, especially those
who use (APPEND X '()) to copy X. Steele's book specifically mentions
that APPEND will work that way in Common LISP, but implies that it is
poor style. My inclination is to be compatible with Common LISP in
order to minimize frustration for the poor people we're trying to
win over to Scheme.
JAR: If this is what other people want I'm happy with it too (except
again for the fact that I'll have to insert another apology and another
reference to Common Lisp).
The fact that CL provides COPY-LIST is enough for me. I am strongly opposed
to continuing this lossage of forcing APPEND to do gratuitous copying. You're
falling down on your let's-not-be-gratuitously-compatible-with-CL maxim. CL
itself is really only doing it for compatibility, too. This is a case where
we're clearly right and ought not give in.
JAR: What about (let ((x (list 'a))) (eq? x (reverse x))) ?
Bartley: I feel strongly that REVERSE should always copy (unless its
argument is the empty list), since it is easier to remember that rule
than that it does so only when there's more than one element in the list.
Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and
wouldn't want to side effect the original list in X if it had exactly
one element. (Note that this works correctly when X is the empty
list, so this is a pretty unusual boundary condition.)
JAR: I agree. (Except note that it doesn't copy empty lists....)
I am receptive to the idea of permitting the result of REVERSE to share with
its input. The idiom (APPEND! (REVERSE X) Y) should just be named. CL has
REVAPPEND and NRECONC. I believe we should just have APPEND-REVERSE and
APPEND-REVERSE! which do these common operations. This would reduce the need
to rely on copying. I think we should take a consistent stand on the idea
that REVERSE, APPEND, do not have to copy and that that's why we provide
COPY-LIST. People can always write their own COPY-LIST-REVERSE,
COPY-LIST-APPEND, etc. if they really need to intertwine the two operations
for some efficiency reason. The dumb routines are so easy to write yourself,
after all. The ones provided by the system should be the messy-to-write
super-optimizing ones.
∂27-Apr-86 1607 @MC.LCS.MIT.EDU:dcj%jacksun@SUN.COM SCOOPS, and GNU support question
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Apr 86 16:07:16 PDT
Received: from sun.com by MC.LCS.MIT.EDU 27 Apr 86 19:06:04 EDT
Received: from snail.sun.com (snail-ptp) by sun.com (3.2-/SMI-3.0)
id AA13232; Sun, 27 Apr 86 16:01:26 PDT
Received: from jacksun.sun.uucp by snail.sun.com (3.2/SMI-3.0DEV4)
id AA28515; Sun, 27 Apr 86 16:04:42 PDT
Received: by jacksun.sun.uucp (1.1/SMI-3.0)
id AA11217; Sun, 27 Apr 86 16:04:02 PDT
Date: Sun, 27 Apr 86 16:04:02 PDT
From: dcj%jacksun@SUN.COM (Donald Clark Jackson)
Message-Id: <8604272304.AA11217@jacksun.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: SCOOPS, and GNU support question
As a user of TI-SCHEME, I kind of like
the SCOOPS object-oriented package.
I have C-Scheme running on a Sun now, and
I would like to get SCOOPS running on it.
Is source for SCOOPS available, or is it
TI proprietary code? Is there something
similar available?
Also, while getting the "inferior scheme"
mode in GNU Emacs to work, I had to change the
following line in xscheme.el:
(make-shell "scheme" scheme-program-name nil "-emacs")
to
(make-shell "scheme" scheme-program-name)
What was the "-emacs" supposed to do?
I have GNU Emacs Version 17.61, and
MIT C-Scheme Version 6.1.
If this is the wrong mailing list for these
questions, please suggest a better forum.
Mail me your replies, if possible. I'll
summarize to this list if there is any
demand.
Thanks,
Don Jackson
djackson@sun.com
{ucbvax,decwrl,...}!sun!djackson
∂28-Apr-86 1155 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: variata
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Apr 86 11:54:22 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 14:55:35 EDT
Received: from ti-csl by csnet-relay.csnet id a002987; 28 Apr 86 14:49 EDT
Received: by tilde id AA15512; Mon, 28 Apr 86 13:40:42 cdt
Date: Mon 28 Apr 86 13:28:11-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: variata
To: JINX%OZ.AI.MIT.EDU%xx.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <JINX.12201924643.BABYL@MIT-OZ>
Message-Id: <12202480652.63.BARTLEY@CSC60>
>Date: 26 Apr 1986 10:33 EST (Sat)
>From: Bill Rozas <JINX%OZ.AI.MIT.EDU%xx.lcs.mit.edu@csnet-relay>
>
> [Bartley:]
> -- I like warning messages for things like (MAKE-VECTOR 0 exp) more
> than you do. We can probably agree to provide declarations so you
> won't refuse to buy my system!
>
>I agree with JAR. I think that (MAKE-VECTOR 0 exp) is reasonable and
>no error (warning) message should be given. I don't understand why
>you object to it. Why not warn about reversing a list with less than 2
>elements also?
I'm not objecting, just asking questions to clarify JAR's position and
to elicit comments from others with strong opinions. Let's see if I
can clarify both mine and yours:
-- I agree that (MAKE-VECTOR EXP1 EXP2) shouldn't be an error or
cause a warning at runtime should EXP1 evaluate to zero. I'm talking
about compile-time warnings (e.g. for a COMPILE-FILE) when EXP1 is a
literal zero. I oppose most, perhaps all, warnings during evaluation.
Sorry I wasn't more explicit -- I tend to think in terms of separate
compilation and I'm sure many of you are thinking primarily in terms
of interpretation.
-- Likewise, (REVERSE EXP3) obviously shouldn't cause a warning when
EXP3 evaluates to a list with fewer than two elements. But a
compile-time warning about (REVERSE '(A)) might be helpful (if it
weren't so unlikely!).
There's no real debate here. If I were to report `warnings,' as
opposed to actual `errors,' I'd do it only in a compilation mode where
they wouldn't be confused with the runtime behavior of the program and
only if the user asked for them by setting a flag. This is a
development environment issue, not a language issue.
> -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
> are valid.
>
> -- I feel that (BEGIN) should have the same meaning as (COND), but I
> won't push the point.
>
>I don't like this. Unfortunately JAR did not give me choice c (status
>quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I
>like best. I object pretty strongly to (BEGIN) and somewhat less
>strongly to (COND). The usual rationale is that it makes macros
>easier to write, but this is just laziness of the same sort as using
>(cdr (assq <something> <some-list>)) in a Lisp where (cdr '()) -> '().
>(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE
>clause is empty, which should be an error, but we agree on this).
Actually, JINX and I seem to agree that (BEGIN) and (COND) are equally
meaningless. I offer to allow (COND) but feel (BEGIN) makes as much
sense. If there's a consensus against (COND), then I'm even happier.
I'm not all that motivated by wanting to write lazy macros or program-
generating programs for reasons similar to JINX's.
Regards,
David Bartley
-------
∂28-Apr-86 1340 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: SCOOPS, and GNU support question
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Apr 86 13:39:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 16:39:23 EDT
Received: from ti-csl by csnet-relay.csnet id a003922; 28 Apr 86 16:34 EDT
Received: by tilde id AA15837; Mon, 28 Apr 86 13:50:21 cdt
Date: Mon 28 Apr 86 13:42:05-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: SCOOPS, and GNU support question
To: dcj%jacksun%sun.com@CSNET-RELAY.ARPA,
scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <8604272304.AA11217sun.sun.uucp>
Message-Id: <12202483182.63.BARTLEY@CSC60>
> Date: Sun, 27 Apr 86 16:04:02 PDT
> From: Donald Clark Jackson <dcj%jacksun%sun.com@CSNET-RELAY.ARPA>
>
> As a user of TI-SCHEME, I kind of like
> the SCOOPS object-oriented package.
> I have C-Scheme running on a Sun now, and
> I would like to get SCOOPS running on it.
>
> Is source for SCOOPS available, or is it
> TI proprietary code? Is there something
> similar available?
I'll look into getting formal approval from our product group to
release the source for SCOOPS. The actual SCOOPS source for TI's PC
Scheme has some implementation-dependent efficiency hacks built in,
but we may be able to put together a sanitized portable version.
However, SCOOPS is built upon first-class environments, so it wouldn't
port to some dialects out there (including the standard).
If we get permission to give out the source, we will of course want to
make it non-proprietary, which works both ways: you owe us nothing and
we owe you nothing (well, very little!). I'll see what we can work
out and post the result.
David Bartley
-------
∂29-Apr-86 0743 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU meaning of *global* define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Apr 86 07:43:13 PDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 29 Apr 86 10:44:21 EDT
Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Apr 86 10:42-EDT
Date: 29 Apr 1986 10:20 EDT (Tue)
Message-ID: <JINX.12202697723.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Cc: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, RRRS-Authors%mit-mc@XX.LCS.MIT.EDU
Subject: meaning of *global* define
In-reply-to: Msg of 15 Apr 1986 15:49-EST from willc%tekchips%tektronix.csnet at CSNET-RELAY.ARPA
What is the difference between having incorrect procedures all over
the place and having incorrect numbers, lists, strings, or vectors all
over the place?
It would be possible to fix other objects if in our system all objects
maintained a history of how they were created, and often I think that
this would be a very nice debugging environment. Unfortunately, for
efficiency reasons, they do not. Procedures, fortunately, contain the
environments where they are closed, and these include most of the
relevant information about their creation history. By modifying these
environments we can patch a running system in a way we cannot patch it
if the "wrong value" happens to be a vector or other "simple" data
structure. Just because we cannot provide a more general and powerful
debugging tool, it does not mean that we should not provide an
extremely useful (the most useful to me) special case.
In terms of implementation, there are various possible trade offs. I
can easily accept a system where incremental definition (when it does
not degenerate into assignment) causes a garbage-collection-like
process to occur to make all the references consistent. I am
perfectly willing to pay the price of a very powerful feature which I
use relatively often.
PS: Sorry about taking so long to answer this message. It was buried
in a large pile.
∂30-Apr-86 1425 @MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA Questions from a newcomer
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Apr 86 14:19:02 PDT
Received: from ORNL-MSR.ARPA by MC.LCS.MIT.EDU 30 Apr 86 17:18:30 EDT
Received: by ORNL-MSR.ARPA (4.12/4.9)
id AA16413; Wed, 30 Apr 86 16:38:46 edt
Date: Wed, 30 Apr 86 16:38:46 edt
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8604302038.AA16413@ORNL-MSR.ARPA>
To: scheme@mc
Subject: Questions from a newcomer
Hi -
I would like to learn know about an implementation of Scheme which runs
on VAX VMS 4.x and an implementation which runs on a 68000 machine
(especially Amiga, Macintosh Plus, Sage/Stride, or Atari 1040ST). I
have seen a reference to Scheme 312 which sounded interesting.
I have also seen a reference to "Chez Scheme" for VAX BSD 4.2++ which I
would like to know more about.
I am especially interested "native" implementations (not implemented on
top of another Lisp), versions with a compiler, and versions which are
public domain. I have purchased TI's PC Scheme for my IBM AT.
I am interested in Scheme because I think it may run reasonably well on
a micro I can afford to have at home. I have a Sage II now, but I am
considering another 68000 machine. I am also hoping that Scheme will
be a simple, easy to implement Lisp which is not thundering towards
commercialization.
I tried Golden Common Lisp on ATs and was disappointed in the
unwieldiness.
We have Common Lisp (DEC Lisp and NIL) on the VAXen I use at work,
but I would like to investigate Scheme as an alternative.
- Thanks
jim mullens
oak ridge national laboratory
∂30-Apr-86 2156 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Questions from a newcomer
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Apr 86 21:56:39 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86 00:55:49 EDT
Date: 1 May 1986 00:43 EDT (Thu)
Message-ID: <JINX.12203116956.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: jcm@ORNL-MSR.ARPA (James A. Mullens)
Cc: scheme@MC.LCS.MIT.EDU
Subject: Questions from a newcomer
In-reply-to: Msg of 30 Apr 1986 16:38-EDT from jcm at ORNL-MSR.ARPA (James A. Mullens)
MIT CScheme runs on a wide variety of machines with C compilers. In
particular it runs on some 68000 systems (mostly unices) and on VMS.
It currently does not have a compiler, but will have one by the end of
the summer (the VAX back end may not be ready at that time, however).
It is public domain.
∂05-May-86 1142 @MC.LCS.MIT.EDU:amn@LOCUS.UCLA.EDU getting C-Scheme running on HP workstations
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86 11:42:26 PDT
Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU 5 May 86 14:40:34 EDT
Date: Mon, 5 May 86 11:26:40 PDT
From: Arthur Newman <amn@LOCUS.UCLA.EDU>
To: scheme@mc.lcs.mit.edu
Subject: getting C-Scheme running on HP workstations
Message-ID: <860505.182640z.03031.amn@ZEUS.LOCUS.UCLA.EDU>
By just installing the student version we would get the following bug:
trying to set! an undefined variable would cause a bus error and kick
you out of Scheme back to the system prompt.
I recompiled Scheme using the normal.bin file, and eval'ed
(enable-language-features). Now trying to set! undefined variables
just gives an error message.
Are there any reasons why we had trouble with set! in the student system
that you can think of?
Thanks for any help,
Arthur Newman
∂05-May-86 1402 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU one more message about CScheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86 14:02:15 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAY 86 17:01:34 EDT
Date: 5 May 1986 16:26 EDT (Mon)
Message-ID: <JINX.12204337135.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: scheme@MC.LCS.MIT.EDU
Subject: one more message about CScheme
Please, send bug reports about MIT CScheme to
bug-cscheme%oz@mit-mc, not to this (scheme@mit-mc) mailing list.
bug-scheme%oz@mit-mc is not good either. There is more than one
implementation at MIT, and bug-scheme does not refer to CScheme.
General questions about CScheme should be sent to
info-cscheme%oz@mit-mc.
Thanks.
PS: When answering bug reports incorrectly sent to this mailing list I
have tried not to send the reply here. If you have run across similar
bugs, and have not received a reply, send mail to bug-cscheme, since
they have probably been fixed. Notices of bug fixes, etc, are sent to
info-cscheme.
∂05-May-86 1910 @MC.LCS.MIT.EDU:serafini@ames-aero implementation roundup
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86 19:09:55 PDT
Received: from ames-aero.ARPA by MC.LCS.MIT.EDU 5 May 86 21:41:26 EDT
Date: 5 May 86 18:32:00 PST
From: DAVE SERAFINI <serafini@ames-aero>
Subject: implementation roundup
To: scheme <scheme@mit-mc.arpa>
Reply-To: DAVE SERAFINI <serafini@ames-aero>
Has anyone compiled a list of the various implementations of scheme extant,
and could I be send a copy?
advTHANKSance
Dave Serafini
------
∂05-May-86 1914 JAR@MC.LCS.MIT.EDU implementation roundup
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86 19:13:36 PDT
Date: Mon, 5 May 86 22:12:44 EDT
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject: implementation roundup
To: serafini@AMES-AERO.ARPA
cc: SCHEME@MC.LCS.MIT.EDU
In-reply-to: Msg of 5 May 86 18:32:00 PST from DAVE SERAFINI <serafini at ames-aero>
Message-ID: <[MC.LCS.MIT.EDU].904409.860505.JAR>
Date: 5 May 86 18:32:00 PST
From: DAVE SERAFINI <serafini at ames-aero>
Has anyone compiled a list of the various implementations of scheme extant,
and could I be send a copy?
There's a list of implementations, with brief descriptions, in the file
"SCHEME;SCHEME IMPLS" on MIT-MC. I compiled it from messages sent to
this mailing list. I don't think MC's FTP server requires passwords to
log in; if you are asked to supply a user name or password, give
arbitrary strings like GUEST and ARPA.
People who don't have Internet access and want a copy of this file
should send a message to JAR@MC (not to SCHEME@MC!) requesting it. I'll
batch requests, except that if I get more than ten requests I'll simply
send the file out to the entire Scheme mailing list. It's about 12K
bytes so I'll have to mail it in two pieces (MC's mailer is limited to
10 or 11K).
Jonathan
∂22-May-86 0819 NET-ORIGIN@MC.LCS.MIT.EDU H, E, S, B, O, D, X
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86 08:19:24 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:17:45 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1619; Thu 22-May-86 11:18:03-EDT
Date: Thu, 22 May 86 11:18 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: H, E, S, B, O, D, X
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Has anyone implemented number output formats in their entirety? A
number of people have requested the the following minor change: that
the keywords which are now single letters be spelled out. E.g.
EXPRESSED and SUPPRESSED instead of E and S.
We can discuss the details separately. If some people think such a
change is a bad idea at this point then the change shouldn't be made.
But if no one has implemented it and people like the idea then I think
it can be done pretty painlessly.
The letters in question are H, E, S, B, O, D, and X. If you don't know
what they mean that simply attests to the desirability of spelling them
out.
Jonathan
∂22-May-86 0900 NET-ORIGIN@MC.LCS.MIT.EDU LOAD
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86 08:54:27 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86 11:53:10 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1622; Thu 22-May-86 11:51:29-EDT
Date: Thu, 22 May 86 11:51 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: LOAD
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
I would like to either remove LOAD from the report or change the way in
which it is presented.
Reasons:
(a) A LOAD procedure is equipotent with EVAL, and EVAL isn't documented.
The same reasons that applied to kick out EVAL apply here.
(b) It seems to me a perfectly reasonable idea to create Scheme systems
that don't have a LOAD procedure. I can imagine at least two completely
different kinds of implementations in which LOAD wouldn't make sense.
One kind of implementation would be in the style of most implementations
of PASCAL, FORTRAN, etc., where one runs programs by configuring entire
environments at once. This avoids all the semantic stickiness of LOAD
and EVAL by making configuration a meta-issue. Second, at the opposite
extreme, in an Interlisp-like implementation where one actually edits
"in core", and files don't generally come into play, LOAD is pretty
meaningless.
(c) It seems to me that LOAD is a user interface/programming environment
issue. We don't talk about read-eval-print loops, or entering or
exiting scheme, or logging in, or editing files; how is this different?
Alternative solutions:
(1) Omit it entirely without saying anything.
(2) Mention somewhere (e.g. in the introduction) that Scheme is
"usually" an interactive language with a read-eval-print loop and
support for things like interactive debugging and dynamic program
loading.
(3) Reclassify LOAD as being part of the syntax of a file. I.e., like
DEFINE, it can only occur at top level in a file.
(4) Leave it alone, but put it in a "user interface" section along with
TRANSCRIPT-ON and TRANSCRIPT-OFF (and maybe TRACE, DEBUG, and EDIT?),
instead of classifying it as an input procedure. Make a disclaimer that
these things are only guaranteed to work "at top level" (whatever that
is).
(5) Some combination of (3) and (4) [allow it both in files and at
command loops].
Feedback solicited.
-Jonathan
-----
KMP: please send a message making a case for a (LOAD-SILENTLY x).
∂22-May-86 1016 @MC.LCS.MIT.EDU:andy@aids-unix Re: LOAD
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86 10:16:06 PDT
Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 22 May 86 13:14:03 EDT
Date: Thu, 22 May 86 10:13:20 pdt
From: andy@aids-unix (Andy Cromarty)
To: JAR@MIT-AI.ARPA
Subject: Re: LOAD
Cc: rrrs-authors@mit-mc
1. Numbers: I agree with full naming. Even when I was actively working
on a full numbers package I couldn't remember what these were
wiuthout looking them up. Perhaps implementations should be free
to support single-letter names in "not recommended" status for
the sake of downward compatibility.
2. LOAD: This is sticky. The beast probably should not exist in this
or any other language, because files themselves are a bad idea
left over from the early days of computer science when we didn't
know any better and allowed hardware to dominate software design.
The problem is that not having LOAD available requires that we
have an alternative available, which means either (a) having a
transparent or essentially transparent object filing system or (b)
having a non-transparent object filing system with an explicit
object-writing operator (e.g. WRITE or some variant would have to
be able to render permanent any arbitrary object, such as functions
that make lexical reference to variables from an enclosing scope
and similar LISP objects that can have very messy state in a
lexically scoped environment).
If we have LOAD available but we don't document it, we have simply
ignored the problem, rather than either solving it or admitting we
can't yet. The fact is that, unlike EVAL, LOAD is something that
everyone will have to use, including newcomers; it's not esoterica,
even if it does interfere with intellectual cleanliness. The means
to address such cleanliness issues is probably design, not selective
non-documentation.
A good compromise might be to add a paragraph of comment,
something like what appears in the RRRS for macros, stating that
this is currently a difficult area in LISP design and that LOAD
is provided but that work on alternatives (e.g. object filing systems)
is encouraged.
asc
∂22-May-86 1558 @MC.LCS.MIT.EDU:KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Notes about (↑ revised 3) report
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86 15:58:13 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 22 May 86 18:55:22 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6687; Thu 22-May-86 18:53:41 EDT
Date: Thu, 22 May 86 18:53 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Notes about (↑ revised 3) report
To: JAR@MIT-MC.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, RRRS-AUTHORS@MIT-MC.ARPA
Message-ID: <860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
On p30, while reading the description of READ, the following questions
occurred to me, the answers to which are in some cases probably dependent
upon the answers to the others in order to assure useful consistency:
* Does the stream become closed as a side-effect of hitting eof?
* Is it an error to read from a closed stream, or does eof just keep
getting returned?
* Can you read the eof object twice at the end of a file using READ ?
How about if using READ-CHAR ? PEEK-CHAR ?
* Is it possible to detect whether a file is closed?
* Is it acceptable for close on certain streams to not really close the file?
For example, I could imagine implementing terminal streams or streams into
editor buffers in a way such that they just always claimed to be open and
close was a no-op.
Also on p30, it seems to me that the notion of CHAR-READY? is not a useful one.
It's subject to timing errors in multi-processed systems and/or systems which
allow asynchronous interrupts. The Lisp Machine's TYI-NO-HANG paradigm is much
better, since it has a more test-and-set feel to it and is more easy to use
reliably. I suggest that CHAR-READY? should be flushed and replaced by a
READ-CHAR? which returns either a character if one is ready, or NIL otherwise.
This gets you out of the bind with rubbing out stuff that CHAR-READY? has
noticed, which is really an awful crock. I believe that TYI-NO-HANG will
interact satisfactorily with Lispm-style rubout handlers.
On p30, the issue with LOAD is that if we're going to define it, we need to give
it a standard meaning so it can be usefully used on different systems. If we
don't say it either types out or doesn't, then people can't use it in their
programs for fear it will screw up the display (this exact problem arose in real
situations in my work with Common Lisp). I feel that a LOAD which does
no typeout is a useful interface to the operating system and a necessary
feature for bootstrapping other code. The absence to provide it will mean that
either every user will have to type in a definition of load at the keyboard
or every system will have to provide it anyway. Obviously, this translates
to that every system will provide one, since no one's going to force the user
to type it in. If every system is going to provide it, we might as well
standardize on it so people can know what they're getting. If particular
dialects want to offer additional options, well, ... you're no doubt aware
of my feelings on this issue and i'll spare the cc'd folks for now.
∂23-May-86 0957 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: H, E, S, B, O, D, X
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86 09:57:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 12:54:49 EDT
Received: from ti-csl by csnet-relay.csnet id a004166; 23 May 86 12:35 EDT
Received: by tilde id AA21938; Fri, 23 May 86 10:21:49 cdt
Date: Fri 23 May 86 10:06:06-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: H, E, S, B, O, D, X
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12208997463.23.BARTLEY@CSC60>
We have implemented the number output formats in PC Scheme. I like
the idea of spelling out the keywords and won't "vote" against it, but
there are two troublesome aspects:
(1) We already have a product out that supports the abbreviated style,
so we'd have to grandfather it. That's always a minor pain.
(2) My experience is that not one programmer in ten can spell both
EXPRESSED and SUPPRESSED correctly (sorry about that!). What should
NUMBER->STRING do with EXPRESED or SUPRESSED? [Of course, there are
plenty of other opportunities for misspellings to trip one up!]
Seriously, I recommend that we retain the single letter abbreviations
as an option if we switch to full names for these keywords.
Regards,
David Bartley
-------
∂23-May-86 1013 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: LOAD
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86 10:12:57 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 13:08:09 EDT
Received: from ti-csl by csnet-relay.csnet id ab04166; 23 May 86 12:36 EDT
Received: by tilde id AA21281; Fri, 23 May 86 10:06:37 cdt
Date: Fri 23 May 86 09:54:59-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: LOAD
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12208995440.23.BARTLEY@CSC60>
My first thought is that LOAD should be retained, but not as an
essential procedure. That would help a programmer avoid some name
conflicts, since most implementations of Scheme and Lisp have a LOAD.
My second thought is to wonder why we have included non-essential
procedures in the Report. Is it to warn a programmer that the given
identifier should be considered "reserved" or is it to guide
implementors toward consistent extensions to the essential language?
In the first case, I'd say that the programmer should be referring
primarily to the manual for his implementation, not to the Report, and
that that manual should take care to warn him of portability issues.
In the second case, I'd say that our coverage of "suggested"
extensions is so patchy that it's almost irrelevant whether LOAD is
mentioned or not. After all, where are COMPILE and EVAL, two obvious
names for extended features?
So, my inclination is to let JAR do whatever he likes. This is a
pragmatic issue. Ideally, we'd have an appendix that discusses these
things, but that may be Pandora's box.
--db--
-------
∂25-May-86 0923 @MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA Addition to Mailing-List
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 May 86 09:23:11 PDT
Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 12:18:59 EDT
Date: 25 May 1986 12:18-EDT
Sender: VERACSD@USC-ISI.ARPA
Subject: Addition to Mailing-List
From: VERACSD@USC-ISI.ARPA
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD>
Please add me to your Scheme Mailing-List.
I am presently running MacScheme, and have used it to work
through the examples in the Abelson & Sussman book, define a
Common Lisp compatibility package, and implement a PROLOG.
I am particularly interested in using continuations and macros in
Scheme. I have a great general interest in logic-programming,
and the imple- mentation of logic-programming languages.
Thanks.
-- Cris Kobryn
∂25-May-86 1237 @MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA Addition to Mailing-List
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 May 86 12:37:32 PDT
Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 15:14:26 EDT
Date: 25 May 1986 12:18-EDT
Sender: VERACSD@USC-ISI.ARPA
Subject: Addition to Mailing-List
From: VERACSD@USC-ISI.ARPA
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD>
ReSent-To: scheme@MC.LCS.MIT.EDU
ReSent-From: VERACSD at USC-ISI.ARPA
ReSent-Date: 25 May 1986
Please add me to your Scheme Mailing-List.
I am presently running MacScheme, and have used it to work
through the examples in the Abelson & Sussman book, define a
Common Lisp compatibility package, and implement a PROLOG.
I am particularly interested in using continuations and macros in
Scheme. I have a great general interest in logic-programming,
and the imple- mentation of logic-programming languages.
Thanks.
-- Cris Kobryn
∂26-May-86 1555 @MC.LCS.MIT.EDU:JAR@MX.LCS.MIT.EDU R↑3RS draft
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 May 86 15:55:20 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 MAY 86 18:54:42 EDT
Date: Mon, 26 May 86 18:54:00 EDT
From: Jonathan A Rees <JAR@MX.LCS.MIT.EDU>
Subject: R↑3RS draft
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].921583.860526.JAR>
I have mailed / given out copies of the latest draft of the report (22
May). People in Boston and New Haven should have either received one
from me or should stop by and pick one up. A copy went to Tektronix by
special courier. People with Internet access AND Latex AND something
that will read Unix "tar" files should FTP to MIT-PREP, using user
Scheme and null password if necessary, and get the file
"/u/jar/r3rs.tar". If FTP doesn't seem to work, then try telnetting to
PREP and logging in as Scheme (no password needed). The login shell is
FTP. Send the abovementioned file to your machine. Extract all the
files somewhere and run Latex on the file "rrrs.tex". If you don't have
something that will read tar files, use FTP to get all the files on the
directory /u/jar/r3rs.
On Friday I mailed one copy to Dan Friedman and one copy to Dave
Bartley, so people at Indiana and TI should get extra copies from them.
Anyone else who wants one mailed should let me know right away (although
I think that everyone has been taken care of).
There is a cover letter, too, relevant parts of which I'll send
electronically.
Jonathan.
∂27-May-86 1120 NET-ORIGIN@MC.LCS.MIT.EDU Remaining questions & remarks (1)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86 11:19:24 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 14:18:40 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1808; Tue 27-May-86 14:18:17-EDT
Date: Tue, 27 May 86 14:19 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: Remaining questions & remarks (1)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
I included the following with the reports I sent and gave out. Here it
is again for those people who don't have it already. It enumerates most
of the remaining nits I have. Don't be intimidated by the number of
items; none are serious. Many of these questions have been discussed
and some have been resolved already. For those items that stay
unresolved, I'll take the conservative position and leave the new report
in agreement with the old report.
I'll send a second, more recent set of nits separately.
- Jonathan
-----
Questions on LANGUAGE
I left CASE as is, using EQV? as the comparison, and I explicitly stated
that the object ought to be boolean, character, number, or symbol. But
shouldn't it allow empty lists, vectors, and strings, too?
May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND
be Common Lisp compatible? [Bartley says sharing would be a gratuitous
incompatibility with CL, I'm invlined to agree.]
Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?
Should APPEND! disallow () as other than last argument?
I decided that allowing GCD, etc. of Gaussian integers was probably
premature. I'll put them in if someone writes the documentation
(including examples).
Can we decide on what to do about number exactness on input? How about:
inexact if there are digits following a decimal point, or if exponential
notation is used. Otherwise exact.
Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?
What should be said, if anything, about the desirability and/or legality
of EQUAL? failing to terminate? Rozas thinks an implementation with
this property is in error.
In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it
would be a good idea to explicitly state that closing a closed port
should be a no-op instead of an error.
-----
Questions on PRESENTATION
Should the various examples which use DEFINE be changed to use the
(define (foo ...) ...) syntax instead of (define foo (lambda ...))?
Several people have told me that all those LAMBDA's could unnecessarily
intimidate SIGPLAN readers.
There are two places (in descriptions of let* and letrec) where it is
necessary to create a lambda body in a context (such as the tail of a
BEGIN) where there isn't one already. What is the cleanest way to do
this? Is (let () ...) ok, or would ((lambda () ...)) or something else
be better?
Is the word ``promise'' all right for objects returned by DELAY?
Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?
-----
Notes on LANGUAGE
The selectors in a CASE expression must be distinct.
I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.
BOOLEAN? is essential.
No agreement on COND or BEGIN. I have left them as in RRRS.
[To do: fix the BNF to agree!]
The RRRS explicitly allows internal definitions in the body of a LETREC.
They are scoped to the body only, not to the entire expression. I can
flush this "feature" if a movement arises to do so; it seems sufficient
to me to permit only expressions (not definitions) in the body.
The list to which the rest argument gets bound must be newly allocated.
Making LET* be essential was suggested, but there was resistance to
this, so I left it as is.
There was strong sentiment both for removing REC and for removing
NAMED-LAMBDA. However, the sentiment was not unanimous. I don't
understand why it should have matterred so much, since neither is an
essential feature. If these are present, shouldn't everyone's favorite
features be present too? ... Supporters of REC included Kent Dybvig and
Dan Friedman. Supporters of NAMED-LAMBDA included Jim Miller and Henry
Wu. In addition, Bill Rozas insisted that if REC stayed, then
NAMED-LAMBDA must stay too, but he was willing to see both go.
APPEND! necessarily clobbers its arguments (other than the last and
empty ones).
Many people wanted the number predicates pruned (i.e. choose between <
and <?). No agreement here, so both stay.
The BNF says that ALL random symbols, including ELSE, =>, UNQUOTE, and
UNQUOTE-SPLICING, are reserved and may not be used as variable names. I
hope this is OK with everyone.
Note that the grammar for numbers allows one to write things like 23##
for inexact numbers. This was implicit in last summer's report, and I
thought it wouldn't make sense if this was allowed on output but not on
input.
The case sensitivity issue was a very sensitive one (so to speak). I
did not change the report's stance of symbol case insensitivity.
-----
Notes on PRESENTATION
I listed myself as "editor" of this version. I probably should just
remain a coauthor, but the report needs an editor in order to look like
the Algol 60 report.
I eliminated the term ``special form.'' I introduced phrases like ``IF
expression'' in a couple of places; things like IF and CASE are not
referred to as active agents (keywords don't refer to particular
things---it's the evaluator that actively interprets expressions having
certain special syntactic forms). I removed statements like
``<expression> is evaluated but <variable> is not.''
At Pitman's request, I changed ``guard'' to ``test'' in the description
of COND because ``guard'' has inappropriate connotations; COND doesn't
really implement a Dijkstra guarded conditional.
The term "variable" now refers the name itself, not the binding or the
location. This is in accordance with the way logicians (including
Alonzo Church) use the term.
I decided not to add an appendix describing S&ICP differences. The most
important difference, I think, was RRRS's lack of DELAY and FORCE. I no
longer find the presence of SEQUENCE distasteful.
I removed the apologetic statement that went with the description of T
and NIL. (Some people actually like T and NIL.)
The sentence ``This procedure can be very confusing if used
indiscriminately'' in the descriptions of set-car! and set-cdr! was
struck at Chris Hanson's request; it seemed gratuitous.
There are at least sixteen different references to Common Lisp. I'm
going to try to remove some of them. We have to make it very clear that
Scheme is 11 years old and originated some of CL's ideas --- not the
other way around!
∂27-May-86 1339 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA define (resend)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86 13:38:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 May 86 16:37:57 EDT
Received: from indiana by csnet-relay.csnet id a009297; 27 May 86 15:40 EDT
Date: Tue, 27 May 86 12:20:15 EST
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend)
We have one great difficulty with the RRRS as it stands: DEFINE can not make
global bindings when used locally and still be consistent with the report.
Much has been said about the pros and cons of the "MIT style" local define,
and it is clear that a consensus is not possible, so a compromise is in
order. Simply making MIT style optional is not acceptible: optional syntax,
if implemented, must conform to a single semantics. Thus DEFINE semantics is
preempted as the report is currently written.
Using a different keyword, such as DEFINE-GLOBAL, to make global definitions
from lexically nested positions is not acceptible to us. We have tried to
live with such arrangements for some months now, and have found them
intolerable.
A compromise position would be to include a form such as DEFINE-GLOBAL in
the report, hopefully as a required special form, and make an explicit
exception in the case of DEFINE to the rule that optional features, if
implemented, always have a single semantics. The idea is that it should be
possible, in any "standard" Scheme that supports some kind of macro package,
to get *either* style of lexical DEFINE by simply loading the appropriate
macro package. Failing that, it should at least be *possible* for a
Scheme implementation to provide such packages, and allow either package to
be loaded without stepping outside of the "standard".
This compromise is not something that anyone would love, but it is most
sincerely hoped that it is something that everyone can live with. Then
no one will feel bad about being associated with the RRRS.
Chris Haynes
Dan Friedman
Kent Dybvig
∂27-May-86 1844 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define (resend) (long)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86 18:44:40 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86 21:44:00 EDT
Date: 27 May 1986 21:43 EDT (Tue)
Message-ID: <JINX.12210162108.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend) (long)
In-reply-to: Msg of 27 May 1986 13:20-EDT from Chris Haynes <cth%indiana.csnet at CSNET-RELAY.ARPA>
I'm afraid that we have a real disagreement here.
Much has been said about the pros and cons of the "MIT style" local define,
and it is clear that a consensus is not possible, so a compromise is in
order.
I disagree. Much has been said about MIT's INCREMENTAL DEFINE (which
T also has), but not much has been said at all about (static and local)
INTERNAL DEFINE, which is the only one which appears on the report.
This happened mostly for compatibility with S&ICP, not because the
people from MIT were trying to force it on anybody else (after all, we
cheerfully accepted LETREC, which we did not have before).
Using a different keyword, such as DEFINE-GLOBAL, to make global definitions
from lexically nested positions is not acceptible to us. We have tried to
live with such arrangements for some months now, and have found them
intolerable.
DEFINE-GLOBAL does not make sense for either T or MIT-Scheme. Neither
really has a global environment distinguished from the rest, thus
there is no environment where these definitions could be made. The
closest we (MIT) can come to this is making the definition occur in
the innermost environment created by means of MAKE-ENVIRONMENT (the
innermost locale in the case of T), but this seems arbitrary in our
case, to say the least, since all environments are created equal. In
T this is not the case, so this is a viable option. We would still do
it if everybody else agreed to it, but we'd rather not, since there
are other options (see below).
The idea is that it should be
possible, in any "standard" Scheme that supports some kind of macro package,
to get *either* style of lexical DEFINE by simply loading the appropriate
macro package.
What about Schemes that do not have macros at all? Does this mean
that they have to choose one of the two styles, and thus have no
possibility of running the "portable" code written using the other? I
disagree very strongly with having a feature with two possible
inconsistent semantics. The only option would be to remove its
optional status, and therefore remove it from the report completely.
Thus nobody would be able to use DEFINE at all in portable code.
Changing semantics now, besides being unacceptable to us, would mean
being purposely incompatible with S&ICP, and gratuitously incompatible
with the previous version of the report.
What is it that you do not like about DEFINE-GLOBAL? The name is too
long? Use DEFINE! or DEF instead. The first was suggested at the meeting
in Brandeis. Is the problem that it is not even in the report, so you
can't use it because it is not portable? I'm pretty convinced that we
(MIT) could be convinced of accepting it for the sake of consensus
after a little arm twisting (very little needed).
Note that there is a portable way of achieving the effect of
DEFINE-GLOBAL:
(define foo) ; or (define foo '*)
(define bar) ; or (define bar '*)
(let ((<local-state>))
(set! foo <whatever you want 1>))
(set! bar <whatever you want 2>)))
We often do this (although we have and use alternatives) to "export"
values to outer environments, but this gives us more control than
DEFINE-GLOBAL, since we can just place the DEFINEs in the environment
where we want the definitions to occur.
If you do not like the assignments, there is the following
alternative:
(with-exports (foo bar)
(let ((<local-state>))
(define-export foo <whatever you want 1>)
(define-export bar <whatever you want 2>)))
which would just be pretty syntax for the previous choice. Note that
DEFINE-EXPORT (or DEFINE!, or anything you want to call it) is nothing
special, since it trivially turns into SET!.
Note that the (FOO BAR) list could be made optional, meaning "trap"
all DEFINE-EXPORTs.
∂28-May-86 0827 @MC.LCS.MIT.EDU,@KATHERINE.THINK.COM:gls@AQUINAS.THINK.COM Remaining questions & remarks (1)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 08:26:59 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 28 May 86 11:21:41 EDT
Received: from KATHERINE.THINK.COM by Godot.Think.COM; Wed, 28 May 86 10:42:51 edt
Date: Wed, 28 May 86 10:43 EDT
From: Guy Steele <gls@Think.COM>
Subject: Remaining questions & remarks (1)
To: JAR@MIT-AI.ARPA
Cc: rrrs-authors@MIT-MC.ARPA
In-Reply-To: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-Id: <860528104332.1.GLS@KATHERINE.THINK.COM>
Date: Tue, 27 May 86 14:19 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
...
There are at least sixteen different references to Common Lisp. I'm
going to try to remove some of them. We have to make it very clear that
Scheme is 11 years old and originated some of CL's ideas --- not the
other way around!
That's right! Good for you.
--Guy
∂28-May-86 0836 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA hash-consing
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 08:36:45 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 11:33:21 EDT
Received: from ti-csl by csnet-relay.csnet id aj17147; 28 May 86 11:08 EDT
Received: by tilde id AA18724; Wed, 28 May 86 09:55:46 cdt
Date: Wed 28 May 86 09:45:51-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: hash-consing
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12210304495.60.BARTLEY@CSC60>
Has anyone had any experience with systems that use hashing CONS? I
remember the idea was in vogue 15 or 20 years ago as a way to lower
memory consumption, speed up EQUAL, and for theoretical (heretical?)
reasons. The idea is to use hashing techniques to make pairs that are
EQUAL? also be EQ?.
The disadvantages seem to be (1) slower CONS, (2) unclear semantics
for SET-CAR! and SET-CDR!, (3) separate spaces or tags (or something)
if both hashed and regular CONS exist, and (4) GC complications. Are
there any experimental results that demonstrate any significant
compensating advantages? If so, what are the circumstances?
The definition of CONS in the RRRRS guarantees that every pair
returned is unique, so hashing would seem to be out of the question.
However, I wonder if a HASH-CONS procedure has any merit.
Regards,
David Bartley
-------
∂28-May-86 1137 @MC.LCS.MIT.EDU:andy@aids-unix Re: define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 11:37:37 PDT
Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 28 May 86 14:36:14 EDT
Date: Wed, 28 May 86 08:04:09 pdt
From: andy@aids-unix (Andy Cromarty)
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, cth%indiana.csnet@CSNET-RELAY.ARPA
Subject: Re: define
Cc: rrrs-authors@MC.LCS.MIT.EDU
If we are casting votes on DEFINE, I would observe that of the
half-dozen or so of us here who are directly involved in our Scheme
effort, only one of us favors any legitimate status for "global"
DEFINEs. (He happens to come from Indiana, BTW, and we may have
succeeded in changing even his mind on this issue.) The rest of us
have from the outset found Scheme-84's global DEFINE semantics to be
an abhorrent violation of the principles of lexical scope. In fact,
we assumed it was a compiler bug when we first ran across it.
Even where there is a most global environment, we are hard-pressed
to see what could justify advocacy of a special form that reaches
into it specially from an enclosed scope to destructively manipulate
its state. If we (collectively) need an extension of Scheme to achieve
this effect, let's promote binding environments to first-class objects and
define a destructor that treats them uniformly. (I believe, however,
that it is possible to write substantive, efficient, and above all,
elegant Scheme programs without the inclusion of such a destructor.)
I have always felt that the global DEFINE in Scheme-84 was a profound
design flaw that must be attributable to the unfortunate influence of
the Franz environment (both software and intellectual) in which Scheme-84
was constructed. I understand that there is a substantial difference of
opinion on this issue, but we find it difficult to see how global DEFINEs
are even arguably compatible with what we take to be fundamental design
principles of Scheme. In fact, as evidence of our objection to Scheme-84's
global DEFINE semantics, we have done some work on ripping this feature out
of a copy of the Scheme-84 compiler, replacing it with S&ICP's internal
DEFINE.
asc
p.s. My apologies for blitzing you with such a strong opinion; we hashed
this one out locally until it was beaten to death some time ago,
and our opinions have admittedly become somewhat calcified....
∂28-May-86 1241 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: define (resend) (long) (short)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 12:41:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 15:40:20 EDT
Received: from indiana by csnet-relay.csnet id ab19262; 28 May 86 15:35 EDT
Date: Wed, 28 May 86 13:30:30 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jinx@MC.LCS.MIT.EDU
Subject: Re: define (resend) (long) (short)
Cc: rrrs-authors@MC.LCS.MIT.EDU
It is too much to ask everyone who has learned to use "define" the
way we know and love it here to switch to either a new word or a
new meaning for internal definitions. We feel that we have given it
our best shot over the past year, having tried both "define!" and
"global-define". What it boils down to is that (1) the same name
should be used inside as out to define global variables and (2) the
right name is define.
You mentioned the possibility of omitting internal define altogether.
We would be satisfied with that. The report should say something to
the effect of portable code should only use the define/set! form (or
appropriate sugaring). This seems to be the only viable solution.
∂28-May-86 1736 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define (resend) (long) (short)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 17:36:26 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86 20:34:54 EDT
Date: 28 May 1986 20:34 EDT (Wed)
Message-ID: <JINX.12210411645.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend) (long) (short)
In-reply-to: Msg of 28 May 1986 14:30-EDT from Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>
What it boils down to is that (1) the same name
should be used inside as out to define global variables and (2) the
right name is define.
Again, this does not make any sense in MIT Scheme, where user code
runs by default in an environment which inherits the "global"
bindings, rather than the one were the bindings actually exist. Top
level DEFINEs do not define in the global environment, but in whatever
environment the code is loaded. The default top level environment is
an environment with an empty top frame, and whose parent frame
contains the initial accessible bindings of the system. Our system
(local and incremental DEFINE) is perfectly consistent, since DEFINE
always acts on the environment where the definition is evaluated.
There is no difference between top level and inner environments. As a
matter of fact, top level is changed at various times, and thus top
level DEFINE acts on different environments at different times.
Indiana style DEFINE sounds horrendous to me because the evaluation
happens in one environment, while the "assignment" happens in another,
without making this explicitely visible. Nevertheless, I'm willing to
have it added it to the report as long as it has a different name
(DEF?). Note that if DEF is implemented, it will also "work" at top
level, so you can always use the same name.
You mentioned the possibility of omitting internal define altogether.
We would be satisfied with that. The report should say something to
the effect of portable code should only use the define/set! form (or
appropriate sugaring). This seems to be the only viable solution.
Again, this is being gratuitously different from the previous version
of the report, and S&ICP. We are keeping T and NIL, #!TRUE and
#!FALSE, just to be backwards compatible. Removing DEFINE would allow
implementations (like you) to have semantics completely incompatible
with the previous report.
Look guys, I hate BEGIN with all my guts. I am not fighting against
it. We had a vote at Brandeis and it WON (I cast the only vote
against it). I (and JAR, and GJS, who hate it almost as much as I do)
abide by that decision (although I occasionally grumble about it, as
well as about REC). I would very much like to see it out, but if
everybody does this we will never agree on anything, because everybody
will find something they do not like. I'm afraid that DEFINE must
stay the way it is, and I (and the rest of the Scheme people at MIT,
plus others, I'm sure) will oppose any changes to it. You are
reopening a can of worms which was closed at Brandeis. Since we are
at it, why don't we argue again about when CALL-WITH-INPUT-FILE closes
the file or whether the name should be LETREC or LABELS?
∂28-May-86 2216 @MC.LCS.MIT.EDU:gls@Think.COM Embedded DEFINE forms
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 22:16:13 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 29 May 86 01:14:55 EDT
Received: by Godot.Think.COM; Thu, 29 May 86 01:14:45 edt
Date: Thu, 29 May 86 01:14:45 edt
From: gls@Think.COM (Guy Steele)
Message-Id: <8605290514.AA08588@Godot.Think.COM>
To: rrrs-authors@mc
Subject: Embedded DEFINE forms
I have watched the controversy going on for quite some
time, and it seems to me that at this late date, on the
eve, apparently, of widespread publication of a standard
for SCHEME, that there is not consensus in the SCHEME
community on the subject of embedded DEFINE forms.
If the community cannot agree, nor even agree to agree
on some arbitrary choice, then the matter should not be
standardized.
I see no harm in the standard not defining what happens to
embedded DEFINE forms. This would allow the various camps
to be upward-compatible extensions of the standard (though
of course not with each other in this regard). RRRS might
even have, as a footnote or appendix, descriptions of the
competing proposals.
--Guy
∂28-May-86 2243 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Notes about (↑ revised 3) report
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86 22:43:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 01:17:54 EDT
Received: from tektronix by csnet-relay.csnet id ak02235; 29 May 86 1:04 EDT
Received: by tektronix.TEK (5.31/6.12)
id AA09772; Tue, 27 May 86 13:03:39 PDT
Received: by tekchips (5.31/5.14)
id AA07744; Tue, 27 May 86 13:07:54 PDT
Message-Id: <8605272007.AA07744@tekchips>
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: JAR@MC.LCS.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU,
willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: Notes about (↑ revised 3) report
In-Reply-To: Your message of Thu, 22 May 86 18:53 EDT.
<860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 May 86 13:07:52 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Here are the answers I prefer to KMP's starred questions; words within
brackets were edited by me.
* Does the [port] become closed as a side-effect of hitting eof?
No.
* Is it an error to read from a closed [port], or does [an eof-object]
just keep getting returned?
It is an error.
* Can you read the eof object twice at the end of a file using READ ?
How about if using READ-CHAR ? PEEK-CHAR ?
Yes. Yes. Yes.
* Is it possible to detect whether a [port] is closed?
Impossible using only the procedures documented in R↑3RS. I'd like the
language to remain silent on whether a closed port is still a port.
* Is it acceptable for close on certain [ports] to not really close the
[port]? For example, I could imagine implementing terminal [ports] or
[ports] into editor buffers in a way such that they just always claimed
to be open and close was a no-op.
Yes.
KMP:
Also on p30, it seems to me that the notion of CHAR-READY? is not a
useful one. It's subject to timing errors in multi-processed systems
and/or systems which allow asynchronous interrupts. The Lisp Machine's
TYI-NO-HANG paradigm is much better, since it has a more test-and-set
feel to it and is more easy to use reliably. I suggest that CHAR-READY?
should be flushed and replaced by a READ-CHAR? which returns either a
character if one is ready, or NIL otherwise. This gets you out of the
bind with rubbing out stuff that CHAR-READY? has noticed, which is really
an awful crock. I believe that TYI-NO-HANG will interact satisfactorily
with Lispm-style rubout handlers.
To some extent I agree with this, but I don't think READ-CHAR? by itself
is any better for multi-processing than CHAR-READY?.
Peace, Will
∂29-May-86 1417 NET-ORIGIN@MC.LCS.MIT.EDU define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 14:16:32 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 17:04:56 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86 16:14:05 EDT
Date: Thu, 29 May 86 16:13 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: define
To: cth%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MIT-MC.ARPA
In-Reply-To: The message of 27 May 86 13:20-EDT from Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Message-ID: <"860529161305.5.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
I didn't want to make any changes to the report as fundamental as this.
A change to DEFINE also seems infeasible given how constroversial the
topic is and always has been. I am trying to sidestep controversies
right now, so that I can get something done. Maybe in next year's
revision (??) we can address this question.
As we agreed at Brandeis, few of us wholeheartedly like internal
definitions, but they should be described ("nonessentially") because
S&ICP uses them. This was a difficult compromise for us to arrive at,
and I think it would be much too painful at this point to retract it.
And now we have another reason to leave them in, which is compatibility
with the RRRS.
T originally had the semantics that you prefer for DEFINE (although
definitions aren't "globally" effective, they're scoped to the innermost
lexical contour which is willing to accept it). Many users found it to
be a very nice feature, for the same reasons you do. However, I have
recommended to the current T implementors that they remove the feature,
for several reasons:
(a) It makes it more difficult for humans & programs to scan a file
to find its definitions.
(b) It's not always obvious which environment it is intended the
definitions go in; like MIT Scheme, T has no notion of "top level."
(c) It really confuses anyone who has ever seen S&ICP or MIT Scheme.
The old meaning will be retained in T, probably under some other name
(or anonymously, since T has anonymous special form types). Kent and
others still stand by the old meaning.
Here is how I think I would put the functionality that "global define"
provides into a language like Scheme. (A better language than Scheme
might do it better.) Invent a special form (or macro) called something
like EXPORT or PROVIDE or MODULE which works as follows:
(provide <var1> <var2> ...)
is equivalent to
(lambda (<temp>)
(case <temp>
((<var1>) <var1>)
((<var2>) <var2>)
...
(else <error>)))
where <temp> is a variable different from <var1>, <var2>, ....
Then instead of
(let ((state ...))
(define-global reader ...)
(define-global writer ...)
...)
you can write
(define i/o-system
(letrec ((state ...)
(reader ...)
(writer ...)
...)
(provide reader writer ...)))
(define reader (i/o-system 'reader))
(define writer (i/o-system 'writer))
...
The PROVIDE special form would be useful for many other applications as
well (e.g. object-oriented programming).
If this is too verbose for you, I think other kinds of macros could
almost as easily be designed which like the above raise no new semantic
questions.
- Jonathan
∂29-May-86 1438 NET-ORIGIN@MC.LCS.MIT.EDU schedule
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 14:38:38 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 17:35:14 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86 14:37:56 EDT
Date: Thu, 29 May 86 14:36 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: schedule
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860529143648.3.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Thanks to everyone who has read the draft report so carefully. But
don't stop -- keep those cards and letters coming. I called Wexelblat
about the production schedule for August and September SIGPLAN. He said
he has to have it in his hands by June 13 (needs a page count sooner) if
it's to go into the August issue (which gets mailed out the first week
of August). So this gives us a little more time. However: the August
issue is getting to be pretty full; if we think it's urgent that it be
published, it's possible to get it in, but he would prefer if it waited
for the September issue. I told him that some of the coauthors were
ancy to get the thing published and that I'd ask them what they thought.
Note that it won't get out to people before the Lisp conference in any
case.
I'm inclined to try to push and get it into the August issue, but if
people think we should spend more time arguing about things (I had no
idea so much controversy would arise at this late date), then we can
wait.
Jonathan
∂29-May-86 1450 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 14:48:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:39:12 EDT
Received: from ti-csl by csnet-relay.csnet id aa00976; 29 May 86 13:21 EDT
Received: by tilde id AA23409; Thu, 29 May 86 11:09:54 cdt
Date: Thu 29 May 86 10:35:51-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: define
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12210575742.48.BARTLEY@CSC60>
There is clearly no chance of a consensus on the meaning of an
internal DEFINE. It seems fair to let the current draft go through
without changes from the previous one, since that was the
understanding at Brandeis.
The only viable solutions for the future are to remove internal
DEFINEs entirely (as Guy suggests) or to persuade the Indiana folk to
choose a new name. (I thought `DEFINE!' was appropriate--whatever
happened to it?)
I prefer the second option. Now that Scheme systems are being broadly
distributed, it is important for us to show a united front. I would
understand a user's anger if he could not find compatible
implementations for his range of machines.
I understand IU's feelings, but I think a compromise with DEFINE! or
DEF or whatever is in the same spirit as all of us have solved similar
inconsistencies in the past.
Regards,
David Bartley
-------
∂29-May-86 1454 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA R3RS draft -- procedural
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 14:54:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:14 EDT
Received: from northeastern by csnet-relay.csnet id a001585; 29 May 86 14:20 EDT
Date: Thu, 29 May 86 10:32 EST
From: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: R3RS draft -- procedural
I have been looking at the draft of the R3RS which was distributed (dated 22
May). There are certainly a number of issues (some serious) which need to be
resolved. In addition, there are many places in the report (marked by open
brackets) which have not yet been filled in, and where the completion is
substantive, rather than presentational.
In view of this situation, I think it would be a serious mistake to "mail it
to SIGPLAN June 1 come hell or high water". I think those of us whose names
will appear as authors of the report deserve to see a CLEAN draft before it is
submitted. The document is too important not to get it right.
I will send out my other comments in some other messages.
Mitch Wand
∂29-May-86 1545 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R3RS draft -- procedural
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 15:44:21 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 18:42:11 EDT
Date: Thu, 29 May 86 18:42:02 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: R3RS draft -- procedural
To: WAND%northeastern.edu@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 29 May 86 10:32 EST from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].48143.860529.JAR>
Date: Thu, 29 May 86 10:32 EST
From: MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
In view of this situation, I think it would be a serious mistake to "mail it
to SIGPLAN June 1 come hell or high water". I think those of us whose names
will appear as authors of the report deserve to see a CLEAN draft before it is
submitted. The document is too important not to get it right.
OK.
∂29-May-86 1610 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA response to new draft report (long)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 16:10:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 16:06:56 EDT
Received: from ti-csl by csnet-relay.csnet id aa00186; 29 May 86 11:51 EDT
Received: by tilde id AA21997; Thu, 29 May 86 10:35:56 cdt
Date: Thu 29 May 86 10:19:27-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: response to new draft report (long)
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA
Message-Id: <12210572757.48.BARTLEY@CSC60>
Here are my (hasty) comments on the new draft Report.
COMMENTS ON THE TEXT OF THE DOCUMENT:
[page 1]
My name is "David Bartley", but "D.H.Bartley" is better than "D.Bartley".
Why use zero-origin indexing for section numbers?
[page 2]
Use italics and capitalization for consistency in "revised report
[29]" in 2nd paragraph of Background.
The term "coalescing" in the 2nd-to-last paragraph is not defined
anywhere.
[page 4]
Remove "will" from "Italicized names will stand for..."
Pluralize "argument" in "the append procedure is being passed zero or
more list argument."
Add "be" in "this report explicitly does not specify what value should
[be] returned." at end of 0.2.2.
Change "Upper and lower case letters are never distinguished..." in 1
to something like "Upper and lower case forms of a letter are never
distinguished...". Surely `A' is distinct from `b'.
Are #t and #f considered identifiers?
[page 5]
In 1st paragraph of 1.1: "Whitespace may occur..., but not within a
token." Is a string containing a space a token? The character `#\ '?
Typo: change `occuring' to `occurring'.
The statement "Backslash isn't used by Scheme except within string
constants" is awkward and negative.
Remove "are not used in Scheme right now but" from "... curly braces
are not used in Scheme right now but are reserved...".
Change "Like Algol or Pascal" to "Like Algol and Pascal".
[page 6]
In 2.1, the words "most values count as true, but a few--notably #f--
count as false" should be tightened up, since section 5.0 on page 13
makes it clear that only #f and the empty list count as false IN
CONDITIONAL EXPRESSIONS. (Is "in conditional expressions" a
qualifier???)
[page 7]
Fix "see section refdefine" in 3.0.2.
Is 3.0.2 a good place to take note that () is not a good procedure call?
What is meant by "here we will ASSUME that <body> is simply a sequence
of one or more expressions" in 3.0.3?
[page 8]
Please change the descriptions of COND and CASE to be what they were
in the RRRS (modulo the small changes we seem to have consensus on).
I see no reason to get carried away with describing the permissible
types for <datum> in a CASE key list. Just define CASE as using MEMV
(or EQV?) and let the implications hang out!
[page 10]
The first LET* example at the top left of the page is confusing, since
the first <binding> is decomposed into <variable> and <init> and the
others are not.
At the bottom of the first column, change the second instances of
<variable1> and <init1> to have subscript 2.
The words "... are variables which do not occur in the original LETREC
expression..." are confusing. Would a new binding of the identifier
(or is it variable) <temp1> be an occurrence of <temp1>? Similar
wording appears elsewhere in the document (e.g. with DO).
[page 11]
Specify that <name> in named LET must be an identifier (or is it
"variable").
[page 12]
Section 3.1.4: The wording "(for example, by a call to the FORCE
procedure)" begs for elaboration. I think it makes sense to postpone
most of the discussion to page 27ff, as JAR does, so let's use a
"white lie" here and mention only FORCE as a way to collect on a
promise. All other ways are extensions.
[page 13]
Change the last line of 4.1.0 from "Global definitions are essential;
all Scheme implementations must support them." to something like "This
semantics for top level definitions is essential." What does "global
definition" mean? The clause after the ";" is redundant.
I feel uncomfortable about using the term "lambda body" to include the
"body" of a LET or DEFINE expression, as is done in 4.2.
Why not retitle section 5 to be something like "Standard Procedures"
instead of "Initial Environment"? The text makes it clear that these
procedures are the standard bindings of variables in the initial
environment, so it doesn't have to be emphasized in the title. A
person looking at the table of contents on page 1 is likely to be
confused.
[page 14]
How about adding (EQ? NIL 'NIL) ==> #F as another example at the end
of 5.0 to hammer the point home?
Add "in the same order" at the end of "Two procedures are
operationally equivalent iff ... they return the same value and
perform the same side-effects." (Or is that implied by `having the
same side-effects'?)
The wording "it will always err on the conservative side" seems to say
that EQV? tries to do the "right" "wrong thing"!
[page 15]
Change "Objects of distinct types WILL NEVER BE operationally
equivalent, BUT FALSE and the empty list are permitted to be
identical..."
to "Objects of distinct types ARE NEVER operationally equivalent,
EXCEPT THAT #F and the empty list are permitted to be
identical...".
The second sentence of the description of EQUAL? should say that EQV?
is used for all objects except pairs, vectors, and strings.
[page 16]
Change "same" to "equivalent" in the comparison of (a b c d e) and its
dotted form.
[page 17]
APPEND! always side-effects all but its last argument.
[page 18]
Change "(in the sense of EQV? and EQ?)" to "(in the sense of EQ?)" or
"(in the sense of EQV?)". (Why mention both?)
What is meant by "returned" in the second and third sentences of the
description of SYMBOL->STRING? How about "created"?
[page 19]
The previous Report used all caps for the words NUMBER, COMPLEX, ...,
for EXACT and INEXACT, and [page 23ff] INT, RAT, FIX, FLO, ... . I
think that is less confusing than using the same typeface used for
Scheme identifiers.
[page 20]
Change the title of 5.4.2 from "Syntax" to something like "Number syntax".
Rephrase "to make all user populations happy". >I'm< not happy with
having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!
[page 25]
JAR has omitted an important paragraph in the previous Report's
discussion of strings. The sixth paragraph on page 51 of the RRRS,
beginning "In phrases such as...", clarified in one place how
substring START and END work. The descriptions of SUBSTRING (etc)
don't make this clear at all.
[page 26]
If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
flush it! This is only the tip of the iceberg when it comes to handy
little utility functions for building editors.
[page 27]
The dual use of VECTOR in the example starting (LET ((VECTOR (VECTOR...
is confusing.
For consistency, change ELTS in LIST->VECTOR to LIST.
[page 28]
Change "they" to "to" in "but they illustrate the property that the
value of a promise is computed at most once."
The second "bullet" at the top of the second column is not an
extension but an implementation issue (I think).
[page 29]
Restore the mention of the alternate name CALL/CC at the end of the
rationale for CALL-WITH-CURRENT-CONTINUATION.
[page 39ff]
Add index entries for `identifier' and `variable'.
------------------------------------------------
[Following are my responses to JAR's specific questions on language and
presentation. His question is left adjusted, my response is preceded
by ` ******* '.] I've omitted some questions/proposals I agree with
or have no comment on.
Questions on LANGUAGE
I left CASE as is, using EQV? as the comparison, and I explicitly stated
that the object ought to be boolean, character, number, or symbol. But
shouldn't it allow empty lists, vectors, and strings, too?
******* Define it in terms of EQV? and define (EQV? '() '()) ==> #T.
******* This is consistent with Common Lisp's CASE, which uses EQL.
May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND
be Common Lisp compatible? [Bartley says sharing would be a gratuitous
incompatibility with CL, I'm invlined to agree.]
******* Don't share structure with any argument but the last.
Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?
******* Yes.
Should APPEND! disallow () as other than last argument?
******* No.
Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?
******* Yes.
What should be said, if anything, about the desirability and/or legality
of EQUAL? failing to terminate? Rozas thinks an implementation with
this property is in error.
******* Leave it as it is. It is `an error' not to terminate.
In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it
would be a good idea to explicitly state that closing a closed port
should be a no-op instead of an error.
******* Yes.
-----
Questions on PRESENTATION
Should the various examples which use DEFINE be changed to use the
(define (foo ...) ...) syntax instead of (define foo (lambda ...))?
Several people have told me that all those LAMBDA's could unnecessarily
intimidate SIGPLAN readers.
******* LAMBDA is what it's all about; but I don't really care.
There are two places (in descriptions of let* and letrec) where it is
necessary to create a lambda body in a context (such as the tail of a
BEGIN) where there isn't one already. What is the cleanest way to do
this? Is (let () ...) ok, or would ((lambda () ...)) or something else
be better?
******* Use (LET () ...).
Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?
******* It's OK where it is, but see my comments above.
-----
Notes on LANGUAGE
The selectors in a CASE expression must be distinct.
******* OK.
I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.
******* Yes--I don't like the rewrite in the new draft.
BOOLEAN? is essential.
******* I suppose so.
No agreement on COND or BEGIN. I have left them as in RRRS.
[To do: fix the BNF to agree!]
******* Yes, but keep `test' instead of `guard'.
The RRRS explicitly allows internal definitions in the body of a LETREC.
They are scoped to the body only, not to the entire expression. I can
flush this "feature" if a movement arises to do so; it seems sufficient
to me to permit only expressions (not definitions) in the body.
******* Allow them.
The list to which the rest argument gets bound must be newly allocated.
******* Yes. Common Lisp screwed this up.
There was strong sentiment both for removing REC and for removing
NAMED-LAMBDA. However, the sentiment was not unanimous. I don't
understand why it should have matterred so much, since neither is an
essential feature. If these are present, shouldn't everyone's favorite
features be present too? ... Supporters of REC included Kent Dybvig and
Dan Friedman. Supporters of NAMED-LAMBDA included Jim Miller and Henry
Wu. In addition, Bill Rozas insisted that if REC stayed, then
NAMED-LAMBDA must stay too, but he was willing to see both go.
******* Keep them both.
APPEND! necessarily clobbers its arguments (other than the last and
empty ones).
******* Yes. It's meaningless otherwise.
Many people wanted the number predicates pruned (i.e. choose between <
and <?). No agreement here, so both stay.
******* I still can't understand why we can't get agreement, but
******* having both forms is OK until we do. I'll live with either form.
The case sensitivity issue was a very sensitive one (so to speak). I
did not change the report's stance of symbol case insensitivity.
******* Let's remain case-insensitive.
-----
Notes on PRESENTATION
******* I agree with (or don't care about) the rest of the issues.
-------------------------------------------------
BTW, I generally agree with Will's answers to KMP's questions.
Regards,
David Bartley
-------
∂29-May-86 1610 @MC.LCS.MIT.EDU,@CSNET-RELAY.ARPA,@boethius.think.com:gls@AQUINAS.THINK.COM hash-consing
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 16:10:42 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:28 EDT
Received: from [30732002700] by CSNET-RELAY.ARPA id a003087; 29 May 86 16:54 EDT
Received: from BOETHIUS.THINK.COM by Godot.Think.COM; Thu, 29 May 86 16:50:11 edt
Date: Thu, 29 May 86 16:50 EDT
From: Guy Steele <gls@GODOT.THINK.COM>
Subject: hash-consing
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA,
RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: gls@AQUINAS.THINK.COM
In-Reply-To: <12210304495.60.BARTLEY@CSC60>
Message-Id: <860529165056.1.GLS@BOETHIUS.THINK.COM>
Dr. Eiichi Goto has done the greatest amount of work on hash-consing;
I think he may have invented the idea. See the bibliography of the
paper by Goto et al. in the 1982 Lisp conference.
--Guy
∂29-May-86 1706 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: global definitions
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 17:05:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 18:47:48 EDT
Received: from tektronix by csnet-relay.csnet id a003857; 29 May 86 18:45 EDT
Received: by tektronix.TEK (5.31/6.12)
id AA25806; Thu, 29 May 86 15:24:54 PDT
Received: by tekchips (5.31/5.14)
id AA13361; Thu, 29 May 86 15:29:04 PDT
Message-Id: <8605292229.AA13361@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: global definitions
Date: 29 May 86 15:29:02 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Though I spent time in Indiana, I must join with JINX and Andy in
protest against the very idea of global definitions. If we must
have global definitions, I propose that the syntax be
(SETF (SYMBOL-FUNCTION 'FOO) ...)
so as to avoid gratuitous differences between Scheme and Common Lisp.
As prelude to more serious comments, let me summarize the status quo:
INCREMENTAL DEFINE: Not in the report, but appears in S&ICP. Supported
only by MIT Scheme, though T has something similar.
INTERNAL DEFINE: Optional in the report, pervasive in S&ICP. Alternative
syntax for LETREC. Supported by MIT Scheme, PC Scheme, and MacScheme.
TOP-LEVEL DEFINE: Essential in the report. It is up to the programming
environment whether top-level definitions are implemented as global
bindings, incremental bindings, or assignments; it makes very little
semantic difference. Supported by everyone.
I don't want to give in to Guy's suggestion that internal definitions be
dropped entirely because it would return us to the days when we couldn't
read each other's code. The implementations that support internal
definitions for compatibility with S&ICP would go on supporting them,
while people using Chez Scheme and Scheme-84 would write syntactically
identical code that does something completely different. If everyone
could agree not to use DEFINE except at top level I might agree with Guy,
but that just isn't going to happen. (For instance, the idea of dropping
internal DEFINE wouldn't even have come up if the people at Indiana
weren't so insistent on using the word DEFINE at places other than top
level.)
Though I once programmed in the Indiana style, I have found it easy to
switch to the new idiom:
(define foo)
(define bar)
(let (<local state>)
(set! foo ...)
(set! bar ...))
I am partly in the dark because I have not yet received Chris Haynes's
message, but I suspect that folks at Indiana have not really given the
above idiom a chance because the one message I have received says only
that both "define!" and "global-define" were tried.
In short, I'm not a fan of the internal definition syntax, but I vote in
favor of keeping it in the report so as to prevent the syntax from being
used with two incompatible semantics.
Peace, Will
∂30-May-86 1432 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA definitions; APPEND!; etc
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86 14:31:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 17:30:31 EDT
Received: from tektronix by csnet-relay.csnet id ac00463; 30 May 86 17:19 EDT
Received: by tektronix.TEK (5.31/6.12)
id AA16726; Fri, 30 May 86 12:04:15 PDT
Received: by tekchips (5.31/5.14)
id AA21283; Fri, 30 May 86 12:08:30 PDT
Message-Id: <8605301908.AA21283@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: jar@MC.LCS.MIT.EDU
Subject: definitions; APPEND!; etc
Date: 30 May 86 12:08:29 PDT (Fri)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Since the report won't appear in SIGPLAN Notices until after the Lisp
conference, I too favor waiting another month.
----------------------------------------------------------------
At Brandeis we agreed that (BEGIN (DEFINE ...) (DEFINE ...)) would be
flattened when it appeared at the beginning of a lambda body, but I
forgot to mention that in the RRRS. It seems simplest to extend that
flattening to apply to the top level as well by changing the formal
syntax of <definition> to be
<definition> --> (define <variable> <expression>)
| (define (<pattern> <formalz>) <body>)
| (begin <definition>+)
This still rules out things like
(begin (define up)
(define down)
(let ((n 0))
(set! up (lambda () (set! n (1+ n)) n))
(set! down (lambda () (set! n (-1+ n)) n))))
After writing the new syntax for <program> that would be needed
to allow this, I decided it isn't worth it.
----------------------------------------------------------------
I prefer dropping both NAMED-LAMBDA and REC to leaving them both
in.
----------------------------------------------------------------
I have a few remarks to add to some of David Bartley's comments.
>Add "in the same order" at the end of "Two procedures are
>operationally equivalent iff ... they return the same value and
>perform the same side-effects." (Or is that implied by `having the
>same side-effects'?)
There is still considerable research directed toward formulating
a satisfactory notion of operational equivalence for procedures
with side effects in the presence of concurrency, or even in the
presence of asynchronous interrupts. To see that the definition
on page 14 is inadequate, consider that
(lambda (x) (set! x (1+ (1+ x))) x)
and
(lambda (x) (set! x (1+ x)) (set! x (1+ x)) x)
are operationally equivalent but
(lambda (y) (set! x (1+ (1+ y))) x)
and
(lambda (y) (set! x (1+ y)) (set! x (1+ x)) x)
are not.
>APPEND! always side-effects all but its last argument.
No, APPEND! should not be required to perform side effects. This is not
as silly as it may sound. In an implementation using the Hewitt-Lieberman
gc algorithm, for example, side effects to sufficiently old structures are
likely to be more expensive than consing. APPEND! should be free to decide
for itself which technique is fastest.
I would feel differently if APPEND! returned an unspecified value, as
does VECTOR-SET!.
>Rephrase "to make all user populations happy". >I'm< not happy with
>having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!
I have been one of the main holdouts here, but I too am now willing to
settle for either one.
>If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
>flush it! This is only the tip of the iceberg when it comes to handy
>little utility functions for building editors.
I agree. I think we should write other documents, however, to describe
the portable Scheme libraries that people have written, and we should
work on improving portability and availability.
peace, Will
∂30-May-86 1650 @MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA Re: Embedded DEFINE forms
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86 16:49:47 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:48:45 EDT
Received: from ti-csl by csnet-relay.csnet id ab01528; 30 May 86 19:37 EDT
Received: by tilde id AA15347; Fri, 30 May 86 17:50:20 cdt
Date: Fri 30 May 86 17:42:25-CDT
From: Don Oxley <OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Embedded DEFINE forms
To: gls%Think.COM@CSNET-RELAY.ARPA, rrrs-authors%mc@CSNET-RELAY.ARPA
In-Reply-To: <8605290514.AA08588@Godot.Think.COM>
Message-Id: <12210915540.62.OXLEY@CSC60>
I have generally avoided getting into these discussions as David has
represented our viewpoints very effectively. However, I am becoming
concerned about what looks like a potentially destructive argument over
DEFINE.
It seems to me that it is unlikely that very many users outside of the
aficionados at MIT and IU are likely to use embedded DEFINE at all -
except as they may have seen it in S&ICP. I would hate to see
"outsiders" back away from using SCHEME because they see a religious war
going on within the community.
My first suggestion is to leave it as we decided at Brandeis - based on
the notion that we had agreement (even if grudging) and we do not have
an agreement on a change. Possibly better is Guy's suggestion to
leave it undefined (which I think is roughly equivalent to letting the
dominant dialect win).
I would be very hesitant for us to have to change PC Scheme in an
incompatible direction. I'll hazard a guess that PCS is or is close to
becoming the most widely used Scheme today, so we are trying to be
somewhat careful about compatibility (although as I said, I doubt if
this will affect very many users). Either leaving the position as it is
or making it undefined would leave PCS alone.
Please, let's not let this become a divisive issue that hurts the spread
of Scheme to those who don't care about so technical an issue and
merely what to know what the langauge does and does not do.
--Don
-------
∂30-May-86 1703 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA procedure (Tnx)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86 16:58:49 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:57:43 EDT
Received: from northeastern by csnet-relay.csnet id ac01577; 30 May 86 19:48 EDT
Date: Fri, 30 May 86 10:04 EST
From: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: procedure (Tnx)
Thanks to Jonathan for so promptly accepting my suggestion that we delay
publication until these issues are resolved.
-- Mitch
∂30-May-86 1703 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA define -- a modest proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86 17:03:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:59:54 EDT
Received: from northeastern by csnet-relay.csnet id ae01577; 30 May 86 19:49 EDT
Date: Fri, 30 May 86 10:40 EST
From: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: define -- a modest proposal
I think it is clear that we do not have a consensus on the semantics of
internal DEFINE. My understanding of the compromise reached at Brandeis was
that lexically nested DEFINE would retain the MIT semantics, whereas
the IU semantics could be obtained by using DEFINE! . The current report
does not appear to be compatible with that compromise, because it would appear
necessary to do a
(define foo 'hunoz)
at top-level before one can legally do a set! on foo from an interior scope.
Analyzing this situation, there are two operations involved in a define:
1. Binding the identifier to some location.
2. Storing a value in that location.
The latter operation is clearly doable by set!, so the only issue is #1.
The MIT semantics has DEFINE performing #1 on the current scope. The
advantage of this proposal is that it is uniform on both "top-level" and
interior scopes. The disadvantage is that it essentially creates a new scope
(region) in the program which is not delimited by parentheses. [Perhaps the
grammar could be fixed to recognize this new, non-list-structure phrase?].
This is an unpleasantness at the top level which I do not think we understand.
[Perhaps we should separate DEFINE into two procedures:
(make-local-variable 'foo)
(set! foo value)
[shades of GNU Emacs-Lisp!!]]
[Another, separate, argument against including internal define as an optional
feature in the report is that, unlike the other optional features in the
report, it requires pervasive modifications in many other sections of the
report].
Nevertheless, I am not yet arguing for elimination of internal defines from
the report, in keeping with the compromise reached at Brandeis.
What I will argue for is the following:
An implementation may have a top level (initial, whatever) environment in
which every possible identifier is bound (though only some are initialized).
This would allow programs in that implementation to do a set! on a global
variable (excuse me, a variable in the current top-level environment) from an
internal scope without having to explicitly bind the variable in the initial
scope. It would also allow MIT-style define to proceed, as it does not
require the existence of a distinguished global environment.
I think this proposal retains the spirit of the Brandeis agreement on this
issue.
Mitchell Wand
∂31-May-86 0108 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define -- a modest proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 01:08:38 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 00:34:03 EDT
Date: 31 May 1986 00:32 EDT (Sat)
Message-ID: <JINX.12210979336.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: define -- a modest proposal
In-reply-to: Msg of 30 May 1986 11:40-EDT from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
I may have misunderstood your message, but I'm afraid you are still
confusing (local static) INTERNAL DEFINE with (dynamic, horrible
semantically) INCREMENTAL DEFINE. They have nothing in common (except
sharing the keyword).
INTERNAL DEFINE does NOT create a new scope. The scope is created by
the surrounding LAMBDA, LET, or LETREC expression, and is therefore
bounded by parentheses.
(let ()
(define foo ...)
(define bar ...)
<some expression>)
should be exactly equivalent to
(letrec ((foo ...)
(bar ...))
<some expression>)
As a matter of fact, I originally implemented LETREC in MIT-Scheme
(and it is still implemented in this way in MIT CScheme, I believe),
by transforming the second expression into the first.
Thus, the (INTERNAL) DEFINEs do not establish the context. The
context is established by LET.
Your proposal of separating DEFINE into
(make-local-variable 'foo)
(set! foo value)
seems to violate this semantics. It appears to be advocating for
INCREMENTAL DEFINE, which is NOWHERE on the report. Indeed, MIT
Scheme has a primitive procedure which implements INCREMENTAL DEFINE,
on top of which MAKE-LOCAL-VARIABLE could be implemented trivially,
but we are certainly not advocating for a feature we don't feel
comfortable with ourselves.
INTERNAL DEFINE is purely declarative, it does not involve ANY side
effects. INCREMENTAL DEFINE, on the other hand, is mostly imperative,
and involves side effecting environments.
As far as I know (please correct me on this), INTERNAL DEFINE has no
semantic problems, its only problem is purely syntactic: it makes the
evaluator (compiler, syntaxer, code walker, whatever) harder to write
since it has to collect all the definitions which occur in a scope
before processing the expressions. Since the report only allows
definitions as the very first thing in a block (it's the only place
where they make sense), collecting them is trivial.
∂31-May-86 0331 NET-ORIGIN@MC.LCS.MIT.EDU wanted: teaching do's and dont's
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 03:31:21 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 06:25:28 EDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 Dec 85 15:20:57 EST
Received: from bostonu by csnet-relay.csnet id ae01055; 23 Dec 85 15:15 EST
Received: by bu-cs.ARPA (4.12/4.7)
id AA22857; Mon, 23 Dec 85 14:41:29 est
Date: Mon, 23 Dec 85 14:41:29 est
From: Edward Sciore <sciore%bostonu.csnet@CSNET-RELAY.ARPA>
To: SCHEME@mit-mc.ARPA
Subject: wanted: teaching do's and dont's
I will be teaching from the "Structure and Interpretation..." book
spring semester. Students will be sophmores/juniors with at least 2
semesters of Pascal behind them. Does anybody know of things that I
should be wary of? How fast should I go in order to get through chapter
4? Will their previous programming experience allow the students to
handle the material more easily? Any tips people have discovered
will be appreciated. Thanks.
Ed Sciore
Boston University CS Dept
sciore@bostonu.CSNET
∂31-May-86 0539 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU wanted: teaching do's and dont's
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 05:38:57 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 08:34:33 EDT
Date: 31 May 1986 08:33 EDT (Sat)
Message-ID: <JINX.12211066871.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Edward Sciore <sciore%bostonu.csnet@CSNET-RELAY.ARPA>
Cc: SCHEME@MC.LCS.MIT.EDU
Subject: wanted: teaching do's and dont's
In-reply-to: Msg of 23 Dec 1985 14:41-EST from Edward Sciore <sciore%bostonu.csnet at CSNET-RELAY.ARPA>
Our experience at MIT is that it is often the case that students with
previous programming experience suffer MORE in the course than
students without such experience, since the latter are not biased.
In particular, students familiar with BASIC and FORTRAN (and probably
PASCAL) tend to have a hard time adapting to the functional style
encouraged by Scheme. They view DEFINE as assignment, which it isn't,
and even if they get used to the functional style, when assignment
(SET!) is finally introduced, they often revert to the ugly imperative
style. They sometimes have this crazy notion that imperative style is
more efficient. Interestingly enough, code with side effects is often
LESS efficient in T and in MIT Scheme with the new compiler.
Although Pascal is, like Scheme, lexically scoped, students do not
have a really hard time accepting this, so I'm not sure it's a real
advantage.
Obvious potential stumbling blocks, beyond style:
Absence of VAR parameters, used sometimes to "return" multiple values in
Pascal. This is usually done in Scheme (in dialects without multiple
values) in one of two ways: returning a data structure (list or
vector) with the appropriate contents, or passing an explicit
continuation with many parameters to the procedure that wants to
return multiple values, which will, instead of returning, invoke its
explicit continuation with the multiple "returned" values.
Absence of iteration constructs. Standard Scheme has DO, but it is
not used in S&ICP, in fact, we did not even have it in MIT Scheme
until the report describing Standard Scheme came about. Iteration has
to be achieved through syntactic recursion. One of the reasons for
not having syntactic sugar in MIT Scheme (originally) was to emphasize
this point, and force students to deal with the issue.
Absence of explicit allocation. Memory management in Scheme is
automatic, rather than manual.
Eventually, the fact that thanks to tail recursion and first class
procedures (and worse, cwcc, but this is not covered in S&ICP), Scheme
is a completely unstructured language (in the sense of "structured
programming"). Procedures (lambda expressions) are labels, and
application is GOTO, and any arbitrary control structure can be built
on top of this.
PS: There is a teacher's manual for S&ICP written by Juile Sussman.
It is very good. It contains more examples, more problems, and a very
detailed description of where students go wrong in various places, and
what points need further emphasis. I believe (HAL or GJS can correct
me here) that it can be obtained through McGraw Hill.
∂31-May-86 0738 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA sentiments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 07:37:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 31 May 86 10:37:01 EDT
Received: from indiana by csnet-relay.csnet id aa06940; 31 May 86 10:36 EDT
Date: Fri, 30 May 86 15:34:53 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: sentiments
Cc: jar@MC.LCS.MIT.EDU
I believe I must explain to you why I am as upset about internal-define
as I am. This report has been a long time in coming and as it approaches
its final form, it begins to look quite splendid. So much so that I
believe that its potential for generating converts will be quite
substantial. That was, in fact, one of its goals. However, we Schemer's
have had the freedom for several years of writing code for papers and
books in just about any dialect we felt the audience could/would follow.
Scheme has been a fabulous tool for that purpose. The simplicity of the
language and the elegance of its definition attracted us and I am sure
many of you towards it. How simple was it? In the presence of macro
expansion, we needed the following 4 special forms: "quote", "lambda",
"if", and "set!". Many implementations began to exist on micros. One
of my students, Mark Meyer, implemented an entire Scheme system including
engines, macros, a compiler, the run time support in 5k bytes on a
IBM PC. He did this as an undergraduate in the 5 weeks following my
undergraduate programming languages course. Now it was the case that
"set!" assigned to the closest lexical "rib" and we assumed that the
bottom rib had all known identifers assigned to either "unbound" or,
in the case of +, to some value. This really was simple. With this view,
define was merely an alias for set!. However, define's value was its
first argument and set!'s value was its second argument.
This is how things were prior to the Brandeis meeting. As I recall the
feeling at the Brandeis meeting most of us were willing to go along with
the idea of limiting the use of "define" internally to the semantics of
SI&CP. This was in the interest of good feeling about not undermining
their book. I hope everyone understands that I do not want to undermine
their book, although I would like to see them rewrite it without internal
defines. However, when I went along with this view I had underestimated
how damaging this decision would be to the characterization of Scheme being
a simple language. I was expecting a "comment" in the report that stated
that "use of define within the text of a program would be restricted to
the use as given in SI&CP." Instead, the definition of "lambda" got changed.
Instead, begin must be added to the list of special forms. Instead the
macro for "letrec" must be conscious of it by having the body be
"(let () <body>)" where it should be <body>. Instead define must be added to
the list of special forms. Instead the semantics of "set!" are weakened
so that it is not possible to just get by with "set!" and ignore "define".
Instead we must do something "special" with "lambda", "named-lambda",
"let", "let*", and "letrec".
We have taken a rather elegant language and made it elitest. I wanted
all of my students to be able to implement "Scheme" when they walked out
of my course, now that is no longer possible. It was a great beauty of
Scheme that the four mentioned special forms along with identifiers and
application were the only syntax. It was wonderful that a CPS interpreter
for Scheme was all that was necessary to come to grips with in order to
understand the run-time architecture of Scheme.
My argument with internal-define is not that it is good or bad, but
that the subtlety of its definition is unnecessary with judicious use
of letrec and letrec should be a trivial macro. What happened?
I have never liked internal defines. I thought they were harmless
until I saw what havoc they introduced to the Report. I am trying
desperately to convince everyone that we made a mistake and we should
do everything in our power before we go public on this Report to
wait until we impose internal defines on everyone.
Dan
∂31-May-86 1608 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU sentiments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 16:08:15 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86 19:07:29 EDT
Date: Sat, 31 May 86 18:53:02 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: sentiments
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].923375.860531.JAR>
Date: Fri, 30 May 86 15:34:53 est
From: Dan Friedman
Sent-by: Kent Dybvig
... define was merely an alias for set! ...
This is how things were prior to the Brandeis meeting.
This is how things were AT INDIANA prior to the Brandeis meeting. At
Yale and MIT they somewhat different (although not as different as you
suppose) and had been since at least 1981. Your quest for elegance is
noble but please try not to equate your own version of Scheme with
Scheme.
As I recall the feeling at the Brandeis meeting most of us were
willing to go along with the idea of limiting the use of "define"
internally to the semantics of SI&CP. This was in the interest of
good feeling about not undermining their book. I hope everyone
understands that I do not want to undermine their book, although I
would like to see them rewrite it without internal defines.
However, when I went along with this view I had underestimated how
damaging this decision would be to the characterization of Scheme
being a simple language. I was expecting a "comment" in the report
that stated that "use of define within the text of a program would
be restricted to the use as given in SI&CP." Instead, the
definition of "lambda" got changed.
I don't understand. Is it really the case that S&ICP never ever uses
internal defines in the body of a lambda? I'll check. In any case, if
internal definitions exist at all, LAMBDA is the ONLY form that's
affected, after macro expansion.
Instead, begin must be added to the list of special forms.
Not true, and I'm don't understand why you think so. Note that I
clearly put BEGIN in the "derived expression types" section. I will
include the usual expansion of it in a future draft; I forgot to note
that this was on my list of things to do.
Instead the macro for "letrec" must be conscious of it by having the
body be "(let () <body>)" where it should be <body>.
I proposed flushing internal definitions in the body of a letrec for
exactly this reason. But I don't see this as increasing the complexity
of LETREC significantly, and I was wrong to draw attention to it. I'll
try to figure out how to make this smoother.
Instead define must be added to the list of special forms.
What do you mean? Definitions aren't even expressions!
Instead the semantics of "set!" are weakened so that
it is not possible to just get by with "set!" and ignore "define".
As has been explained innumerable times, there is no way to avoid this
and have a language which is at all coherent with T and MIT Scheme.
Note that in all programming languages of the Algol/Pascal/C variety it
is an error to assign to an undeclared variable. That MIT Scheme and T
(and thus RRRS Scheme) also have this property is not coincidence.
Instead we must do something "special" with "lambda",
"named-lambda", "let", "let*", and "letrec".
Certainly the report is muddled, and I must accept the blame for some of
this muddle. I introduced a lot of the nonsense you're complaining
about into this version of the report in a quest for accuracy. I agree
with your complaint that internal definitions are intrusive, and I'll do
what I can to remedy the situation.
We have taken a rather elegant language and made it elitest.
I don't understand this use of that term.
I wanted all of my students to be able to implement "Scheme" when
they walked out of my course, now that is no longer possible.
This is false. Internal defines are not essential. If by "Scheme" you
mean absolutely everything described in the report, I would expect that
internal definitions (which can be implemented with a very small amount
of code) would be the least of any implementor's worries. What about
number I/O?
It was a great beauty of
Scheme that the four mentioned special forms along with identifiers and
application were the only syntax. It was wonderful that a CPS interpreter
for Scheme was all that was necessary to come to grips with in order to
understand the run-time architecture of Scheme.
Why isn't this still true?
My argument with internal-define is not that it is good or bad, but
that the subtlety of its definition is unnecessary with judicious use
of letrec and letrec should be a trivial macro. What happened?
How do internal definitions make LETREC more complicated? The (LET ()
...) (which would otherwise be a (BEGIN ...)) is trivial compared to
the rest of what LETREC has to do, and doesn't even have to be there at
all if you're not implementing the full language.
I have never liked internal defines.
Thanks for telling me, I hadn't figured this out.
I thought they were harmless
until I saw what havoc they introduced to the Report. I am trying
desperately to convince everyone that we made a mistake and we should
do everything in our power before we go public on this Report to
wait until we impose internal defines on everyone.
I'll do what I can to fix the presentation; I can at least certainly
make internal definitions less intrusive than they were in the RRRS. I
hope that will be sufficient. Personally, I wouldn't mind removing
internal definitions from the language, although special treatment of
definitions at top level of a file (which is another story altogether)
must stay. If you can convince everyone, including Sussman and Abelson,
that internal definitions should be flushed, then I'll flush them. If
you must persue this, I suggest you talk to Sussman on the telephone
about this; he isn't reachable by electronic mail until June 20, I
think. I'll try to find his phone number at Princeton or HP or wherever
he is.
Why does this question arise at this moment? I am angered by the
untimeliness of this debate. Why didn't it come up when the idea of
printing the report in SIGPLAN was first mentioned? This part of the
language hasn't changed.
Jonathan
∂31-May-86 2319 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU define -- a modest proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86 23:19:38 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 02:18:12 EDT
Date: Sun, 1 Jun 86 02:03:01 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: define -- a modest proposal
To: WAND%northeastern.edu@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].923455.860601.JAR>
Date: Fri, 30 May 86 10:40 EST
From: MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
I think it is clear that we do not have a consensus on the semantics
of internal DEFINE.
This isn't clear to me. I thought we had always agreed that internal
definitions were just sugar for LETREC (see Will's message of 11 November
84, excerpted below).
My understanding of the compromise reached at
Brandeis was that lexically nested DEFINE would retain the MIT
semantics, whereas the IU semantics could be obtained by using
DEFINE! . The current report does not appear to be compatible with
that compromise, because it would appear necessary to do a
(define foo 'hunoz)
at top-level before one can legally do a set! on foo from an interior scope.
At first I thought that you had misremembered, but I just went back to
the archives, and you are right. However, DEFINE! was later flushed --
without any liberalization of SET! . The discussion was obviously
incomplete (as you can tell by reading it), and we're completing it now.
Will did the right thing since he flushed features that not everyone
wanted, namely (a) DEFINE! and (b) an environment in which SET! could
cause unbound variables to become bound. See the Appendix to this
message for the exchange.
I was moderately happy with how that turned out and implicitly assumed
that if people had serious troubles with the RRRS they would have spoken
up ages ago. My attempts to clarify things have apparently drawn
attention to issues which have been peacefully asleep for over a year.
Analyzing this situation, there are two operations involved in a define:
1. Binding the identifier to some location.
2. Storing a value in that location.
The latter operation is clearly doable by set!, so the only issue is #1.
The MIT semantics has DEFINE performing #1 on the current scope. The
advantage of this proposal is that it is uniform on both "top-level" and
interior scopes. The disadvantage is that it essentially creates a new scope
(region) in the program which is not delimited by parentheses.
This is true, the region is only the <body> of the LET or whatever
expression, not the entire expression, so the region isn't delimited by
left and right parentheses. The region of a definition at top level of
a file is similarly not delimited by parentheses, although for a
slightly different reason. I wouldn't say the definition creates the
scope, I'd say that the scope is created by the expression in whose body
the definition appears. But what is so unusual about this? The region
of a binding created by LET is also not delimited by parentheses; it's
not the entire LET expression.
[Perhaps the
grammar could be fixed to recognize this new, non-list-structure phrase?].
What change do you suggest? Why don't <body> and <program> foot the
bill? A <body> is exactly the region of the bindings specified by
internal definitions which begin it. A <program> (which, I suppose, is
the concatenation of all the files comprising a running Scheme program,
or something like that) is the region of bindings created by top level
definitions.
This is an unpleasantness at the top level which I do not think we
understand.
I guess I'm losing track of what you're saying. I agree that there is
much unpleasantness, but to which one are you referring?
In Algol 60 a <program> is a <block> or a <compound expression>, so
Algol 60 has the property you want, that regions are always fully
parenthesized (by BEGIN ... END). I always rationalized Scheme's lack
of "outermost parentheses" by the fact that there would be no point in
having them if you would always have to write them -- they would be
redundant. I imagine that those parentheses are there, just outside the
edge of my files, providing a region for my files' top level bindings to
live in. (The T compiler actually puts the parentheses there, treating
a file boundary as a sort of a macro.)
The main unpleasantness I see is the syntactic oddity that a <program>
is a sequence of intermixed <expression>s and <definition>s (it's very
important that <definition>s aren't <expression>s!), whereas a <body> is
a sequence of <definition>s followed by a sequence of <expression>s. I
think I suggested fixing this a while ago (whether to people at MIT or
to RRRS-Authors I don't remember), so that <program>s and <body>s could
have the same syntax and semantics (if internal definitions were
supported at all, that is), but this suggestion was not well received.
This change would make Scheme like Algol 68, which also allows one to
intersperse statements and declarations within a "series" (the region
("range") of a declaration includes previous statements and declarations
in its "series"). The other way to resolve the inconsistency is to be
like Algol 60 and require that all the definitions in a program go at
the top, before any statements (expressions), but somehow I don't think
people would buy that.
[Perhaps we should separate DEFINE into two procedures:
(make-local-variable 'foo)
(set! foo value)
A reasonable idea. In MIT Scheme, (make-local-variable 'foo) is written
(define foo). (Or do you really mean a procedure?) If people like this
feature (which causes the variable to become bound but unassigned, like
in LETREC) I'd be happy to see it go into the report. It is bothersome
that one has to specify an initial value, and this seems as good a way
as any to avoid having to do so.
[Another, separate, argument against including internal define as an
optional feature in the report is that, unlike the other optional
features in the report, it requires pervasive modifications in many
other sections of the report].
I agree that the presentation is bad. This is a real problem which, as
I said in my message to Dan, I think I can fix, by going back to
something closer to Will's approach, which was much less intrusive. I
take full responsibility for having screwed this up.
What I will argue for is the following:
An implementation may have a top level (initial, whatever) environment in
which every possible identifier is bound (though only some are initialized).
This would allow programs in that implementation to do a set! on a global
variable (excuse me, a variable in the current top-level environment)
[Can you define "current"?]
from an
internal scope without having to explicitly bind the variable in the initial
scope. It would also allow MIT-style define to proceed, as it does not
require the existence of a distinguished global environment.
I think this proposal retains the spirit of the Brandeis agreement on this
issue.
If people generally think it's OK if this is documented as an optional
language feature (as was DEFINE! previously), I don't have too much
problem with putting it in the report, if it's accompanied by some
mention of the fact that some implementations have principled reasons
for not having this feature. (Dan has complained to me, however, that
he doesn't want the report to contain advertisements for random features
of various dialects, so I wouldn't know quite how to do this.) My main
complaint is that it would be nice to be able to support as many as
possible of the report's non-essential features in T and MIT Scheme, and
it would be a substantial amount of work to implement this particular
feature in T and MIT Scheme; causing assigned variables to become bound
in an appropriate contour involves a bothersome non-local code
transformation.
The MIT Scheme and T designers have worked hard to implement truly
block-structured languages which, like Algol, have no distinguished
top-level environments. (Algol 68's "standard prelude" and its
mechanism of "particular-programs" is block structure to the max -- can
someone tell me what would correspond to the proposed SET! extension in
Algol 68?) Legitimizing binding-from-a-distance (or environments in
which all variables are bound, which amounts to the same thing) in the
Scheme report is a threat to the pedagogical and engineering effort
we've put in. Of course, de-legitimizing unprepared SET!'s is
apparently a threat to your investment. I thought the compromise in the
RRRS was a good one considering how different our world views were.
With apologies to you and Dan for the angry tone & the abundance of
parenthetical remarks. I'm tired.
Jonathan.
------
APPENDIX. Historical record of the DEFINE! and SET! debate.
Clinger, 11 Nov 84, preliminary report on the workshop:
(DEFINE id expr) allows top-level definitions of variables. Its
semantics at top level are similar to the semantics of
(SET! id expr). The difference is that if id is not already
bound to a location, then the DEFINE form binds id before
performing the assignment, whereas it would be a mistake to
perform a SET! on an unbound identifier.
Optionally, (DEFINE! id expr) is equivalent to (DEFINE id expr)
when typed at the top level. Within code, (DEFINE! id expr) is
equivalent to (SET! id expr) unless id is unbound, in which case
the DEFINE! form creates a new top level binding for id before
performing the assignment.
Optionally, DEFINE may be used for internal definitions as in MIT
Scheme and in the book by Abelson and Sussman. If allowed at
all, internal definitions are permitted only in the bodies of
LAMBDA, LET, LETREC, and similar binding constructs. Furthermore
they must precede the rest of the body. With these restrictions,
the semantics of internal definitions can be explained in terms
of LETREC. For example, ...
Pitman, 6 Dec 84:
The term "top-level binding" is ... completely vague in DEFINE!'s
definition.
Rees, 14 March 85:
... And incidentally, I don't remember the rationale for having both
DEFINE! and DEFINE. I understand why DEFINE shouldn't have hairy
syntax, but what does DEFINE! give you that the stripped-down DEFINE
doesn't?
Clinger, 18 March 85, "final" draft of report:
(define! var expr) special form
If var is bound, then the define! form is equivalent to the
corresponding set!. If var is unbound, however, define! binds
var in the global environment before performing the assignment.
Haynes and Friedman, 27 Mar 85:
DEFINE! and DEFREC! should go away. (Yes, We were among those who
wanted them originally, but they aren't worth it.) We're not fond of
DEFINE either and wish it could go the same way, or at least be
optional.
Bartley, 29 March 85:
I'm willing to lose DEFINE! and DEFREC!, as Chris and Dan suggest.
Rozas, 27 March 85:
How am I supposed to define things if both DEFINE! and DEFINE
go away?
Haynes, 29 March 85, answering Rozas:
With SET!, provided one assumes that all identifiers are initially bound in
the global environment, or that SET! can extend the global environment.
With the exception of MIT's Scheme, this is what existing systems do. If MIT
is unwilling to change this, then we are reluctantly stuck with DEFINE.
Hanson, 30 March 85, answering Haynes:
This is a terrible idea. It seems that the ability to have many
different environments in which to perform incremental definitions has
been consistently overlooked by almost everyone except MIT Scheme and
T. Anyone who has ever tried to program a BIG system, and by that I
mean something over 500-1000 pages of code, knows that this kind of
packaging is **ESSENTIAL**!! So please don't try to take this away.
Haynes, 31 March 85, answering Hanson:
We grant the importance of such a facility, and are not trying to take it
way; but there is no concensus on how to provide such a facility, so it
is too soon to standardize on one. (Similarly, syntactic extensions
are **ESSENTIAL** to the kind of thing we do here; but it is also too soon
to standardize on a syntactic extension mechanism.)
We were simply debating whether SET! should be required to extend the
global environment if its identifier is unbound (or equivalently, have
everything bound in the global environment to begin with). This would
make DEFINE unessential, though it might still be optional. It has
nothing to do with multiple environments for incremental definition,
except that MIT uses DEFINE for both purposes.
Hanson, 2 April 85, answering Haynes:
What I wanted to say was: if SET! extends the "global" environment,
then that environment has become special in that it is the ONLY
environment that can be extended by interactive definition. This
would seem to preclude the existence of many such environments.
DEFINE eliminates the problem, because it specifies, very precisely,
the environment in which the name is bound.
Clinger, 20 April 85:
define! and defrec! will be flushed altogether.
Note: no one at Indiana replied to Hanson's message, even though it
isn't conclusive. (I don't even think it's true; there could be
multiple "global" environments, and SET!'s could be associated with them
lexically.) Did they assume that SET! would be changed?
∂01-Jun-86 0815 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU define -- a modest proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86 08:14:48 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 11:13:41 EDT
Date: 1 Jun 1986 11:10 EDT (Sun)
Message-ID: <JINX.12211357535.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU, WAND%northeastern.edu@CSNET-RELAY.ARPA
Subject: define -- a modest proposal
In-reply-to: Msg of 1 Jun 1986 02:03-EDT from Jonathan A Rees <JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
In Algol 60 a <program> is a <block> or a <compound expression>, so
Algol 60 has the property you want, that regions are always fully
parenthesized (by BEGIN ... END). I always rationalized Scheme's lack
of "outermost parentheses" by the fact that there would be no point in
having them if you would always have to write them -- they would be
redundant. I imagine that those parentheses are there, just outside the
edge of my files, providing a region for my files' top level bindings to
live in. (The T compiler actually puts the parentheses there, treating
a file boundary as a sort of a macro.)
In MIT Scheme, the syntaxer (a program which translates s-expressions
into Scode, shared by the interpreter and the compiler) "puts" the
parantheses there by building an Scode object called an open-block
around the "top level".
The main unpleasantness I see is the syntactic oddity that a <program>
is a sequence of intermixed <expression>s and <definition>s (it's very
important that <definition>s aren't <expression>s!), whereas a <body> is
a sequence of <definition>s followed by a sequence of <expression>s. I
think I suggested fixing this a while ago (whether to people at MIT or
to RRRS-Authors I don't remember), so that <program>s and <body>s could
have the same syntax and semantics (if internal definitions were
supported at all, that is), but this suggestion was not well received.
This change would make Scheme like Algol 68, which also allows one to
intersperse statements and declarations within a "series" (the region
("range") of a declaration includes previous statements and declarations
in its "series"). The other way to resolve the inconsistency is to be
like Algol 60 and require that all the definitions in a program go at
the top, before any statements (expressions), but somehow I don't think
people would buy that.
I object to mixing internal definitions and expressions. I also
object to mixing top level definitions and expressions although I
admit to being guilty of laziness and occasionally doing the latter.
I never (as far as I can remember) mix them internally, and try to
avoid mixing top level ones also. I would not mind (and might even
applaud) a decision forcing top-level definitions to come first, which
would make the intenal and external cases more symmetric.
[Perhaps we should separate DEFINE into two procedures:
(make-local-variable 'foo)
(set! foo value)
A reasonable idea. In MIT Scheme, (make-local-variable 'foo) is written
(define foo). (Or do you really mean a procedure?) If people like this
feature (which causes the variable to become bound but unassigned, like
in LETREC) I'd be happy to see it go into the report. It is bothersome
that one has to specify an initial value, and this seems as good a way
as any to avoid having to do so.
It is completely unacceptable if it is a procedure (which was my
understanding given the wording and the QUOTE). This would imply
runtime definition (INCREMENTAL DEFINE), rather than static definition
(INTERNAL DEFINE). It also has the problem that if it is a procedure,
it needs the environment where the definition must occur as an
argument. Procedures cannot pick it up at run time.
If it is a special form, the QUOTE is not needed (nor the environment,
which is available at evaluation time), and it could be made static
(as I would expect everyone to want), but then it is exactly internal
DEFINE, so why change names?
I agree that (define foo) is reasonable, although only needed at top
level. I use it often in MIT-Scheme. In particular I use it as an
idiom indicating that the this variable is going to be assigned. I
specify an initial value only when it will not change. It is not
needed elsewhere (in MIT Scheme) because
(let ((foo))
...)
gives me a local binding for FOO which I can then assign.
Note: no one at Indiana replied to Hanson's message, even though it
isn't conclusive. (I don't even think it's true; there could be
multiple "global" environments, and SET!'s could be associated with them
lexically.) Did they assume that SET! would be changed?
JAR, I can't believe YOU have the bad taste to consider this (using
SET! to bind) seriously. One of the features that I dislike the most
from MacLisp and Franz (which is a poor clone of MacLisp), is that
SETQ is used to bind variables. I always use DEFCONST and DEFVAR
before assigning anything. Making this the standard (eliminating
DEFINE) would guarantee that I would never write in the standard
dialect. I'm sure that other people at MIT find this proposal as
distasteful as I do. I don't object to a system (like MacScheme, for
example) where SET! "works", but under no circumstances will I
accept a situation where it is the only way to do it. On such
systems, top-level DEFINE would be a NO-OP, which is fine with me, as
long as it is available.
∂01-Jun-86 2051 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU schedule
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86 20:51:03 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86 23:49:28 EDT
Date: Sun, 1 Jun 86 23:49:21 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: schedule
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 29 May 86 14:36 EDT from Jonathan A Rees <JAR at MIT-AI.ARPA>
Message-ID: <[AI.AI.MIT.EDU].49879.860601.CPH>
I would vote for waiting a little longer before publishing, to get it
done right. It's not terribly important to me that it happen
immediately.
∂01-Jun-86 2343 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: sentiments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86 23:42:59 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 00:59:17 EDT
Received: from indiana by csnet-relay.csnet id a005855; 2 Jun 86 0:57 EDT
Date: Sun, 1 Jun 86 16:21:30 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: Re: sentiments
Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Date: Fri, 30 May 86 15:34:53 est
From: Dan Friedman
Sent-by: Kent Dybvig
First, let me apologize that the note from Dan looked like it was
coming from me. I did "su dfried" and resent the note for him
after his first try failed. I thought that it would put his name
on the note. I also apologize for the length of this note, which
is due primarily to the fact that I have included the entirety of
Jonathan's response to Dan's note.
... define was merely an alias for set! ...
This is how things were prior to the Brandeis meeting.
This is how things were AT INDIANA prior to the Brandeis meeting. At
Yale and MIT they somewhat different (although not as different as you
suppose) and had been since at least 1981. Your quest for elegance is
noble but please try not to equate your own version of Scheme with
Scheme.
This is how things were in the first two Scheme reports, in several
Indiana Schemes, in one North Carolina Scheme, and probably in other
Schemes as well as of the Brandeis meeting.
As I recall the feeling at the Brandeis meeting most of us were
willing to go along with the idea of limiting the use of "define"
internally to the semantics of SI&CP. This was in the interest of
good feeling about not undermining their book. I hope everyone
understands that I do not want to undermine their book, although I
would like to see them rewrite it without internal defines.
However, when I went along with this view I had underestimated how
damaging this decision would be to the characterization of Scheme
being a simple language. I was expecting a "comment" in the report
that stated that "use of define within the text of a program would
be restricted to the use as given in SI&CP." Instead, the
definition of "lambda" got changed.
I don't understand. Is it really the case that S&ICP never ever uses
internal defines in the body of a lambda? I'll check. In any case, if
internal definitions exist at all, LAMBDA is the ONLY form that's
affected, after macro expansion.
I quickly scanned S&ICP and I found two uses of define within let
(pp. 234 and 238), and a mention of the use of a lambda-expression
translator to support internal definitions (p. 440). The obvious
implication to the thoughtful reader is that the authors intend to
allow definitions at the front of a lambda body; however, it might
also be reasonable to only effect "define" (and "let" if the few uses
are considered enough reason to complexify it).
Instead, begin must be added to the list of special forms.
Not true, and I'm don't understand why you think so. Note that I
clearly put BEGIN in the "derived expression types" section. I will
include the usual expansion of it in a future draft; I forgot to note
that this was on my list of things to do.
That begin must be a core special form results from the fact that in
the report, (begin (define ...) ...) must not open up a new scope;
i.e., (begin x y ...) must not be defined as ((lambda () x y ...)),
or the more traditional form ((lambda (t) (begin y ...)) x) where t
does not appear free in (begin y ...). I think of this as the "usual
expansion".
Instead the macro for "letrec" must be conscious of it by having the
body be "(let () <body>)" where it should be <body>.
I proposed flushing internal definitions in the body of a letrec for
exactly this reason. But I don't see this as increasing the complexity
of LETREC significantly, and I was wrong to draw attention to it. I'll
try to figure out how to make this smoother.
You are right, it is not much, but any added complexity is a shame,
especially when the added complexity is to support an innessential
feature (other than the one being described, of course).
Instead define must be added to the list of special forms.
What do you mean? Definitions aren't even expressions!
I wouldn't brag about this! Having already expanded Scheme from
expressions and functions to statements and procedures, we are now
adding declarations. What happened to simplicity?
Instead the semantics of "set!" are weakened so that
it is not possible to just get by with "set!" and ignore "define".
As has been explained innumerable times, there is no way to avoid this
and have a language which is at all coherent with T and MIT Scheme.
Note that in all programming languages of the Algol/Pascal/C variety it
is an error to assign to an undeclared variable. That MIT Scheme and T
(and thus RRRS Scheme) also have this property is not coincidence.
Algol, Pascal, and C are not (typically) interactive languages, nor
do they have such nice features as first-class functions that allow
one to form modules of functions sharing local state/help functions.
I think that it would be possible in any system to have a notion of
a "top-level" lexical environment which implicitly contains bindings
for all things not bound elsewhere. This could be a per-user or
per-module thing; it need not be the outermost lexical environment.
Instead we must do something "special" with "lambda",
"named-lambda", "let", "let*", and "letrec".
Certainly the report is muddled, and I must accept the blame for some of
this muddle. I introduced a lot of the nonsense you're complaining
about into this version of the report in a quest for accuracy. I agree
with your complaint that internal definitions are intrusive, and I'll do
what I can to remedy the situation.
We have taken a rather elegant language and made it elitest.
I don't understand this use of that term.
I don't either, but I think what he means is that only a handful of
experienced implementors will understand how a full Scheme system is
implemented.
I wanted all of my students to be able to implement "Scheme" when
they walked out of my course, now that is no longer possible.
This is false. Internal defines are not essential. If by "Scheme" you
mean absolutely everything described in the report, I would expect that
internal definitions (which can be implemented with a very small amount
of code) would be the least of any implementor's worries. What about
number I/O?
Dan was referring, I'm sure, to the core of the language, which he
feels must now not only include lambda, set!, quote, if, identifiers,
and applications but also begin and define, not to mention the added
complexity of lambda.
It was a great beauty of
Scheme that the four mentioned special forms along with identifiers and
application were the only syntax. It was wonderful that a CPS interpreter
for Scheme was all that was necessary to come to grips with in order to
understand the run-time architecture of Scheme.
Why isn't this still true?
My argument with internal-define is not that it is good or bad, but
that the subtlety of its definition is unnecessary with judicious use
of letrec and letrec should be a trivial macro. What happened?
How do internal definitions make LETREC more complicated? The (LET ()
...) (which would otherwise be a (BEGIN ...)) is trivial compared to
the rest of what LETREC has to do, and doesn't even have to be there at
all if you're not implementing the full language.
I think you misunderstood his point completely here. He was merely
wondering of what use internal define is if you have letrec, and noted
that you can get letrec trivially with lambda and set!, if you like.
I have never liked internal defines.
Thanks for telling me, I hadn't figured this out.
I thought they were harmless
until I saw what havoc they introduced to the Report. I am trying
desperately to convince everyone that we made a mistake and we should
do everything in our power before we go public on this Report to
wait until we impose internal defines on everyone.
I'll do what I can to fix the presentation; I can at least certainly
make internal definitions less intrusive than they were in the RRRS.
I hope that will be sufficient. Personally, I wouldn't mind removing
internal definitions from the language, although special treatment of
definitions at top level of a file (which is another story altogether)
must stay.
I agree in principle with this idea. It makes sense that define at
top level should be treated specially, and nested definitions such as
those given throughout S&ICP are quite handy and encourage modularity
in a nice way. Since this treatment would not affect lambda or let,
it would be easy to understand and easy to implement. I would agree
to using something totally different for definitions or perhaps use
the define/set! combinations for our interpretation of internal define
if we all agreed that define were only to be used at top level, with
the nested syntax. I would even agree to making top-level, nested
define a required feature, and to requiring that define not be used
anywhere else.
If you can convince everyone, including Sussman and Abelson,
that internal definitions should be flushed, then I'll flush them. If
you must persue this, I suggest you talk to Sussman on the telephone
about this; he isn't reachable by electronic mail until June 20, I
think. I'll try to find his phone number at Princeton or HP or wherever
he is.
Why does this question arise at this moment? I am angered by the
untimeliness of this debate. Why didn't it come up when the idea of
printing the report in SIGPLAN was first mentioned? This part of the
language hasn't changed.
We are all very sorry for the lateness of the debate, but it has
taken time to absorb everything (and we have brought it up before
publicly and privately, perhaps not as loudly). None of us had used
a system with the internal definitions until after the RRRS (not R3S)
came out, so we must plead a certain amount of ignorance in earlier
discussions. On the other hand, it is more important on the eve of
SIGPLAN publication than at any previous time, since that will be the
first wide distribution of a Scheme report, and we must come together
on this issue. We have an exceptionally tight community of people
working on/with Scheme and it is not good for us to put each other at
odds by publishing a feature that some of us strongly dislike in its
current form. We ask your forgiveness and patience; please realize
that we understand and very much appreciate all of your time and
effort that has gone gone into this report.
Jonathan
Kent
∂02-Jun-86 0730 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Another Can of Worms?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 07:30:04 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86 10:28:49 EDT
Date: 2 Jun 1986 10:28-EDT
Sender: JMILLER@MIT-OZ
Subject: Another Can of Worms?
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MIT-MC
To: rrrs-authors@MC
Message-ID: <[MIT-OZ] 2-Jun-86 10:28:16.JMILLER>
I've withheld this one for a long time on the theory that new
problems with the language should be discussed AFTER the imminent
publication of the standard. Since we appear to have stalled
that yet again, I'd like to mention it.
I am very concerned about the fact that the document we are
promulgating as a language standard permits of no way to write
truly portable code. This arises from the lack of a convention
which would permit me to choose the names of variables which will
guarantee me that no implementation has used those names as
special forms. I know of two solutions: (a) a gentleman's
agreement to the effect that every implementation will support
some well-publicized mechanism for absorbing foreign portable
code (in MIT Scheme, for example, we could provide a portable
syntax table for this purpose); or (b) as in BCPL, make a formal
statement as part of the language design that certain names will
never be used as the names of built-in special forms.
I am in favor of option (b) since it prevents the current
implementors from becoming a select small clique which has more
knowledge than outsiders. One such proposal would be that we
insert a statement somewhere to the effect that "No
implementation shall supply by default a special form with ":" in
its name". Thus portable code uses variables with ":" in them
somewhere and all is well. [FYI, the BCPL statement was that
reserved words were all lower-case and more than one letter
long.]
-- Jim Miller
∂02-Jun-86 1558 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU sentiments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 15:58:26 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86 18:56:44 EDT
Date: Mon, 2 Jun 86 18:41:25 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: sentiments
To: dyb%indiana.csnet@CSNET-RELAY.ARPA
cc: dfried%indiana.csnet@CSNET-RELAY.ARPA,
rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 1 Jun 86 16:21:30 est from Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].923886.860602.JAR>
Date: Sun, 1 Jun 86 16:21:30 est
From: Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>
That begin must be a core special form results from the fact that in
the report, (begin (define ...) ...) must not open up a new scope;
i.e., (begin x y ...) must not be defined as ((lambda () x y ...)),
or the more traditional form ((lambda (t) (begin y ...)) x) where t
does not appear free in (begin y ...). I think of this as the "usual
expansion".
I get the feeling you haven't read the report. According to NEITHER
Will's RRRS, NOR the draft I sent out, is (begin (define ...) ...) a
syntactically valid expression! Look again at the BNF and at the text.
The usual expansion ((lambda (t) (begin y ...)) x) works perfectly well
since <expression> can't produce anything of the form (define ...),
<definition>s can only occur in <program>'s and <body>'s, and the syntax
of <sequence>s is (begin <expression>+), not (begin <body>). The RRRS
says that definitions are expressions, which isn't exactly wrong, but it
seemed a little misleading to me, since they aren't legitimate in all
places where expressions are supposed to be. (Again, only the details
of the description have changed, not the language described!)
Maybe you're misled by the statement in the RRRS that "(lambda (var1 ...)
expr1 expr2 ...) is equivalent to (lambda (var1 ...) (begin expr1 expr2
...))". This can be seen to be technically true if either (a) you take
this statement to be only about the essential subset or (b) definitions
aren't expressions (so that the statement wouldn't apply in the case of
(begin (define ...) ...)).
The BNF in the draft makes the error of classifying (begin ...) as
primitive instead of derived. This is an error. (At one point I too
was confused and thought that begin had to be primitive, but Sussman
straightened me out). Sorry if this bug confused you. I will fix it.
I wouldn't brag about this! Having already expanded Scheme from
expressions and functions to statements and procedures, we are now
adding declarations. What happened to simplicity?
"Now"? The fact that definitions weren't valid in copntexts other than
top level and the beginnings of "bodies" was agreed on Brandeis and
hasn't been challenged until now.
Introducing the term "statement" to mean an expression whose value is
thrown away seems harmless to me; I was inspired to do this by the
abstract syntax that Will sent me for the denotational semantics (which
sets Com = Exp). Using "<statement>* <expression>" instead of
"<expression>+" also gives a rationale for requiring at least one
expression in LAMBDA, BEGIN, etc. If there's general sentiment that
this is a bad idea, I'll flush it, but I thought it was reasonable.
We all know why we use "procedure" instead of "function". I don't
understand how this makes the language more complex.
Your question about simplicity is pure propaganda, so I won't answer it
beyond the above remarks.
As has been explained innumerable times, there is no way to avoid this
and have a language which is at all coherent with T and MIT Scheme.
Note that in all programming languages of the Algol/Pascal/C variety it
is an error to assign to an undeclared variable. That MIT Scheme and T
(and thus RRRS Scheme) also have this property is not coincidence.
Algol, Pascal, and C are not (typically) interactive languages, nor
do they have such nice features as first-class functions that allow
one to form modules of functions sharing local state/help functions.
I think that it would be possible in any system to have a notion of
a "top-level" lexical environment which implicitly contains bindings
for all things not bound elsewhere. This could be a per-user or
per-module thing; it need not be the outermost lexical environment.
I repeat: "there is no way to avoid [requiring that variables be bound
before they're assigned] and have a language which is at all coherent
with T and MIT Scheme." I never said it would be impossible to
implement. And interactiveness has nothing to do with it.
... I don't either, but I think what he means is that only a handful of
experienced implementors will understand how a full Scheme system is
implemented.
... Dan was referring, I'm sure, to the core of the language, which he
feels must now not only include lambda, set!, quote, if, identifiers,
and applications but also begin and define, not to mention the added
complexity of lambda.
Do I need to mail out a complete evaluator in order to drive the point
home?
I think you misunderstood his point completely here. He was merely
wondering of what use internal define is if you have letrec, and noted
that you can get letrec trivially with lambda and set!, if you like.
No one ever said internal defines were linguistically necessary. They
are obviously redundant. They are there because it's very important to
be compatible with something so central to S&ICP. Like I say, talk to
Sussman and Abelson if you dispute this.
I agree in principle with this idea. It makes sense that define at
top level should be treated specially, and nested definitions such as
those given throughout S&ICP are quite handy and encourage modularity
in a nice way. Since this treatment would not affect lambda or let,
it would be easy to understand and easy to implement.
How does its not affecting lambda or let have anything to do with how
easy it is to implement? Implementing internal defines involves one
trivial loop, and it doesn't matter whether you put this loop in the
code for lambda or define, although it DOES matter if you have to invoke
it two places.
I would agree
to using something totally different for definitions or perhaps use
the define/set! combinations for our interpretation of internal define
if we all agreed that define were only to be used at top level, with
the nested syntax. I would even agree to making top-level, nested
define a required feature, and to requiring that define not be used
anywhere else.
I don't understand this paragraph at all. Note that no one has ever
wanted internal defines to be essential in any context.
... We have an exceptionally tight community of people
working on/with Scheme and it is not good for us to put each other at
odds by publishing a feature that some of us strongly dislike in its
current form.
Like I say, talk to Abelson and Sussman. I think a lot has and can be
done to make internal definitions minimally ugly and intrusive. It is
not good to confuse many innocent bystanders and put your community at
odds with MIT's by permitting an incompatible meaning for DEFINE.
Jonathan.
∂02-Jun-86 1604 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA DEFINE -- a concrete proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 16:02:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 18:57:59 EDT
Received: from tektronix by csnet-relay.csnet id an13197; 2 Jun 86 18:51 EDT
Received: by tektronix.TEK (5.31/6.14)
id AA09219; Mon, 2 Jun 86 13:19:31 PDT
Received: by tekchips (5.31/5.14)
id AA05517; Mon, 2 Jun 86 13:23:57 PDT
Message-Id: <8606022023.AA05517@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, wand%northeastern.edu@CSNET-RELAY.ARPA,
dfried%indiana.csnet@CSNET-RELAY.ARPA
Subject: DEFINE -- a concrete proposal
Date: 02 Jun 86 13:23:55 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
I propose that section 4.1.0 of the 22 May 1986 draft be clarified to
read as follows:
At the top level of a program, a definition
(define <variable> <expression>)
has essentially the same effect as the assignment expression
(set! <variable> <expression>)
if <variable> is bound. If <variable> is not bound, however,
then the definition will bind <variable> before performing
the assignment, whereas it would be an error to perform a
set! on an unbound variable.
[examples go here]
Top level definitions are essential; all Scheme implementations
must support them.
Some implementations of Scheme use an initial environment in
which all possible variables are bound to locations, most of
which contain undefined values. Top level definitions in
such an implementation are truly equivalent to assignments.
In my opinion, this is merely a clarification because the draft
does not say that the initial environment must contain only the
variables mentioned in the report, and it is in fact the case
that most implementations supply variables that don't appear
in the report. Furthermore, even if unbound variables exist,
the phrase "it would be an error" indicates that implementations
are not required to complain when one is assigned, so an
implementation is free to do something random (like bind the
variable and do an assignment) instead of signalling the error.
The phrase "Some implementations of Scheme" is the very same
neutral phrase used at the beginning of Section 4.2 on internal
definitions. Thus the report would be neutral between those
who for whatever reason want to assign variables before they
declare them and those who for whatever reason prefer the
internal definition syntax to LETREC.
Since this is only a clarification of what is already implicit
in the report, I believe this proposal should satisfy those who
prefer the status quo. I believe it should also satisfy those
who with Mitch are arguing for the following:
An implementation may have a top level (initial, whatever)
environment in which every possible identifier is bound
(though only some are initialized).
This would allow programs in that implementation to do a set!
on a global variable (excuse me, a variable in the current
top-level environment) from an internal scope without having
to explicitly bind the variable in the initial scope. It would
also allow MIT-style define to proceed, as it does not require
the existence of a distinguished global environment.
Mitch is entirely right that his proposal retains the spirit of
the Brandeis agreement on this issue. Though Jonathan said in
his reply to Mitch that he wouldn't have too much problem with
adding this clarification to the report, he insisted that it should
be "accompanied by some mention of the fact that some implementations
have principled reasons for not having this feature". I say that
stipulation is unfair -- the report doesn't contain any of the
principled arguments against internal definitions or against the
fancy DEFINE syntax or against REC or against NAMED-LAMBDA or
against NIL or against the behavior of EQ? on procedures or
against hexadecimal notation...
Dan Friedman had some very reasonable things to say about the
importance of simplicity and elegance, particularly with regard
to ease of implementation by students. My answer is that
students should implement "Essential Scheme" instead of worrying
about how to get ASIN to work with complex numbers. Essential
Scheme does not have internal definitions, and it is perfectly
all right to use an initial environment in which all variables
are bound and to implement DEFINE as assignment.
I must admit that Essential Scheme is a more elegant language than
full Scheme.
I second Bill Rozas's objections to MAKE-LOCAL-VARIABLE as a procedure
for performing incremental definitions.
Let us seek peace,
William Clinger
----------------------------------------------------------------
[Because of one mailer error, the local postmaster has suggested
that people send me mail at willc@tekchips.tek.csnet instead of
at willc%tekchips@tektronix.csnet, which had worked fine until
now. If one doesn't work, please try the other.]
∂02-Jun-86 1803 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: definitions; APPEND!; etc
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 18:03:10 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 2 Jun 86 21:02:04 EDT
Received: from ti-csl by csnet-relay.csnet id a014023; 2 Jun 86 20:52 EDT
Received: by tilde id AA20278; Mon, 2 Jun 86 19:00:17 cdt
Date: Mon 2 Jun 86 18:46:15-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: definitions; APPEND!; etc
To: willc%tekchips.tek@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: jar%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@CSNET-RELAY.ARPA,
605301901283@tekchips
MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <12211713593.48.BARTLEY@CSC60>
[Bartley:]
>>APPEND! always side-effects all but its last argument.
[Clinger:]
>No, APPEND! should not be required to perform side effects. This is not
>as silly as it may sound. In an implementation using the Hewitt-Lieberman
>gc algorithm, for example, side effects to sufficiently old structures are
>likely to be more expensive than consing. APPEND! should be free to decide
>for itself which technique is fastest.
My point of view is that APPEND! is used to ensure sharing of
structure and APPEND is used to ensure that structure is NOT shared
(except in the clearly specified case of the last argument).
>I would feel differently if APPEND! returned an unspecified value, as
>does VECTOR-SET!.
Perhaps that would be more consistent. Perhaps we should call it
SET-LAST-CDR! instead!
Seriously, I could go either way, but I'm sure some of my code would
fail to work on a system in which APPEND! did not share structure.
Are there any others we should be discusssing?
--db--
-------
∂03-Jun-86 0853 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 08:53:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 11:48:51 EDT
Received: from ti-csl by csnet-relay.csnet id ac20037; 3 Jun 86 11:38 EDT
Received: by tilde id AA02583; Tue, 3 Jun 86 11:06:15 cdt
Date: Tue, 3 Jun 86 11:06:15 cdt
From: John Maeda <maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: jkr%mit-oz@MC.LCS.MIT.EDU
okay glen I hope this gets to you; I had written you a real l ong letter but
I have no idea how to save it from this version of EMACS running on this uLTRIX
machine ... (must be a ti-professional playing "multi-user") ... so I'm really
ticked, I just hope this gets to you.
jtm
∂03-Jun-86 0953 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU APPEND!
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 09:53:47 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 12:52:26 EDT
Date: Tue, 3 Jun 86 12:37:27 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: APPEND!
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 2 Jun 86 18:46:15-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].924078.860603.JAR>
Maybe we should just flush APPEND! altogether? It's easy enough to do
(SET-CDR! (LAST-PAIR list1) list2). I think Sussman was the one who
really wanted APPEND! in the language, but I forget why.
Jonathan
∂03-Jun-86 1010 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 10:09:43 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 13:08:08 EDT
Date: Tue, 3 Jun 86 13:08:20 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: portability
To: RRRS-AUTHORS@MX.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].924086.860603.JAR>
The following is in response to Jim Miller's message about portability,
which raises an important question I've been hoping to repress. But Freud
tells us that the repressed always returns.
- Jonathan
Date: Sat, 31 May 86 21:32:00 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
To: GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU
cc: JAR at MX.LCS.MIT.EDU
Re: revised↑n report
In-reply-to: Msg of Sat 31 May 86 13:16:32 EDT from George J. Carrette <GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].923398.860531.JAR>
Date: Sat, 31 May 86 13:16:32 EDT
From: George J. Carrette <GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
To: JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU
One should be able to show that clever underspecification in
a language spec is eventually a losing proposition. Example:
in CL (make-array 3) => #(0 0 0) (e.g. in VAX-NIL) or #(NIL NIL NIL)
in at least the LISPM environments I'm aware of. The idea
is to make the guy say (make-array <x> :initial-element <value>) if
he is depending on the initial value. Supposed to be a big efficiency
win. (now, I've just spent a few hours tracking down a bug in the
DOE-MACSYMA plot package that had to do with the initial element of
an array screw). A few days ago you had a note to the CL list about
a similar underspecification screw in defstruct.
Well, revised↑n has its share of clever underspecification too.
But, is this really a win in a language spec? Or is it just a way
of showing (forcing down everybodies neck...) how much the
language designers know about different implementation tricks?
You dont see this kind of stuff in other language specs.
Back to the array example. Is it reasonable to argue that in lisp
there are good natural default values? The empty list as default
for an array? I think it is. On the other hand, if you know that
there might be machine dependancies in these defaults, (in fact it
is usually operating system dependancies. VMS goes to some trouble to
make sure pages allocated to users are filled with zero's)
then why not have:
(make-array 10 :initial-element *:system-prefered-initial-array-element).
I argue that clever underspecifications for the purpose of elicidating
implementation tricks know by the language designers causes:
* "dating" of the language.
* frustration for users of the language
* eventual lack of portability.
This is all too true. I think that if I were designing another language
now I would try to get rid of all underspecifications, since they lead
to so much confusion. I hope that as many underspecifications as
possible will disappear from Common Lisp.
Let me try to figure out why I think it's OK for Scheme to be
underspecified and not for Common Lisp to be underspecified. Scheme's
underspecifications don't generally have anything to do with
"implemetation tricks." Political expediency demands that the report
leave a lot of room for local variation. We wouldn't be able to get
agreement on all these little things. Some differences between versions
result from differing implementation demands, but mostly it's that the
different groups have incompatible ideologies, so each group would have
its own idea of what the "right" thing is for each situation.
The goals of Revised↑n Scheme differ from those of Common Lisp, I think.
Mostly we want to be able to read each others' code when it appears in
the literature, and relieve people from the pain of there being
incompatible languages all calling themselves "scheme". Portability is
only a secondary consideration, and we're not so concerned that all
non-erroneous programs should port, only that "well-written" programs
should port. I think there's the feeling that people who write in
Scheme don't just play around until their code just happens to work
(often the only programming technique available in some systems which
will remain nameless) -- they actually write "clean" code which observes
data abstractions and doesn't depend on things it shouldn't depend on
(like the initial value of vector components). So while it's very easy
to write unportable code, people who do so have somehow missed the
point, and probably ought to be programming in CLU or Ada (or the
language I have yet to design?) instead.
If we really want to aim for airtight portability then we've got to start
making a lot of changes.
Jonathan.
∂03-Jun-86 1124 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 11:23:18 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 14:20:34 EDT
Received: from northeastern by csnet-relay.csnet id a000357; 3 Jun 86 14:19 EDT
Date: Tue, 3 Jun 86 11:29 EST
From: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: define
1. I think the discussion has clarified, at least for me, the difference
between "internal" and "incremental" define. I was certainly thinking about
"incremental" define, which happens conceptually at run-time. As I gather it,
the idea is that internal define is JUST SYNTAX, which might be formalized as
something like
(define-equivalent-syntax ;; hypothetical pseudocode!
(<context-for-internal-define>
(define name1 body1) ...
<body>)
(letrec
((name1 body1) ...)
<body>))
The only place where "internal" define acts truly incrementally is at the top
level.
If this is correct, then my objections are considerably lessened. The major
complication of internal define, then, is sorting out in exactly which
contexts this syntax is permissable. This is a matter on which I think there
can be reasoned debate.
2. Will's proposal looks OK to me.
3. (make-local-variable 'foo) was a joke. No one seemed to get it. Sorry
'bout that.
4. Thanks to jinx and to jar for their thoughtful replies. In particular
thanks to jar (I think) for extracting the historical record. I say "jar (I
think)" because I've managed to lose my copy ($%↑&! VMS mailer); could someone
retransmit it? Tnx.
Mitch
∂03-Jun-86 1441 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA SCOOPS source
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 14:41:37 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 17:33:42 EDT
Received: from ti-csl by csnet-relay.csnet id ac02031; 3 Jun 86 17:24 EDT
Received: by tilde id AA11964; Tue, 3 Jun 86 16:45:17 cdt
Date: Tue 3 Jun 86 15:32:49-CDT
From: Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: SCOOPS source
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12211940524.20.ASRIVASTAVA@CSC60>
SCOOPS source is available now. It can be obtained by doing anonymous
ftp at host BBNA to the directory PS:<TICSL.RELSCOOPS> .
Initially, ftp the file README.SCM . It contains list of the
files needed and other information. The sources have been modified
and are totally in TI Scheme.
- amitabh
-------
∂03-Jun-86 1554 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Is BEGIN primitive?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 15:54:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 3 Jun 86 18:50:57 EDT
Received: from tektronix by csnet-relay.csnet id ai02667; 3 Jun 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.14)
id AA00979; Tue, 3 Jun 86 10:00:01 PDT
Received: by tekchips (5.31/5.14)
id AA14582; Tue, 3 Jun 86 10:04:26 PDT
Message-Id: <8606031704.AA14582@tekchips>
To: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, dyb%indiana.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Is BEGIN primitive?
Date: 03 Jun 86 10:04:25 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Whether you think BEGIN must be a primitive expression depends on your
cultural heritage. If you have grown up believing that syntax is fully
checked before macro expansion, then (BEGIN X Y ...) ==>
((LAMBDA () X Y ...)) works fine. If you have grown up believing that
macros do the least amount of syntax checking they can get away with
(or less), then (BEGIN (DEFINE ...) ...) ==> ((LAMBDA () (DEFINE ...) ...))
does not detect the syntax error.
I like the term "derived expression" because it expresses the fact that
the semantics of BEGIN can be expressed in terms of primitive expressions
without implying that a macro mechanism is used.
Though the word "statement" ought to signify a declarative assertion,
the American programming language community long ago corrupted it to
signify a command. I prefer the English "command", but I prefer even
"statement" to the phrase "expression evaluated solely for effect".
Peace, Will
∂03-Jun-86 2023 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU ftp-able r3rs.dvi
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 20:22:59 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 23:22:06 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 2325; Tue 3-Jun-86 23:22:23-EDT
Date: Tue, 3 Jun 86 23:21 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: ftp-able r3rs.dvi
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860603232145.2.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
I put the DVI file for the report on host MIT-PREP. The filename
is
/u/jar/r3rs.dvi
- Jonathan
∂04-Jun-86 0554 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86 05:53:58 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 JUN 86 08:52:11 EDT
Date: 4 Jun 1986 08:51-EDT
Sender: JMILLER@MIT-OZ
Subject: Re: portability
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 4-Jun-86 08:51:16.JMILLER>
In-Reply-To: <[MX.LCS.MIT.EDU].924086.860603.JAR>
Well, I agree in principle with all that was said. But I think
you have missed one important point: it is not possible, even
with all the care in the world, to write portable code in the
current design. I don't want to contort the language design in
any way (and neither of my suggestions do that) but I DO want
some statement which makes the possibility of portable code
feasible.
I urge you to think, again, about including some formal and
mutually agreeable statement which limits the implementors choice
of names for special forms. I believe that this is the sole
requirement necessary to permit a person intent on writing a
totally portable program to succeed.
--Jim
∂04-Jun-86 1049 @MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA Re: SCOOPS source
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86 10:49:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Jun 86 13:44:00 EDT
Received: from ti-csl by csnet-relay.csnet id ac10705; 4 Jun 86 13:37 EDT
Received: by tilde id AA07924; Wed, 4 Jun 86 11:55:29 cdt
Date: Wed 4 Jun 86 11:47:42-CDT
From: Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: SCOOPS source
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <12211940524.20.ASRIVASTAVA@CSC60>
Message-Id: <12212161685.28.ASRIVASTAVA@CSC60>
I am sorry - our systems people blew it. BBNA does not allow
user anonymous. The sources are available on host UTEXAS-20
in the directory ps:<g.ti.scoops> . Use anonymous ftp to get the
sources.
Initially, ftp the file README.SCM . It contains list of the
files needed and other information. The sources have been modified
and are totally in TI Scheme.
Again, my apologies for this confusion.
- amitabh
-------
∂04-Jun-86 1623 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86 16:23:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Jun 86 19:23:00 EDT
Received: from tektronix by csnet-relay.csnet id ae02282; 4 Jun 86 18:58 EDT
Received: by tektronix.TEK (5.31/6.14)
id AA25894; Wed, 4 Jun 86 09:46:37 PDT
Received: by tekchips (5.31/5.14)
id AA28499; Wed, 4 Jun 86 09:51:05 PDT
Message-Id: <8606041651.AA28499@tekchips>
To: JMiller%OZ@MC.LCS.MIT.EDU
Cc: RRRS-Authors@MC.LCS.MIT.EDU
Subject: Re: portability
In-Reply-To: Your message of 4 Jun 1986 08:51-EDT.
<[MIT-OZ] 4-Jun-86 08:51:16.JMILLER>
Date: 04 Jun 86 09:51:03 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Jim Miller writes:
>I urge you to think, again, about including some formal and
>mutually agreeable statement which limits the implementors choice
>of names for special forms. I believe that this is the sole
>requirement necessary to permit a person intent on writing a
>totally portable program to succeed.
Suppose every implementation of Scheme were required to supply a
"vanilla" mode in which all reserved words are among those that
appear in the report?
Peace, Will
∂05-Jun-86 0546 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86 05:46:24 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86 08:43:44 EDT
Date: 5 Jun 1986 08:42-EDT
Sender: JMILLER@MIT-OZ
Subject: Re: portability
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 5-Jun-86 08:42:33.JMILLER>
In-Reply-To: <8606041651.AA28499@tekchips>
I'd be happy with Will's suggestion, and it does make the writing
of portable code considerably easier than my suggestion. I'm
only concerned that this may require unanimous consent. I
believe that the MIT system already includes the necessary hooks
(we would supply an RRRS-Essential syntax table).
--Jim
∂05-Jun-86 0935 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Will's proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86 09:34:51 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Jun 86 12:34:17 EDT
Received: from indiana by csnet-relay.csnet id a007465; 5 Jun 86 12:21 EDT
Date: Wed, 4 Jun 86 23:44:17 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Will's proposal
We are satisfied with Will's proposal re "set!".
Dan
∂05-Jun-86 0939 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA named-lambda and rec
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86 09:39:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Jun 86 12:34:21 EDT
Received: from indiana by csnet-relay.csnet id aa07465; 5 Jun 86 12:21 EDT
Date: Wed, 4 Jun 86 23:47:27 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: named-lambda and rec
Jinx recently suggested that he could live without either.
I second jinx's suggestion.
Dan
∂05-Jun-86 1055 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU named-lambda and rec
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86 10:55:38 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86 13:54:39 EDT
Date: Thu, 5 Jun 86 13:54:25 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: named-lambda and rec
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 4 Jun 86 23:47:27 est from Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].52205.860605.CPH>
Date: Wed, 4 Jun 86 23:47:27 est
From: Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
Jinx recently suggested that he could live without either.
I second jinx's suggestion.
I `third' it.
∂06-Jun-86 0800 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86 08:00:02 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86 10:59:40 EDT
Date: Fri, 6 Jun 86 10:59:26 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: portability
To: JMiller@OZ.AI.MIT.EDU
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 5 Jun 1986 08:42-EDT from JMILLER at MIT-OZ
Message-ID: <[MX.LCS.MIT.EDU].924918.860606.JAR>
I would say that a strict reading of the new draft, and perhaps even of
the RRRS, would say that ANY identifier other than those explicitly
listed as syntactic keywords (reserved words) may be used as a variable.
In other words, a correct implementation of the report would already
have the property that there are no other special forms other than the
ones explicitly listed in the report (the complete list is somewhere
inside the BNF). So that a program which does (define trace ...) or
(let ((loop ...)) ... (loop ...) ...) would already be portable. The
addition of ANY special form is an incompatible change to Scheme.
[Actually, if in a particular implementation special-form-ness is
cancelled out by DEFINE and lambda-binding, then it would probably be OK
in that implementation to have extra special forms/macros lying around,
since a program which used those identifiers for variables would still
be correct. But let's not think about this possibility.]
I wouldn't say that all implementations would have to start up with the
stripped-down syntax, omitting all their favorite features, but I think
that supplying a mode in which this was the case, rather than saying
only a certain class of identifiers can be used as variables, is the
right thing.
Would any implementors have any problem providing a report-syntax-only
mode? I know this is trivial in MIT Scheme and T, but we haven't heard
from other implementors.
If there are problems, then one way to cope would be to add to the
report's list of syntactic keywords some or all of the things which such
implementations would like to have be special forms, e.g. define-macro,
trace, make-environment, etc., simply saying that these are reserved for
use by particular implementations as syntactic keywords, but have no
meaning according to the report. This is sort of the dual of Jim's
original suggestion. It's pretty gross, but I thought I'd mention it.
How should this situation be explained in the report, if at all?
Jonathan
∂06-Jun-86 0806 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA add1 and sub1
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86 08:06:06 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jun 86 11:05:34 EDT
Received: from indiana by csnet-relay.csnet id aa00907; 6 Jun 86 11:04 EDT
Date: Fri, 6 Jun 86 09:57:13 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: add1 and sub1
When describing arithmetic I find the symbols "1+" and
"-1+" very harmful. The function + is denoted by the
symbol "+" and this confuses people who are trying to
understand the primitive recursive definition of +.
Purely for pedagogical reasons I would like to see "add1"
and "sub1" be optional. I know that macscheme & PC-Scheme
have included them. I don't like multiple names for the
same construct, but we have a few instances already in the
report.
Dan
∂06-Jun-86 1039 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU add1 and sub1
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86 10:39:37 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86 13:38:58 EDT
Date: Fri, 6 Jun 86 13:38:45 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: add1 and sub1
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 6 Jun 86 09:57:13 est from Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].52665.860606.CPH>
Date: Fri, 6 Jun 86 09:57:13 est
From: Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
When describing arithmetic I find the symbols "1+" and
"-1+" very harmful.
Purely for pedagogical reasons I would like to see "add1"
and "sub1" be optional.
Another alternative might be to make `1+' and `-1+' optional, since
they aren't necessary in any sense. Then there would be no need to
describe them to students at all.
In fact, there's no need to teach them even if they are essential.
∂06-Jun-86 2038 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86 20:38:22 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Jun 86 16:25:39 EDT
Received: from ti-csl by csnet-relay.csnet id ad03178; 6 Jun 86 16:24 EDT
Received: by tilde id AA18136; Fri, 6 Jun 86 14:06:53 cdt
Date: Fri 6 Jun 86 13:55:31-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: portability
To: JAR%MX.LCS.MIT.EDU%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
JMiller%oz.ai.mit.edu@CSNET-RELAY.ARPA
Cc: RRRS-Authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@a
In-Repl <[MX.LCS.MIT.EDU].924918.860606.JAR>
Message-ID: <12212709243.41.BARTLEY@CSC60>
From JAR:
>I would say that a strict reading of the new draft, and perhaps even of
>the RRRS, would say that ANY identifier other than those explicitly
>listed as syntactic keywords (reserved words) may be used as a variable.
>In other words, a correct implementation of the report would already
>have the property that there are no other special forms other than the
>ones explicitly listed in the report (the complete list is somewhere
>inside the BNF). So that a program which does (define trace ...) or
>(let ((loop ...)) ... (loop ...) ...) would already be portable. The
>addition of ANY special form is an incompatible change to Scheme.
Several implementations, including Chez Scheme, PC Scheme, and
Scheme-84, allow user-specified syntactic extensions. I doubt if we
could get a consensus that this is to be disallowed. When you (JAR)
speak of special forms, are you including macros and the like?
>[Actually, if in a particular implementation special-form-ness is
>cancelled out by DEFINE and lambda-binding, then it would probably be OK
>in that implementation to have extra special forms/macros lying around,
>since a program which used those identifiers for variables would still
>be correct. But let's not think about this possibility.]
Is there an alternative possibility?
(This paragraph seems to say that you are speaking of macros as well
as special forms.)
Regards,
David Bartley
-------
∂07-Jun-86 1658 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA macros.
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86 16:58:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 19:49:27 EDT
Received: from indiana by csnet-relay.csnet id a005487; 7 Jun 86 19:00 EDT
Date: Sat, 7 Jun 86 15:25:24 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: macros.
Our programming relies heavily on the safe use of macros.
No one here would be willing to remove the option of having
them in the language.
Dan
∂07-Jun-86 1820 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: named-lambda and rec
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86 18:19:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 21:18:13 EDT
Received: from tektronix by csnet-relay.csnet id ad00288; 7 Jun 86 1:47 EDT
Received: by tektronix.TEK (5.31/6.14)
id AA19278; Fri, 6 Jun 86 09:06:33 PDT
Received: by tekchips (5.31/5.14)
id AA26553; Fri, 6 Jun 86 09:11:02 PDT
Date: Fri, 6 Jun 86 09:11:02 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8606061611.AA26553@tekchips>
Subject: Re: named-lambda and rec
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dan Friedman <dfried%indiana.csnet@csnet-relay.arpa>, Wed, 4 Jun 86 23:47:27 est
I too would prefer to see both NAMED-LAMBDA and REC removed.
-Norman
-------
∂07-Jun-86 1829 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: add1 and sub1
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86 18:29:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jun 86 21:19:58 EDT
Received: from indiana by csnet-relay.csnet id a003864; 7 Jun 86 13:46 EDT
Date: Fri, 6 Jun 86 15:43:12 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: add1 and sub1
Another alternative might be to make `1+' and `-1+' optional, since
they aren't necessary in any sense. Then there would be no need to
describe them to students at all.
These are already innessential, in both RRRS and the draft RRRRS.
Chez Scheme will support add1 and sub1 for Dan (and the Little LISPer),
but I don't care if they appear in the report or not. I will also support
1- as an alternative for -1+; if ever there was a gratuitous difference
from Common Lisp, -1+ is it. Actually, I'd prefer flushing 1+ and -1+
from the report, but it doesn't seem worth worrying about.
∂08-Jun-86 1652 @MC.LCS.MIT.EDU:Swenson.Multics@MIT-MULTICS.ARPA Re: SCOOPS source
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jun 86 16:52:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Jun 86 19:47:59 EDT
Received: from mit-multics.arpa by CSNET-RELAY.ARPA id a006158;
8 Jun 86 19:45 EDT
Acknowledge-To: "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Date: Sun, 8 Jun 86 19:35 EDT
From: "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Subject: Re: SCOOPS source
To: Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To: Message of 3 Jun 86 16:32 EDT from "Amitabh Srivastava"
Message-ID: <860608233557.811290@MIT-MULTICS.ARPA>
Are you certain BBNA supports anonymous FTP? I repeatedly get rejected
when attempting to "login anonymous" with an error indicating that there
is no such user as "anonymous."
∂09-Jun-86 1643 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Jun 86 16:43:34 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86 19:43:14 EDT
Date: Mon, 9 Jun 86 19:27:34 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: portability
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-AUTHORS@MX.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].925333.860609.JAR>
OK, my message seems to have confused a lot of people. I'll try to be
clearer. For the purposes of this message I'll only consider
system-supplied special form types, not user-supplied ones, although the
problems are I think the same.
Jim Miller said originally that he didn't see any way to write portable
programs which used variables, because implementations were free to
preempt arbitrary variable names for use as syntactic keywords. I just
wanted to reply that on the contrary, the report is clear on what the
set of allowable variable names is. The BNF describes a <variable> as
being any <identifier> which isn't a <syntactic keyword>, and the
<syntactic keywords> are enumerated. E.g. according to my reading of
the report, the sequence
(define block (lambda (x) (extend x 3)))
(define extend (lambda (a b) (list b a)))
(block 1)
has a perfectly well-defined meaning: BLOCK and EXTEND are variable
names (unconditionally!); these names become bound to values; the value
of BLOCK is applied to the number 1; etc. I didn't see anything in the
report which allowed any implementation to assign any other meaning to
this program fragment. Any implementation which did something different
with this code fragment (e.g., T, which has BLOCK-expressions, and
independent namespaces for variables and keywords) would not be
implementing the language described in the report.
I don't think this is a departure from the previous report, although of
course my edits have made the *description* follow my world view more
closely.
The way so-called "syntactic extensions" usually (not always) work,
however, is that they pre-empt certain identifiers for use as variable
names. E.g. an implementation might make BLOCK or EXTEND unavailable.
Or, worse, the variables remain available, but expressions whose cars
are these names are no longer treated as procedure calls. Then the
above program wouldn't have the expected meaning. I say that such
modifications to the language aren't syntactic extensions, since they
incompatibly change the meanings of programs, rather than just defining
what would otherwise be an error situation.
If the implementation is clever enough that program fragments like these
still work, i.e. the extensions are only seen when the variable is
undefined (a situation which would otherwise be an error), then that's
fine, but I don't think that's how most scheme implementations out there
actually implement their additional special form types. (Correct me if
I'm wrong. Consider forward references.)
Implementations can support macros (they can also support Algol 60 mode,
or any other incompatible change, if they want -- it's not as if it's a
sin to program in something other than reportified-scheme), so long as
there's some way to run programs written in the language described in
the report. Several existing implementations are already structured to
make it easy to support multiple such modes or incompatible dialects; so
what's the big deal?
In short: why should the report say anything at all about this issue?
To warn implementors not to do the wrong thing?
Do we want to change the report to explicitly ALLOW the preemption of
arbitrary variable names? I think Jim's question originated from a
belief that implementations were free to do this and still claim to be
adhering to the report. I think that's absurd. How should the report's
examples, much less portable programs in general, be written in that
case?
Jonathan
∂10-Jun-86 0744 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jun 86 07:44:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jun 86 10:40:50 EDT
Received: from indiana by csnet-relay.csnet id a005144; 10 Jun 86 10:36 EDT
Date: Tue, 10 Jun 86 01:43:10 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU
Subject: Re: portability
Cc: rrrs-authors@MC.LCS.MIT.EDU
I don't think this issue is as cut and dried as all that. Jonathan
is right on the one hand; it is ``absurd'' to write portable programs
if any identifier might be taken away by a particular implementation.
However, it is not clear to me what the most practical solution is
at this point for systems that have additional special forms or user-
defined macros. It is certainly not practical to stay away from all
special forms but those appearing in the report. Nor is it practical
to invalidate a macro when a binding is found; as Jonathan points
out, forward references become a problem. Perhaps it is practical to
complain when a binding is found; this does not allow portable code
but it does provide some level of sanity. And I'm not sure it is
practical to have a "vanilla" mode; although the issue is worthy of
consideration, what happens when someone wants a basically portable
piece of code to use a system-specific special form?
If I had to take a stand one way or another, I would probably favor
a more liberal definition of keyword---rather than saying that all
of the keywords are enumerated in the report, I would allow for the
inclusion of additional keywords by any particular implementation,
with the requirement that any implementation must provide a warning
when a keyword is used as a variable. Writing portable code would
be an iterative process, but it would be relatively painless.
But I don't really want to take a stand at this point. I would
rather leave this topic, along with the whole topic of macros, out of
the report. That way we could experiment with various ways of doing
things and at some point agree on the most practical way of dealing
with the situation.
(I was going to suggest that we require keywords to begin with an
upper-case letter so that portable code could be written by employing
only lower-case variable names, but I remembered that Scheme is case-
insensitive. Sigh...)
Kent
∂11-Jun-86 1021 @MC.LCS.MIT.EDU:TIM%upenn.csnet@CSNET-RELAY.ARPA Scheme for AI based CAI
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jun 86 10:21:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 11 Jun 86 13:16:10 EDT
Received: from [1100455600] by CSNET-RELAY.ARPA id ac01092; 11 Jun 86 13:05 EDT
From: Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Subject: Scheme for AI based CAI
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Date: Wed, 11 Jun 86 12:59 EDT
What follows is a msg from Mark Richer via the AIED digest concerning the
use of Scheme for building AI based educational systems. I've included my
response. Others may have relevant thoughts to share with him.
Tim
--------------------------------------------------------------------------
From: Mark Richer <RICHER@SUMEX-AIM.ARPA> on Wed 11 Jun 1986 at 12:00
To: ai-ed-outgoing@SUMEX-AIM.ARPA
Subj: 1:8 Scheme; AI-ED questionnaire
AI-ED Digest Tuesday, 10 June 1986 Volume 1 : Issue 8
Today's Topics: Scheme, anyone?
AI and Education questionnaire
Date: Tue 10 Jun 86 08:29:38-PDT
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Scheme, anyone?
I have been asked to give advice regarding the appropriateness of using
Scheme for a development effort in Intelligent Computer Assisted Instruction.
Although this is partly a research effort also, a clear goal is testing
and installing the software in high school classrooms. The hardware available
to this project is HP workstations.
Admittedly I know little about Scheme. However, my initial reaction is that
no advantages Scheme could provide over CommonLisp could offset the
disadvantages of using a language without a large user base for the
purposes of software development and installation. CommonLisp
promises to offer portability (of course there are still problems, e.g.,
graphics) and a large user community, and has other obvious advantages
because of the general acceptance of Lisp in the U.S. AI community.
I'd appreciate some feedback from people that are familiar with Scheme,
particularly if you have used it for developing a large AI-based system.
Can any argument be presented to justify the resources necessary to train
people in Scheme and build and maintain a system in this UnCommonLispLike
language? In other words, what is so special about Scheme compared to
CommonLisp?
Mark
... rest of digest deleted ...
-------------------------------------------------------------------------
From: Tim Finin <Tim@upenn> on Wed 11 Jun 1986 at 12:49
To: Mark Richer <RICHER@SUMEX-AIM>
Cc: Bonnie Webber <bonnie@upenn>, Ai Bulletin Board <scheme@upenn>
Subj: Scheme
Here are some thought on Scheme vs. CommonLisp. We use Common Lisp in our
research efforts (mostly) and Scheme as an instructional language. We are
using it in both our graduate and undergraduate programs in the core
software/programming languages courses.
Scheme is Lisp. More precisely, Scheme is what Lisp should be modulo some
software engineering arguments. I think that the biggest influence on the
development of Common Lisp was the success of Scheme as a language. The
differences between common Lisp and scheme, as programming languages, at
this point, are mostly surface level phenomina. Common Lisp does have a
much much bigger base of existing software, however.
Scheme will be the Pascal of the 90's. Scheme is fairly standardized. There
are a number of good implementations (CScheme, PC-Scheme, Chez Scheme,
MacScheme) and all ashere to the unofficial standard (The Revised Revised
Report on Scheme). I think it will be used in most of the good CS
undergraduate programs in a few years to teach basic concepts of
programming. Common Lisp, I believe, will not be used in this way. Thus,
you can expect to see an increasing "user base".
Scheme is simple. Scheme is inherently simpler and smaller than common lisp.
There is some truth to the equation of sheme/commonlisp = pascal/ada. I
think Scheme will be a beter deliverey vehicle for AIED systems. It will be
hard to sell these systems if they need an HP Bobcat or a Vaxstation to run
them. It will be easy to sell them if they run on a PC or a MAC.
I hope these thought are relevant. Tim.
∂11-Jun-86 1145 @MC.LCS.MIT.EDU:FAHLMAN@C.CS.CMU.EDU Scheme for AI based CAI
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jun 86 11:45:20 PDT
Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 11 Jun 86 14:40:44 EDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Jun 86 14:37:45-EDT
Date: Wed, 11 Jun 1986 14:37 EDT
Message-ID: <FAHLMAN.12214016709.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Cc: scheme@MC.LCS.MIT.EDU
Subject: Scheme for AI based CAI
I've been involved pretty deeply in the Common Lisp design effort for
several years. For what it's worth, I agree with most of what Tim Finin
said about Common Lisp vs. Scheme for education. Common Lisp has a lot
of ugly things in it that are there for compatibility with older Lisps,
for efficiency on certain machines, and for support of large systems.
There are a lot of features built into Common Lisp that increase the
conceptual load on the first-time user, but that are valuable for the
experienced user who has to do a big job in a hurry.
Scheme is smaller, cleaner, and more willing to break with some of the
bad ideas of the past. I would use Common Lisp for any really big job,
especially if it needs to be portable to a lot of machines. At some
point, if I were training students to go out into the world and design
intelligent systems, I'd make sure that they were exposed to Common
Lisp. But for teaching the fundamental principles of Computer Science,
Scheme provides equal or better support, with many fewer distracting
features and mis-features.
I think that students trained in Scheme would have no trouble learning
Common Lisp later, though it would be useful to warn them about the
separate function and value namespaces in Common Lisp before they get
too used to Scheme's way of doing things. And I'd try not to present
Scheme in such a way that the students will be too pure to deal with a
"dirty" language like Common Lisp when the time comes. Some of that
dirt is there for a reason, and the rest is the price we had to pay to
make Common Lisp a widely agreed-upon standard.
In the long run, I don't think that the need for a larger machine to run
Common Lisp will matter: the only real difference in resource needs is
that Common Lisp needs a couple of megabytes more than Scheme (either
real or virtual memory will do) to hold the full language, and that
difference tends to wash out once megabit memory chips start turning up
as the prize in Cracker Jacks. But for the next year or two, the choice
on the smallest machines will be between a full Scheme and a very
stripped down Common Lisp, and under those conditions Scheme wins.
I hope that Scheme won't become the Pascal of the 90's. I hate Pascal.
-- Scott Fahlman
∂13-Jun-86 0956 @MC.LCS.MIT.EDU:mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Revised↑3 Draft Comment
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Jun 86 09:54:35 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 13 Jun 86 12:33:09 EDT
Received: from ti-csl by csnet-relay.csnet id ao20650; 13 Jun 86 12:26 EDT
Received: by tilde id AA27555; Fri, 13 Jun 86 10:44:00 cdt
Date: Fri, 13 Jun 86 10:44:00 cdt
From: Mark Meyer <mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: RRRS-authors%mit-mc@CSNET-RELAY.ARPA
Subject: Revised↑3 Draft Comment
Cc: mmeyer%ti-csl.csnet@CSNET-RELAY.ARPA
In going over the grammar in the Revised↑3 Report for numbers in
Scheme, I noticed a possible omission. According to the production
<ureal R> --> <prefix R> <digit R>+ #* / <digit R>+ #* <suffix>
the production of rationals, 1/2e3 is legal syntax while 1e3/2 is not.
Shouldn't the production be amended to
<ureal R> -->
<prefix R> <digit R>+ #* <suffix> / <digit R>+ #* <suffix>
so that the numerator as well as the denominator may carry a suffix?
In that case, 1/2e3 would mean 1/2000 and 1e3/2 would be 1000/2 (=500).
Mark Meyer
(mmeyer@ti-csl)
∂15-Jun-86 1251 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA Logic Continuations (Abstract)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jun 86 12:51:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jun 86 15:47:20 EDT
Received: from indiana by csnet-relay.csnet id ah03896; 15 Jun 86 15:44 EDT
Date: Sun, 15 Jun 86 11:44:22 est
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
Subject: Logic Continuations (Abstract)
The following abstract of a paper, to be delivered at the Third International
Conference on Logic Programming (London, July 1986), may be of interest to the
Scheme community. The paper is also available as Indiana University Computer
Science Department Technical Report No. 183, and is to appear in The Journal
of Logic Programming in a somewhat revised from.
Logic Continuations
by Christopher Haynes
We develop a `complete' embedding of logic programming into Scheme---a
lexically scoped Lisp dialect with first-class continuations. Logic
variables are bound in the Scheme environment and the success and failure
continuations are represented as Scheme continuations. To account for the
semantics of logic variables and failure continuations, the state-space model
of control is modified in a novel way that generalizes the trail mechanism.
This assures that logic variable bindings are properly restored when
continuations are invoked to perform `lateral' control transfers that are not
possible in a traditional logic programming context. It is thereby possible
to obtain greater control over logic program behavior by using continuations
as first-class objects.
∂17-Jun-86 1621 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86 16:20:57 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jun 86 19:19:56 EDT
Received: from ti-csl by csnet-relay.csnet id ao17298; 17 Jun 86 18:51 EDT
Received: by tilde id AA27184; Tue, 17 Jun 86 17:08:11 cdt
Date: Tue 17 Jun 86 16:00:31-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Number syntax
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12215615581.31.BARTLEY@CSC60>
One irritant in the Report that we have neglected to comment on until
now (sorry!) is the syntax of numbers. We believe that Scheme numbers
are essentially equivalent to Common Lisp numbers except for the new
notion of exactness. To the extent that that is so, it seems to be a
(shudder!) ``gratuitous difference'' from Common Lisp to have an
incompatible syntax.
The R↑3RS doesn't make clear which subset of the syntax of numbers is
essential and what is optional. As implementors of systems in which
Scheme and Common Lisp must co-exist, we're faced with two potential
compatibility issues: (1) going with an ``extended subset'' of the
Report's number syntax that is compatible with Common Lisp, or (2)
going with the full number syntax in the Report to be compatible with
all other Scheme implementations.
What we'd like to see is an essential syntax for numbers which is
compatible with Common Lisp's. Additional features, including
exactness, would be optional extensions. Even so, they should not
conflict with Common Lisp. For example, the use of `#s' and the order
of <sign> and <prefix> are different in the two languages.
Our motivation, of course, is that we'd like programmers to feel free to
use either language and exchange files of data without irritating
obstacles being thrown in their path. If we can't agree on a
consistent syntax for numbers, then we'll have to provide each language
with two readers and the user will have to know which one to use.
(There are other problems, of course, such as whether `:' is a
constituent of an identifier or associated with Common Lisp package
designations. We may have to go with separate readers/modes anyway.)
Does anyone agree with us? Is there time to make such a change before
R↑3RS goes to press?
Regards,
David Bartley,
Mark Meyer
-------
∂17-Jun-86 1909 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86 19:09:05 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86 21:46:55 EDT
Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86 21:46:13 EDT
Date: Tue, 17 Jun 86 21:44:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Number syntax
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-Authors@MX.LCS.MIT.EDU
In-reply-to: Msg of Tue 17 Jun 86 16:00:31-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].58406.860617.JAR>
Date: Tue 17 Jun 86 16:00:31-CDT
From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Does anyone agree with us? Is there time to make such a change before
R↑3RS goes to press?
I agree with you, but I don't have anything at stake. If we can come to
an agreement to change, I'd be happy to make the change.
As far as time goes, I have yet to call Wexelblat again to find out the
next deadline, buI imagine it will be the first week of July (for the
September issue). I need to get a clean copy out to everyone at least,
say, 10 days before SIGPLAN's deadline, so that means we should try to
get stability by circa June 25. I'll aim for that, but of course my aim
has not been good in the past.
Jonathan
∂17-Jun-86 1912 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Policy on change-making
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86 19:10:31 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86 22:10:52 EDT
Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86 22:10:08 EDT
Date: Tue, 17 Jun 86 22:08:58 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Policy on change-making
To: rrrs-authors@MX.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].58425.860617.JAR>
A number of suggestions for incompatible changes are currently on the
floor. Before I start polling y'all about these various questions
(mostly removals), I would like to see if we can reach concensus on what
our policy should be for making such incompatible changes. I think the
policy we adopt will bear on the changes we decide we want to make.
Questions that should be answered:
- How radical ought we to be? That is, how important is compatibility with
last summer's report?
- Given that there will be incompatible changes, how should these be
indicated in the report? Should I clutter the main text with little
notes; should I make a list of all the changes; if I make such a list,
where should it appear --- in the "notes" section, in the introduction,
somplace else? Should the list include rationales
I guess my current bias is either to omit the list entirely or relegate
it to the notes section, in pursuit of a "crisper" [Dan Friedman's word]
document. However, I again have nothing at stake, and don't care too
much, so people with real implementations should speak up.
Changes and removals (as opposed to clarifications or extensions) so far
agreed upon include the omission of the "object table" chapter, the
omission of all the #!foo constants, and the change in meaning of
(define (foo ...) ...) [from using named-lambda to using lambda]. We
have already decided on some others, and may decide on others still, in
the coming weeks.
What other documents do: The Revised Report on Scheme has pretty
thorough notes about how the language changed, with complete rationales.
The revised Algol 60 report merely enumerates, in a footnote, the
section numbers of sections that were changed at the 1962 conference.
The Algol 68 report has a comparison with Algol 60 (3 pages) as part of
its introduction, and the Revised Algol 68 report also has a comparison
with the non-revised Algol 68 report (4 pages).
Jonathan
∂18-Jun-86 2144 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: Number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jun 86 21:44:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Jun 86 00:44:37 EDT
Received: from indiana by csnet-relay.csnet id ac01244; 19 Jun 86 0:38 EDT
Date: Wed, 18 Jun 86 17:53:13 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU
Subject: Re: Number syntax
Cc: rrrs-authors@MC.LCS.MIT.EDU
I'm all for the modifications David and Mark suggest...the same issues
have been annoying me, although I have no stake in Common Lisp. I
suggest that David send out another letter with the wording/syntax he
wants to make things easier for Jonathan.
∂20-Jun-86 0202 @MC.LCS.MIT.EDU:JINX@OZ.AI.MIT.EDU Policy on change-making
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 20:01:53 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 JUN 86 23:02:27 EDT
Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 19 JUN 86 23:01:11 EDT
Date: 18 Jun 1986 14:33 EDT (Wed)
Message-ID: <JINX.12215850914.BABYL@MIT-OZ>
From: Bill Rozas <JINX@OZ.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MX.LCS.MIT.EDU
Subject: Policy on change-making
In-reply-to: Msg of 17 Jun 1986 22:08-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
My feelings:
- Don't be unneccessarily radical, but fix things which are broken,
and change things to reflect the new consensus (if there is one).
- I would like the incompatibilities mentioned in the notes section.
∂23-Jun-86 1412 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Bibliography
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86 14:12:10 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86 17:13:15 EDT
Date: Mon, 23 Jun 86 17:11:43 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Bibliography
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].60539.860623.JAR>
I would like to update the "bibliography and references" section of
the report. If you have published new papers on Scheme-related topics
in the past year, or if you will have done so within the next few
weeks, or if you're aware of something which ought to be included,
please send me a complete, accurate reference, or an incomplete
reference and enough information for me to be able to track it down.
Already on my list of things to include are:
- Felleison et al, Reasoning with Continuations (Logic in CS conf)
- Kranz et al, ORBIT compiler (Compiler Construction conf)
- Feeley, Deux approches a l'implantation du langage Scheme (masters
thesis, Montreal)
but I'm sure there are many others.
Also, send your index entry suggestions.
Jonathan
∂26-Jun-86 2114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jun 86 21:14:31 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86 00:16:04 EDT
Received: from LIVE-OAK.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 27 JUN 86 00:14:00 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3220; Thu 26-Jun-86 19:04:00-EDT
Date: Thu, 26 Jun 86 19:03 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: Remaining questions & remarks (2)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Almost no one answered my query about grandfathering. Think about it
while answering the questions below. I propose listing incompatibilites
in the "notes" section, and otherwise not worrying too much about the
incompatibilities we're introducing. I'll send out a list of known
language changes in a separate message.
Here is the second list of remaining questions and remarks. Some of
these may be duplicates.
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
it's obvious to the world we couldn't get consensus on this one.
Many people have told me that they don't care which one is there, so
long as there's only one. SEQUENCE was used heavily in S&ICP and
for that reason I think it should be retained; thus the options I
offer are
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
Let me know your vote if you haven't done so already.
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
[The ones without question marks were used in S&ICP; moreover, they
exist in other Lisp dialects. The argument in favor of the ?'s is that
it allows the simple statement: "names of predicates end in question mark".]
Send me your vote.
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
The only options permitted are:
(a) Keep both
(b) Flush both
My editorial sense is that we should be able to achieve (b). Remember,
the language also doesn't have EVAL, environments, or macros, so if you
want to keep these features please say how they're different from other
"indispensible" features that the language DOESN'T have.
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
Many people have suggested removing these. Anyone who wants them
retained MUST provide a convincing rationale, for inclusion in the
report. Otherwise I'll remove them.
5. Should we say anything about the possibility of parallel or
interleaved argument evaluation? Remembering something I thought I
heard Will once say, I added the innocent little phrase "or perhaps
in parallel" to the description of procedure calling. Richard
Kelsey quickly pointed out that if it's mentioned as being a
possibly legal implementation, many otherwise valid scheme programs
may fail to run in implementations which do this, because they won't
do necessary synchronization. I agree; this is acceptable only if
we provide synchronization primitives.
6. Number input exactness: two proposals have been advanced to decide whether
a number is exact or inexact if it has no #I or #E prefix and contains no
trailing #'s.
(a) Inexact if there are digits following a decimal point, or if exponential
notation is used. Otherwise exact. (This makes exctness similar to
"floatness" in CL.)
(b) A proposal which Will advanced, which I'm unable to locate right now, so he'll
have to re-send it.
I'll additionally advance another alternative, and you can make up more of
your own:
(c) Always exact. E.g. "1.2" is exact.
7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
after being closed?
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
JAR replies (in jest):
(define procedure?
(lambda (obj)
(not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
Seriously however, I was the only holdout at Brandeis against having
this predicate. After thinking about this further I think it's not such
a bad idea, even though it is of limited use. Is anyone opposed to
having an essential procedure PROCEDURE?, to round out the set of type
predicates?
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people
have pointed out. I would expect these two expressions to have the
same meaning, but they don't. The first is defined to always return
an unspecified value. The second is defined to return the value 1
if x is true, and an unspecified value otherwise. I would like to
make this consistent, and there are two ways to do. Take your pick:
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to false.
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
Here are some arguments in favor of (a):
- It removes the possibility of inferring that an implementation might
not be tail-recursive through an alternate-less IF.
- Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
doubt about the meaning of things like (if x (if y 1) z).
- It simplifies the macro expansion of COND as compared with (b).
- Option (b) is obviously undesirable (consider the case of mutually
exclusive test expressions in a COND).
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away. S&ICP doesn't use it, and it has a rather complicated
syntax (look at the BNF for evidence). Vote keep or flush.
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
to be syntactically valid at top level of a file, shouldn't it be
renamed to be INCLUDE ?
15. Page breaks and tabs are mentioned in the report (actually I guess I
added them - sorry), but there are no #\PAGE or #\TAB characters.
Can this be made consistent by documenting #\PAGE and #\TAB, or
should I try to neutralize or remove the places where I mention tabs
and page breaks, by saying something to the effect that there may be
other whitespace characters, and some of these characters might
terminate comments? In Common Lisp, #\PAGE and #\TAB aren't
"standard", they're only semi-standard; and I don't believe that
16. If page breaks are documented, should the terminate comments? I think
they should (but of course they don't in Common Lisp).
17. Bartley says: "the second sentence of the description of EQUAL? should
say that EQV? is used for all objects except pairs, vectors, and
strings." Forcing it to use EQV? seems kind of random to me. This
would of course make my notion of "apparent equivalence" useless,
destroying what I deluded myself into thinking was an elegant symmetry
between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I
intentionally wanted to be silent on this point, allowing EQUAL? to
return true more often than EQV? perhaps, but I don't care that much.
-----
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
19. What should the dedication be? Sussman suggested the PDP-6, which was
the world's first Lisp machine, but some people didn't like this joke.
I have changed it to Christopher Strachey in the draft.
20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section
0.0)? This is Dan Friedman's suggestion and I approve; SASL is more
widely known. I've never heard of Lazy ML (although I can imagine what
it is).
21. Should section numbers be zero-based? I'm beginning to think this looks
unprofessional; and it just doesn't look right in several places. It
worked well in the previous version of the report, and it's clearly more
consistent with the language (which is zero-based), but it doesn't work
the way I've reorganized things. If you like zero-based section
numbers, speak up.
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
26. FORCE & DELAY are still problematic. About half of respondents said it
was better to put FORCE up front with DELAY, and the other half thought
it was fine as it was. No one gave convincing arguments.
27. Is 3.0.2 (description of procedure calls) a good place to take note that
() is not a valid procedure call?
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
29. There are two nonterminals in the BNF that need names. Currently they
are called <formals> and <formalz> which was never intended to be a
serious suggestion (I put it there to see if anyone would actually read
the BNF!). Actually one or both of these can go away if NAMED-LAMBDA
and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes
these things take a look at the BNF and suggest names for these?
30. Someone wanted me to avoid discussion of immutable objects in the
discussion of operational equivalence in the 2nd paragraph before entry
for EQV? . I want to mention immutability there because I think it's
important to warn users that this might be the case, otherwise they can
easily end up writing unportable code.
-----
For your information, here are changes I've made that either don't seem
controversial or reflect what I judged to be the consensus:
Language:
Only one empty list, period. (eq? '() '()) returns true.
Kelsey asks: why does ROUND round to even? Answer: Common Lisp does it
this way. Ask Steele. Probably this has to do with statistical
niceness.
A port does not become closed as a side effect of reaching end of file.
After end of file, you'll continue to read end of file objects as long
as the port is open. It's an error to read from or write to a closed
port.
DISPLAY writes characters like WRITE-CHAR does.
-----
Presentation:
"Iterative process" --> "iterative computation" on page 3 (this change
is an example of "desussmanization").
Inserted the following sentence in section 1.0:
"In addition, \ide{+}, \ide{-}, \ide{1+}, and \ide{-1+} are identifiers."
At Dan Friedman's request, I removed Perlis from the list of authors.
Changed <? and >? to < and > in all examples.
Removed non-essential features from examples (including the big one)
where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.
Changed variable name "loop" to "recur" in the
call-with-current-continuation example.
"iff" --> "if" in section 5.1.
-----
That's all for now, folks...
Jonathan
∂27-Jun-86 0943 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA r3rs presentation
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86 09:42:55 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 27 Jun 86 12:44:13 EDT
Full-Name:
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA00559; Fri, 27 Jun 86 11:38:01 EDT
Posted-Date: Fri, 27 Jun 86 11:37:13 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA19250; Fri, 27 Jun 86 11:37:13 edt
Date: Fri, 27 Jun 86 11:37:13 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8606271537.AA19250@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: r3rs presentation
I went on vacation and then I had trouble getting the r3rs.tar file.
By the time I sat down to read the report, I found my Scheme mail had
grown to 100 printed pages! We have a solid group of committed people.
I would like to make a few comments on presentation. The most
important comment is about section organization. Newspaper writers
spend most of their time writing the first three paragraphs of any
article. This part of the article is often the only part read by
readers, and is important in enticing readers to continue. In the
same way, The first page is most likely to be the only page read by
many SIGPLAN readers. If I had my choice of what I would ask them to
read, it would be the material in Section 0.0, the Semantics section
that notes that scheme is lexically scoped, tail recursive, weakly
typed, ... etc. I would expand on the discussion on continutations,
as they represent one important difference between Scheme and other
languages. The Introduction, with its history of scheme, its history
of scheme reports and meetings, and acknowledgements giving names of
people that the reader will not likely know, is not that one page I
would like all to read. I suggest moving the history to the back of
the report, and use the first couple of pages to convince the reader
that the language documented in this report is worth studying.
On less significant presentation issues, I would like to present a
view that a less sophisicated user of Scheme may get about
continuations. That is, this reader may conclude that continuations
are very powerful and always expensive to use. I know that the T
compiler of 1981 generated goto's from the a catch and throw
expression that exited a loop from within a loop. (Catch and throw is
old syntax for using continuations.) Since we promise that
tail-recursive procedures are executed in constant space, can't we
promise something about certain simple uses of continuations?
Otherwise, they may avoided by programmers for the wrong reasons.
Random notes
[pg. 6, col. 2, +15] In the term "meta-program" well known?
[pg. 30, col. 1] Some note is needed explaining why there are two
different close procedures.
[pg. 29] If call-with-current-continuation calls its argument with
the current continuation, should the I/O routines call-with-input-file
and call-with-output-file be renamed call-with-input-port and
call-with-output-port?
John
∂27-Jun-86 1115 @MC.LCS.MIT.EDU:gls@Think.COM Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86 11:08:13 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 27 Jun 86 13:39:25 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 13:36:07 edt
Date: Fri, 27 Jun 86 13:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Remaining questions & remarks (2)
To: JAR@MIT-AI.ARPA, rrrs-authors@MIT-MC.ARPA
Cc: gls@AQUINAS
In-Reply-To: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <860627133714.3.GLS@BOETHIUS.THINK.COM>
Date: Thu, 26 Jun 86 19:03 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
it's obvious to the world we couldn't get consensus on this one.
Many people have told me that they don't care which one is there, so
long as there's only one. SEQUENCE was used heavily in S&ICP and
for that reason I think it should be retained; thus the options I
offer are
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
(b)
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
(b)
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
Don't forget, of course, to say that Algol 60 came real close. I think you
should research the languages GEDANKEN (Reynolds) and ISWIM (Landin), as one
of those might have had closures. I believe ISWIM was described in CACM in
the mid-1960's.
Kelsey asks: why does ROUND round to even? Answer: Common Lisp does it
this way. Ask Steele. Probably this has to do with statistical
niceness.
ROUND rounds to even because the integer "rounding modes" (floor, ceiling,
round, truncate) were chosen to correspond to the rounding modes required by
the IEEE floating point standard. That standard in turn mandates rounding
to even for what indeed amounts to statistical niceness: on the average the
effects of rounding tend to cancel out. Why round to even instead of odd?
Then further operations on those results are more likely to be exactly
representable and therefore not require further loss of accuracy due to
rounding.
--Guy
∂27-Jun-86 1653 @MC.LCS.MIT.EDU:SGR@ELEPHANT-BUTTE.SCRC.Symbolics.COM [INGRIA@G.BBN.COM: Scheme for LISPM]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86 16:53:02 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 27 Jun 86 19:40:24 EDT
Received: from GROUSE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31612; Fri 27-Jun-86 17:02:04 EDT
Date: Fri, 27 Jun 86 17:02 EDT
From: Stephen G. Rowley <SGR@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [INGRIA@G.BBN.COM: Scheme for LISPM]
To: Scheme@MIT-MC.ARPA
Message-ID: <860627170237.3.SGR@GROUSE.SCRC.Symbolics.COM>
This sounds like a question for people on this list:
Date: Thu, 26 Jun 1986 16:47 EDT
Message-ID: <INGRIA.12217972484.BABYL@G.BBN.COM>
From: INGRIA@G.BBN.COM
To: INFO-LISPM@MC.LCS.MIT.EDU
Subject: Scheme for LISPM
Does anyone have an implementation of Scheme that runs on
LISPMs? It would be useful for us to have a version that runs on Rel6
on 36XXs. Thanks in advance.
-30-
Bob
∂27-Jun-86 1930 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU typo
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86 19:30:29 PDT
Received: from VAIL.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86 22:28:27 EDT
Date: Fri, 27 Jun 86 22:29 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: typo
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860627222941.1.JAR@VAIL.LCS.MIT.EDU>
Of course I meant "return the value of the second form if the first
evaluates to *true*," not false.
∂27-Jun-86 2142 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Grandfathering Responses
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86 21:42:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 00:38:15 EDT
Received: from indiana by csnet-relay.csnet id aa23894; 28 Jun 86 0:36 EDT
Date: Fri, 27 Jun 86 11:09:20 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Grandfathering Responses
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
it's obvious to the world we couldn't get consensus on this one.
Many people have told me that they don't care which one is there, so
long as there's only one. SEQUENCE was used heavily in S&ICP and
for that reason I think it should be retained; thus the options I
offer are
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
Let me know your vote if you haven't done so already.
*****>> (a)
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
[The ones without question marks were used in S&ICP; moreover, they
exist in other Lisp dialects. The argument in favor of the ?'s is that
it allows the simple statement: "names of predicates end in question mark".]
Send me your vote.
******>> (b)
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
The only options permitted are:
(a) Keep both
(b) Flush both
My editorial sense is that we should be able to achieve (b). Remember,
the language also doesn't have EVAL, environments, or macros, so if you
want to keep these features please say how they're different from other
"indispensible" features that the language DOESN'T have.
Named-lambda is totally unacceptable.
Letrec is often overkill and without macros we will be left
with using it. Rec is an incredibly powerful tool. I'd hate
to lose it from my repertoire. However, named-lambda is an
ugly so I am forced, given these choices, to opt for (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
Many people have suggested removing these. Anyone who wants them
retained MUST provide a convincing rationale, for inclusion in the
report. Otherwise I'll remove them.
****>> Remove them
5. Should we say anything about the possibility of parallel or
interleaved argument evaluation? Remembering something I thought I
heard Will once say, I added the innocent little phrase "or perhaps
in parallel" to the description of procedure calling. Richard
Kelsey quickly pointed out that if it's mentioned as being a
possibly legal implementation, many otherwise valid scheme programs
may fail to run in implementations which do this, because they won't
do necessary synchronization. I agree; this is acceptable only if
we provide synchronization primitives.
****>> Yes, either provide synchonization primitives or flush the comment
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
*****>> don't keep both.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
*****>> I agree with the consensus.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
*****>> follow Occam's razor here.
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
JAR replies (in jest):
(define procedure?
(lambda (obj)
(not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
Seriously however, I was the only holdout at Brandeis against having
this predicate. After thinking about this further I think it's not such
a bad idea, even though it is of limited use. Is anyone opposed to
having an essential procedure PROCEDURE?, to round out the set of type
predicates?
*****> include procedure?, but be sure that
(call/cc (lambda (k) (k (procedure? k)))) --> #t.
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people
have pointed out. I would expect these two expressions to have the
same meaning, but they don't. The first is defined to always return
an unspecified value. The second is defined to return the value 1
if x is true, and an unspecified value otherwise. I would like to
make this consistent, and there are two ways to do. Take your pick:
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to false.
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
Here are some arguments in favor of (a):
- It removes the possibility of inferring that an implementation might
not be tail-recursive through an alternate-less IF.
- Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
doubt about the meaning of things like (if x (if y 1) z).
- It simplifies the macro expansion of COND as compared with (b).
- Option (b) is obviously undesirable (consider the case of mutually
exclusive test expressions in a COND).
****>> I favor including a "(when pred val) as the proper special form
for two branch-if's. That way two branch-if's would be syntactically
illegal. I've used them for about a year and I find less bugs creeping
into other's and my own programs.
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away. S&ICP doesn't use it, and it has a rather complicated
syntax (look at the BNF for evidence). Vote keep or flush.
*****>> flush it.
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
****> Realize that Scheme is not "almost"-functional, it's almost Algol!
I agree wholeheartedly agree with Will's characterization.
The best that can be said with respect to the functionality
of Scheme is that it contains a coherent subset that is "functional".
19. What should the dedication be? Sussman suggested the PDP-6, which was
the world's first Lisp machine, but some people didn't like this joke.
I have changed it to Christopher Strachey in the draft.
****> I prefer Christopher Strachey.
21. Should section numbers be zero-based? I'm beginning to think this looks
unprofessional; and it just doesn't look right in several places. It
worked well in the previous version of the report, and it's clearly more
consistent with the language (which is zero-based), but it doesn't work
the way I've reorganized things. If you like zero-based section
numbers, speak up.
*****> 1-based seems better.
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
*****> Landin's ISWIM was the first well-known one back in the early 60's.
However, I would guess that the use of "function" in the
"Lisp 1.5 Programmming Language Manual" should count as
a first-class closure. If all "lambda"'s were surrounded by
(function ...) then LISP 1.5 would model them. Furthermore,
call/cc can be written with Landin's J operat.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
*****> I won't argue for the history. However, the implementor who
thinks that catch (as in Common Lisp) and call/cc are the same
is in for a shock. That should perhaps be pointed out.
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
****> Carolyn Talcott in her dissertation suggested the term "note".
I could live with that. If call-with-current-continuation is
the only term, this will make those of us who write about this object
uncomfortable. I think we agreed that "call/cc" would be an
acceptable abbreviation and I would prefer to keep that name
in the report. Those who don't like the name can choose not to use it.
In a sense I agree with your argument, but "call-with-current
-continuation has 30 characters in it!, "labels" and "letrec", and
"block" and "begin" each have the same number of characters.
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
****> "variable" is a "dangerous" word, try to expunge it. Opinions differ
as to what a variable is.
26. FORCE & DELAY are still problematic. About half of respondents said it
was better to put FORCE up front with DELAY, and the other half thought
it was fine as it was. No one gave convincing arguments.
****> I favor join them. I don't much care where they are joined.
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
****> See comment on 26.
29. There are two nonterminals in the BNF that need names. Currently they
are called <formals> and <formalz> which was never intended to be a
serious suggestion (I put it there to see if anyone would actually read
the BNF!). Actually one or both of these can go away if NAMED-LAMBDA
and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes
these things take a look at the BNF and suggest names for these?
****> I hope they go away.
Language:
Removed non-essential features from examples (including the big one)
where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.
****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the
abuse of punnery "-1+", and its slightly weaker sibling "1+".
The cuteness of "-1+" should go. In writing for a mass audience
I have learned that there is a time and a place for clever un-pronouceable
function names. Please remove them and find pronounceable words
Dan
∂28-Jun-86 1511 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU variable vs. identifier
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jun 86 15:11:09 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 JUN 86 12:37:38 EDT
Date: Sat, 28 Jun 86 12:36:57 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: variable vs. identifier
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].62926.860628.JAR>
From the messages I've recieved, it apparently wasn't clear why two
distinct words are needed. I want to make sure that the grammar
reflects the decision that we will leave it up to implementations
(i.e. leave it "unspecified") just what things like (let ((if ...))
...) would mean. So at the very least these expressions have to be
excluded from the grammar. Therefore one word is needed for things
that are lexically like symbols (and can appear inside of QUOTE
expressions), and another is needed for those things that can be bound
and referred to. I chose "identifier" for the first and "variable"
for the second. Thus IF is an identifier but not a variable. I like
the way this turned out, and can't think of anything else that would
work as well.
∂28-Jun-86 1511 @MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA Grandfathering response
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jun 86 15:11:24 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 15:49:47 EDT
Received: from indiana by csnet-relay.csnet id aa28825; 28 Jun 86 15:37 EDT
Date: Sat, 28 Jun 86 11:50:33 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Grandfathering response
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
it's obvious to the world we couldn't get consensus on this one.
Many people have told me that they don't care which one is there, so
long as there's only one. SEQUENCE was used heavily in S&ICP and
for that reason I think it should be retained; thus the options I
offer are
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
Let me know your vote if you haven't done so already.
*****>> (a)
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
[The ones without question marks were used in S&ICP; moreover, they
exist in other Lisp dialects. The argument in favor of the ?'s is that
it allows the simple statement: "names of predicates end in question mark".]
Send me your vote.
******>> (b)
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
The only options permitted are:
(a) Keep both
(b) Flush both
My editorial sense is that we should be able to achieve (b). Remember,
the language also doesn't have EVAL, environments, or macros, so if you
want to keep these features please say how they're different from other
"indispensible" features that the language DOESN'T have.
Named-lambda is totally unacceptable.
Letrec is often overkill and without macros we will be left
with using it. Rec is an incredibly powerful tool. I'd hate
to lose it from my repertoire. However, named-lambda is an
ugly so I am forced, given these choices, to opt for (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
Many people have suggested removing these. Anyone who wants them
retained MUST provide a convincing rationale, for inclusion in the
report. Otherwise I'll remove them.
****>> Remove them
5. Should we say anything about the possibility of parallel or
interleaved argument evaluation? Remembering something I thought I
heard Will once say, I added the innocent little phrase "or perhaps
in parallel" to the description of procedure calling. Richard
Kelsey quickly pointed out that if it's mentioned as being a
possibly legal implementation, many otherwise valid scheme programs
may fail to run in implementations which do this, because they won't
do necessary synchronization. I agree; this is acceptable only if
we provide synchronization primitives.
****>> Yes, either provide synchonization primitives or flush the comment
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
*****>> don't keep both.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
*****>> I agree with the consensus.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
*****>> follow Occam's razor here.
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
JAR replies (in jest):
(define procedure?
(lambda (obj)
(not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
Seriously however, I was the only holdout at Brandeis against having
this predicate. After thinking about this further I think it's not such
a bad idea, even though it is of limited use. Is anyone opposed to
having an essential procedure PROCEDURE?, to round out the set of type
predicates?
*****> include procedure?, but be sure that
(call/cc (lambda (k) (k (procedure? k)))) --> #t.
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people
have pointed out. I would expect these two expressions to have the
same meaning, but they don't. The first is defined to always return
an unspecified value. The second is defined to return the value 1
if x is true, and an unspecified value otherwise. I would like to
make this consistent, and there are two ways to do. Take your pick:
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to false.
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
Here are some arguments in favor of (a):
- It removes the possibility of inferring that an implementation might
not be tail-recursive through an alternate-less IF.
- Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
doubt about the meaning of things like (if x (if y 1) z).
- It simplifies the macro expansion of COND as compared with (b).
- Option (b) is obviously undesirable (consider the case of mutually
exclusive test expressions in a COND).
****>> I favor including a "(when pred val) as the proper special form
for two branch-if's. That way two branch-if's would be syntactically
illegal. I've used them for about a year and I find less bugs creeping
into other's and my own programs.
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away. S&ICP doesn't use it, and it has a rather complicated
syntax (look at the BNF for evidence). Vote keep or flush.
*****>> flush it.
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
****> Realize that Scheme is not "almost"-functional, it's almost Algol!
I agree wholeheartedly agree with Will's characterization.
The best that can be said with respect to the functionality
of Scheme is that it contains a coherent subset that is "functional".
19. What should the dedication be? Sussman suggested the PDP-6, which was
the world's first Lisp machine, but some people didn't like this joke.
I have changed it to Christopher Strachey in the draft.
****> I prefer Christopher Strachey.
21. Should section numbers be zero-based? I'm beginning to think this looks
unprofessional; and it just doesn't look right in several places. It
worked well in the previous version of the report, and it's clearly more
consistent with the language (which is zero-based), but it doesn't work
the way I've reorganized things. If you like zero-based section
numbers, speak up.
*****> 1-based seems better.
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
*****> Landin's ISWIM was the first well-known one back in the early 60's.
However, I would guess that the use of "function" in the
"Lisp 1.5 Programmming Language Manual" should count as
a first-class closure. If all "lambda"'s were surrounded by
(function ...) then LISP 1.5 would model them. Furthermore,
call/cc can be written with Landin's J operat.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
*****> I won't argue for the history. However, the implementor who
thinks that catch (as in Common Lisp) and call/cc are the same
is in for a shock. That should perhaps be pointed out.
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
****> Carolyn Talcott in her dissertation suggested the term "note".
I could live with that. If call-with-current-continuation is
the only term, this will make those of us who write about this object
uncomfortable. I think we agreed that "call/cc" would be an
acceptable abbreviation and I would prefer to keep that name
in the report. Those who don't like the name can choose not to use it.
In a sense I agree with your argument, but "call-with-current
-continuation has 30 characters in it!, "labels" and "letrec", and
"block" and "begin" each have the same number of characters.
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
****> "variable" is a "dangerous" word, try to expunge it. Opinions differ
as to what a variable is.
26. FORCE & DELAY are still problematic. About half of respondents said it
was better to put FORCE up front with DELAY, and the other half thought
it was fine as it was. No one gave convincing arguments.
****> I favor join them. I don't much care where they are joined.
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
****> See comment on 26.
29. There are two nonterminals in the BNF that need names. Currently they
are called <formals> and <formalz> which was never intended to be a
serious suggestion (I put it there to see if anyone would actually read
the BNF!). Actually one or both of these can go away if NAMED-LAMBDA
and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes
these things take a look at the BNF and suggest names for these?
****> I hope they go away.
Language:
Removed non-essential features from examples (including the big one)
where possible: (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.
****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the
abuse of punnery "-1+", and its slightly weaker sibling "1+".
The cuteness of "-1+" should go. In writing for a mass audience
I have learned that there is a time and a place for clever un-pronouceable
function names. Please remove them and find pronounceable words
∂29-Jun-86 1205 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [INGRIA@G.BBN.COM: Scheme for LISPM]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jun 86 12:05:51 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUN 86 14:59:40 EDT
Date: Sun, 29 Jun 86 14:58:30 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [INGRIA@G.BBN.COM: Scheme for LISPM]
To: INGRIA@BBNG.ARPA
cc: SGR@SCRC-STONY-BROOK.ARPA, Scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 27 Jun 86 17:02 EDT from Stephen G. Rowley <SGR at STONY-BROOK.SCRC.Symbolics.COM>
Message-ID: <[AI.AI.MIT.EDU].63300.860629.JAR>
Date: Thu, 26 Jun 1986 16:47 EDT
Message-ID: <INGRIA.12217972484.BABYL@G.BBN.COM>
From: INGRIA@G.BBN.COM
To: INFO-LISPM@MC.LCS.MIT.EDU
Subject: Scheme for LISPM
Does anyone have an implementation of Scheme that runs on
LISPMs? It would be useful for us to have a version that runs on Rel6
on 36XXs. Thanks in advance.
I wrote one last summer. It's not great for development, since there
are no debugging facilities besides TRACE, but it works. It is written in
Common Lisp, but it has been comditionalized to make it also work in
Rel 6 Symbolics Common Lisp (which is full of bugs). If you're at BBN,
you should contact Don Allen and get a copy from him. Otherwise
contact me (JAR@MIT-AI) and I'll give you more information.
Jonathan
∂29-Jun-86 2140 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jun 86 21:40:26 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 00:37:18 EDT
Received: from indiana by csnet-relay.csnet id ab01297; 30 Jun 86 0:37 EDT
Date: Sun, 29 Jun 86 19:58:16 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: Re: Remaining questions & remarks (2)
Cc: rrrs-authors@MC.LCS.MIT.EDU
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
...
(a) leave things as they are (BEGIN essential with non-essential
...
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
...
(b) [I hate the name begin... I am always looking for a corresponding end]
2. Similarly but less glaringly, we have a problem with the numeric
...
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
...
(b)
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
...
(a) Keep both
(b) Flush both
My editorial sense is that we should be able to achieve (b). Remember,
...
(b)
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
Many people have suggested removing these. Anyone who wants them
...
remove them
5. Should we say anything about the possibility of parallel or
...
remove mention of parallel argument evaluation
7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
...
I would prefer if it was but not strongly
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
call it phase
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
are they not different in implementations without complex numbers?
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
JAR replies (in jest):
(define procedure?
(lambda (obj)
(not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
Seriously however, I was the only holdout at Brandeis against having
...
it should be included---I would much prefer the name "closure?"
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent, as a couple of people
...
(a) Change IF expressions so that they return the value of the
...
(b) Change COND and CASE so that they return an unspecified value if
...
...
(c) require if to have a consequent and include WHEN as required---this gets
rid of the whole mess and is much cleaner.
13. Many people would like to see the (define ((((a b) c) d) e) ...)
...
flush it
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
...
renamed to be INCLUDE ?
no... load implies run time, include implies compile time, if they are
different
15. Page breaks and tabs are mentioned in the report (actually I guess I
...
leave them out where possible
17. Bartley says: "the second sentence of the description of EQUAL? should
...
I agree with David
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
...
I'd say leave Will's description.
19. What should the dedication be? Sussman suggested the PDP-6, which was
...
how about Haskell B. Curry?
20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section
...
it does seem more appropriate; SASL predates lazy ML.
21. Should section numbers be zero-based? I'm beginning to think this looks
...
1-based seems best
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
ISWIM (Burge) had them about ten years prior to Scheme. might want to refer
to Burge, W.H. ``ISWIM Programming Manual,'' IBM Research Report RA129,
Yorktown Heights, New York (November 1981).
23. I flushed the historical note "CATCH could be provided by a procedure"
...
I agree, flush it.
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
...
definitely keep call/cc. call/cc has appeared in several papers, and it is
much easier to type in without making mistakes---the other name compromises
did not end us up with names 5 times as long
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
I prefer identifier for all symbols, such as keywords and lexical identifiers,
and variable for lexical identifiers.
26. FORCE & DELAY are still problematic. About half of respondents said it
was better to put FORCE up front with DELAY, and the other half thought
it was fine as it was. No one gave convincing arguments.
they should be together, I would say where FORCE now is
27. Is 3.0.2 (description of procedure calls) a good place to take note that
() is not a valid procedure call?
it should be obvious from the syntax
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
yes
Changed variable name "loop" to "recur" in the
call-with-current-continuation example.
please don't---recur is the name of a special form in Chez Scheme and
is used by lots of people---I'd like to avoid confusion
As for grandfathering, unless the original RRRS report was distributed
much more widely than I figure it was, I would rather see no mention of
the incompatibilities. It is not worthwhile to support old features
when the affected group of people is fairly small (particularly for new
implementations). Besides, the various language manuals for existing
implementations with all their differing syntaxes were much more widely
distributed in total, and their features are not being grandfathered.
Kent
∂30-Jun-86 0741 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA Re: r3rs presentation (long)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jun 86 07:41:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 10:39:57 EDT
Received: from indiana by csnet-relay.csnet id aa04496; 30 Jun 86 10:37 EDT
Date: Mon, 30 Jun 86 03:46:12 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: ramsdell%linus@MITRE-BEDFORD.ARPA
Subject: Re: r3rs presentation (long)
Cc: rrrs-authors@MC.LCS.MIT.EDU
On less significant presentation issues, I would like to present a
view that a less sophisicated user of Scheme may get about
continuations. That is, this reader may conclude that continuations
are very powerful and always expensive to use. I know that the T
compiler of 1981 generated goto's from the a catch and throw
expression that exited a loop from within a loop. (Catch and throw is
old syntax for using continuations.) Since we promise that
tail-recursive procedures are executed in constant space, can't we
promise something about certain simple uses of continuations?
Otherwise, they may avoided by programmers for the wrong reasons.
The T compiler of 1981 did not support continuations, just Lisp-style
catch and throw. However, simple uses can be compiled into jumps or
not much more. For instance, a smart compiler can tell that
(call/cc (lambda (k) (if (zero? x) (k x) (/ 1 x))))
requires nothing more than a goto for (k x). The ability to perform
this improvement is easily lost; if k is returned, placed somewhere,
or invoked from within a closure that is returned or placed somewhere,
etc., the full continuation must be made. Recursion makes things a
little more difficult, since it requires not just a goto but some way
of recording the depth of the stack. What's more, it takes a fairly
sophisticated compiler (or some special-casing) not to trip on
(call/cc
(lambda (return)
(letrec ([g (lambda (l a)
(cond
[(null? l) a]
[else
(when (zero? (car l)) (return 'oops))
(g (cdr l) (/ a (car l)))]))])
(g some-list-of-numbers 1))))
because it appears that return is closed over even though g can be
implemented as a simple loop (but couldn't be, for example, if the
closure g itself were returned instead of 'oops). But this may be
just what the "do" expression below turns into.
(call/cc
(lambda (return)
(do ([l some-list-of-numbers (cdr l)]
[a 1 (/ a (car l))])
((null? l) a)
(when (zero? (car l)) (return 'oops)))))
(Actually, it's worse than that, since letrec is itself a derived
form and really appears as a convoluted combination of lambda and
set! expressions.)
Making a guarantee that call/cc produces essentially gotos in simple
situations might backfire, too, resulting in convoluted code to take
advantage of the faster call/cc. For instance, a programmer might
abandon map in favor of hand-coded loops, or not take full advantage
of closures and recursion.
Another problem with making such a guarantee is that call/cc is a
function, not a special form, and its value might change, e.g., for
tracing or "constraining control". Certainly, it would be possible
to generate code for the first example something like
(if (eq? call/cc *primitive-call/cc*)
{fancy goto code for (if (zero? x) (k x) (/ 1 x))}
{normal application of call/cc to (lambda (k) ...)}),
but this would be clumsy and wasteful of code space.
Some implementations of Scheme currently promote some or all primitive
functions almost to special form status... if the identifier's binding
is the expected one at compile time, assume it will be at run time and
generate inline code. For example, car and cdr might be inlined this
way. In these systems, call/cc could presumably be nailed down too.
But it cannot be guaranteed so in the RRRS without implying that some
primitives are really special forms.
Since I have brought the issue up, how does everyone feel about this
special treatment for primitives? Should it be explicitly allowed or
disallowed? All of the arguments against allowing extra special forms
come in to play here as well, plus others, so I'd say it should be
disallowed, at least by default. I have no problem with some sort of
flag controlling this behavior, e.g., (set! *benchmark-mode* #t). Or
perhaps we want to say that all primitives are special forms or that
primitive identifiers are not assignable (I don't think so).
How about making call/cc a special form? I've often wondered if it
should be even though its evaluation rule would be the same as for
function application. Call/cc is basic to any system, and support
for it must be provided by the compiler, at least in the way it
represents things. Why should something be a function and not a
special form just because its evaluation rule coincides with the
evaluation rule for function applications?
(By the way, what about "not"? How many times have you seen someone
turn a conditional expression around to avoid the extra call?)
Kent
∂01-Jul-86 1040 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Call-with-current-continuation
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86 10:40:22 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 1 Jul 86 13:18:51 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA02064; Tue, 1 Jul 86 13:19:55 EDT
Posted-Date: Tue, 1 Jul 86 13:21:34 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA02532; Tue, 1 Jul 86 13:21:34 edt
Date: Tue, 1 Jul 86 13:21:34 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607011721.AA02532@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Call-with-current-continuation
I told a white lie. My worry about the way continuations are
perceived was generated from opinions expressed by a knowledgeable
computer scientist from Harvard, not by myself. This person showed a
good understanding of continuations, but worried about the runtime
overhead incurred even when continuations are used to express control
patterns that can be implemented using constant space (or a stack).
Agreeing with Kent, I cannot think of any way to promise something
about the execution of certain simple uses of continuations. I guess
we should leave the topic of how to use continuations to another
document.
We've heard reviews of r3rs from knowledgeable users of Scheme, has
anyone received an opinion of the document from a reader that is
representative of the general programming language community?
John
PS. Sorry about being sloppy about T's continuations. T of 1981
restricted continuations to those that allowed stack allocation of
control structure. You could not return from a continuation twice or
pass a continuation out of its defining environment. Thus, a more
correct statement is that CATCH and call of a T continuation was
syntax for stack-based continuations. In the interpreter, CATCH was
expanded to a lambda expression and a call to a procedure like
call-with-current-continuation, but the same restriction on the
continuations applied.
∂01-Jul-86 1432 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86 14:27:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 1 Jul 86 17:21:32 EDT
Received: from ti-csl by csnet-relay.csnet id aa02302; 30 Jun 86 15:51 EDT
Received: by tilde id AA19055; Mon, 30 Jun 86 13:55:24 cdt
Date: Mon 30 Jun 86 13:47:42-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Remaining questions & remarks (2)
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12218999275.23.BARTLEY@CSC60>
=======> Here are my comments. I don't care all that much about the items
=======> I've skipped over. --David Bartley
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report
[...]
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
=======> I strongly prefer (a). BEGIN is the traditional name and is easy
=======> to understand (even without END). SEQUENCE is a *type* in Common
=======> LISP and is likely to cause confusion. I thought Hal and Gerry
=======> had indicated at Brandeis that they were willing to revise the
=======> book to use BEGIN instead of SEQUENCE. (Is my memory faulty?)
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
=======> (b)
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
The only options permitted are:
(a) Keep both
(b) Flush both
=======> (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
=======> Flush them.
5. Should we say anything about the possibility of parallel or
interleaved argument evaluation? Remembering something I thought I
heard Will once say, I added the innocent little phrase "or perhaps
in parallel" to the description of procedure calling. Richard
Kelsey quickly pointed out that if it's mentioned as being a
possibly legal implementation, many otherwise valid scheme programs
may fail to run in implementations which do this, because they won't
do necessary synchronization. I agree; this is acceptable only if
we provide synchronization primitives.
=======> Flush the reference to parallel evaluation. Keep random order
=======> evaluation.
6. Number input exactness:
=======> I haven't come to terms with exactness yet, so I don't have an
=======> opinion. Has anyone implemented this yet?
7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
after being closed?
=======> Yes. (Maybe. (I don't know. (What a question!)))
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
=======> Flush MAGNITUDE; keep ABS.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
=======> Use PHASE.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
=======> Is there any problem with precision here? I'll go with the
=======> consensus.
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
=======> As Dan points out, we need to make it clear whether a
=======> continuation object is a "procedure" in the sense of this
=======> predicate. If we call it CLOSURE?, as someone (Kent Dybvig?)
=======> suggested, then it should perhaps discriminate against
=======> continuations. Since it is implementation-dependent whether
=======> continuations are easily distinguished from closures, I prefer a
=======> PROCEDURE? that is true of both closures and continuations.
12. (if x 1) vs. (cond (x 1))
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to false. [TRUE]
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
=======> (a), as amended.
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away. S&ICP doesn't use it, and it has a rather complicated
syntax (look at the BNF for evidence). Vote keep or flush.
=======> Flush.
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
to be syntactically valid at top level of a file, shouldn't it be
renamed to be INCLUDE ?
=======> I'm not sure what INCLUDE means to people. My intuition is that
=======> INCLUDE is a conditional LOAD---it is ignored if the specified
=======> files has already been loaded. LOAD is unconditional and more
=======> appropriate as a building block for smarter capabilities.
15. Page breaks and tabs are mentioned in the report (actually I guess I
added them - sorry), but there are no #\PAGE or #\TAB characters.
Can this be made consistent by documenting #\PAGE and #\TAB, or [...]
=======> Lump these under "other whitespace". I intend to treat them as
=======> in Common LISP.
16. If page breaks are documented, should the terminate comments? I think
they should (but of course they don't in Common Lisp).
=======> They won't if they are just whitespace.
17. Bartley says: "the second sentence of the description of EQUAL? should
say that EQV? is used for all objects except pairs, vectors, and
strings." Forcing it to use EQV? seems kind of random to me. This
would of course make my notion of "apparent equivalence" useless,
destroying what I deluded myself into thinking was an elegant symmetry
between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I
intentionally wanted to be silent on this point, allowing EQUAL? to
return true more often than EQV? perhaps, but I don't care that much.
=======> I think that explicitly mentioning EQV? would clarify things.
=======> In particular, people want to understand how EQ?, EQV?, and
=======> EQUAL? are related. I think its easier to understand them if
=======> they monotonically become less discriminating; thus all things
=======> that are EQ? are also EQV? and EQUAL? and all things that are
=======> EQV? are also EQUAL?.
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
=======> Keep Will's description.
21. Should section numbers be zero-based? I'm beginning to think this looks
unprofessional; and it just doesn't look right in several places. It
worked well in the previous version of the report, and it's clearly more
consistent with the language (which is zero-based), but it doesn't work
the way I've reorganized things. If you like zero-based section
numbers, speak up.
=======> One-based.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
=======> We need to explain that CALL/CC is more than CATCH.
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
=======> Keep CALL/CC.
Language:
Only one empty list, period. (eq? '() '()) returns true.
=======> Yes.
A port does not become closed as a side effect of reaching end of file.
After end of file, you'll continue to read end of file objects as long
as the port is open. It's an error to read from or write to a closed
port.
=======> Yes. Yes. Yes.
DISPLAY writes characters like WRITE-CHAR does.
=======> Yes.
=======> Regards,
=======> David Bartley
-------
∂01-Jul-86 1446 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86 14:34:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 1 Jul 86 17:28:39 EDT
Received: from tektronix by csnet-relay.csnet id ad03875; 30 Jun 86 19:09 EDT
Received: by tektronix.TEK (5.31/6.15)
id AA15265; Mon, 30 Jun 86 14:39:28 PDT
Received: by tekchips.TEK (5.31/6.15)
id AA08024; Mon, 30 Jun 86 14:41:11 PDT
Message-Id: <8606302141.AA08024@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Subject: Re: Remaining questions & remarks (2)
In-Reply-To: Your message of Thu, 26 Jun 86 19:03 EDT.
<"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Date: 30 Jun 86 14:41:09 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
1. BEGIN vs. SEQUENCE...
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
*****> (a). Fix the book so we can get rid of SEQUENCE.
2. <names of arithmetic comparators>
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
*****> (b). MacScheme will continue to support the alternative names.
3. REC and NAMED-LAMBDA...
(a) Keep both
(b) Flush both
*****> (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT!...
*****> Flush them, but encourage Chris Hanson to publish his suite of
operations in a separate document.
5. <the possibility of parallel or interleaved argument evaluation>
*****> Drop the comment. (I use call-without-interrupts, but that
might not be so sweet on some multiprocessors.)
6. Number input exactness: two proposals have been advanced to decide whether
a number is exact or inexact if it has no #I or #E prefix and contains no
trailing #'s.
(a) Inexact if there are digits following a decimal point, or if
exponential notation is used. Otherwise exact. (This makes
exctness similar to "floatness" in CL.)
(b) A proposal which Will advanced, which I'm unable to locate right
now, so he'll have to re-send it.
I'll additionally advance another alternative, and you can make up more of
your own:
(c) Always exact. E.g. "1.2" is exact.
*****> (b). The proposal was that exponents be treated as shorthand, so
for example 1.2e3 would be treated as though it had been written 1200,
1.2000e3 would be treated as though it had been written 1200.0, and so
on; if, after getting rid of the exponent in this way, there are
digits following a decimal point, then assume inexact; otherwise
assume exact.
(a) is also ok. I think scientists and engineers would quickly
become exasperated by (c), however.
7. Must a port still be a port...after being closed?
*****> No, but we shouldn't make a big issue of whatever we decide.
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
*****> Flush MAGNITUDE. Talk about ABS where MAGNITUDE is now talked
about.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
*****> I don't care.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
*****> PLEASE don't flush two-argument ATAN, because an implementation
that supports flonums but not complexnums is going to have a hard
time with (ANGLE (MAKE-RECTANGULAR X Y)).
11. ...Is anyone opposed to having an essential procedure PROCEDURE?...
*****> I very much want one. I agree with Dan that
(call-with-current-continuation (lambda (k) (procedure? k)))
must be true.
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent...
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to [true].
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
*****> (a).
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away.
*****> Flush. MacScheme will continue to support it.
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
to be syntactically valid at top level of a file, shouldn't it be
renamed to be INCLUDE ?
*****> LOAD should be syntactically valid only at the top level of a file.
I suppose it should be renamed to INCLUDE, but I don't want to.
LOAD seems a more appropriate name for something that will in fact
be used interactively, even though we don't talk about interactive
programming in the report.
15. Page breaks and tabs are mentioned in the report (actually I guess I
added them - sorry), but there are no #\PAGE or #\TAB characters...
*****> Please neutralize the places that mention tabs and page breaks.
Let's not get hung up about characters.
16. If page breaks are documented, should [they] terminate comments?
*****> I think so.
17. Bartley says: "the second sentence of the description of EQUAL? should
say that EQV? is used for all objects except pairs, vectors, and
strings." Forcing it to use EQV? seems kind of random to me. This
would of course make my notion of "apparent equivalence" useless,
destroying what I deluded myself into thinking was an elegant symmetry
between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I
intentionally wanted to be silent on this point, allowing EQUAL? to
return true more often than EQV? perhaps, but I don't care that much.
*****> I think your "apparent equivalence" was a valiant effort on behalf
of a lost cause. I think Bartley's suggestion will simplify the
report and will make the language easier to understand and use.
-----
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
*****> Admit that Scheme isn't functional. Add a note to the effect that
in programs without side effects one can safely pretend that the
variables are bound directly to the arguments.
19. What should the dedication be? Sussman suggested the PDP-6, which was
the world's first Lisp machine, but some people didn't like this joke.
I have changed it to Christopher Strachey in the draft.
*****> The abstract from the RRRS was a better joke, because it said
something serious. A dedication to DEC PDP-6 Serial Number 2
could well offend the memory of the person to whom the Algol 60
Report was dedicated, so I think we'd better flush it. Do we
have to have a dedication? I'm not sure how many of us actually
met Christopher Strachey. I remember Alonzo Church from the 1982
Lisp Conference, and he might be better; maybe we could dedicate
the report to both. I believe that Church died a couple of years
ago, but I might be thinking of Haskell Curry instead. Dan? Mitch?
20. Is it OK to replace "Lazy ML" with "SASL"...
*****> Yes.
21. Should section numbers be zero-based?
*****> I've decided that zero-based numbering is perceived as cutesy.
I've found it helpful to have an unnumbered introductory section
at the beginning of a chapter, which I think of as section 0 of
that chapter, but I think it's best not to number it that way.
My apologies for setting the precedent in the RRRS.
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
*****> I don't think Scheme was the first. Scheme is unique not because
it was the first to have anything (except full continuations, and
even there it was anticipated by one of Reynolds's unimplemented
languages), but because it was nearly the first at many things
and succeeded in integrating those avant garde features.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
*****> Something needs to be said about the evolution of the special form
into a procedure having a different name. As the paragraph stands
in the 3 June draft, it makes no connection between the operators
mentioned in the paragraph and call-with-current-continuation. The
typical reader will wonder why the paragraph is there. The reason
that history is called for in this instance is that the concepts
are completely new to most readers, and they will need help to
appreciate their significance. Someday the rationale will be
unnecessary, but by then the R3RS will be a standard reference
cited by people who want to talk about the history of
continuations.
I favor adding a sentence such as "CALL-WITH-CURRENT-CONTINUATION
is equivalent in power to the 1975 CATCH, but is a procedure rather
than a special syntax."
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
*****> As someone who writes manuals for a mass audience, I find the name
CALL/CC quite distasteful. It was in the RRRS to placate those
who objected to the length of CALL-WITH-CURRENT-CONTINUATION.
This was a political compromise; I suggest we leave the RRRS
wording alone rather than try to achieve a new compromise.
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
*****> In the abstract syntax, say "identifiers (variables)" and
"commands (statements)".
26. FORCE & DELAY are still problematic...
*****> I don't care.
27. Is 3.0.2 (description of procedure calls) a good place to take note that
() is not a valid procedure call?
*****> Ok with me.
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
*****> Yes. Dan points out that the semantics of "variable" is highly
variable, but we have an advantage over most authors in that people
can turn to the formal syntax and semantics if they want to know
what's really going on. Section 2.0 is a pretty good informal
description. I think people can deal with a few loaded terms
in an overview like section 0.0.
29. There are two nonterminals in the BNF that need names. Currently they
are called <formals> and <formalz> which was never intended to be a
serious suggestion (I put it there to see if anyone would actually read
the BNF!). Actually one or both of these can go away if NAMED-LAMBDA
and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes
these things take a look at the BNF and suggest names for these?
*****> I hope NAMED-LAMBDA and the complicated DEFINE syntax depart from
the report, but even if they do we still have to deal with <formalz>
in the (DEFINE (FOO . X) ...) syntax; perhaps the possibilities
could be expanded in-line.
30. Someone wanted me to avoid discussion of immutable objects in the
discussion of operational equivalence in the 2nd paragraph before entry
for EQV? . I want to mention immutability there because I think it's
important to warn users that this might be the case, otherwise they can
easily end up writing unportable code.
*****> In my opinion, the paragraph in question is too little to deal
with the problem. It uses "immutable" without explaining what
it means; worse, it appears that the typical reader is supposed
to know as a matter of course that "mutation procedures" (whatever
they are) can't be applied to immutable objects. As to which
objects are immutable, all we have is the suggestion that objects
returned by literal expressions may be immutable.
I believe the paragraph at the end of 3.0.1 is sufficient. The
report is a definition, not a tutorial.
-----
DISPLAY writes characters like WRITE-CHAR does.
*****> I assume it's ok for an implementation that represents characters as
imaginary numbers to have (DISPLAY #\a) print "-97i"?
Peace, Will
∂02-Jul-86 0515 @MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86 05:15:44 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86 08:14:17 EDT
Date: 2 Jul 1986 08:13-EDT
Sender: JMILLER@MIT-OZ
Subject: Re: Remaining questions & remarks (2)
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: Bartley%ti-csl.csnet@CSNET-RELAY
Cc: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 2-Jul-86 08:13:05.JMILLER>
In-Reply-To: <12218999275.23.BARTLEY@CSC60>
I suggest the name APPLICABLE? instead of PROCEDURE?. I
personally do not regard continuations as procedures, but I
completely understand and empathize with people on the other
side. I think the notion of applicable is a legitimate
generalization and probably would solve Bill's portable printer
problem just as well.
--Jim
∂02-Jul-86 0557 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Call-with-current-continuation
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86 05:57:07 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 2 Jul 86 08:54:07 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA16445; Wed, 2 Jul 86 08:55:09 EDT
Posted-Date: Wed, 2 Jul 86 08:56:47 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA03112; Wed, 2 Jul 86 08:56:47 edt
Date: Wed, 2 Jul 86 08:56:47 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607021256.AA03112@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Call-with-current-continuation
I told a white lie. My worry about the way continuations are
perceived was generated from opinions expressed by a knowledgeable
computer scientist from Harvard, not by myself. This person showed a
good understanding of continuations, but worried about the runtime
overhead incurred even when continuations are used to express control
patterns that can be implemented using constant space (or a stack).
Agreeing with Kent, I cannot think of any way to promise something
about the execution of certain simple uses of continuations. I guess
we should leave the topic of how to use continuations to another
document.
We've heard reviews of r3rs from knowledgeable users of Scheme, has
anyone received an opinion of the document from a reader that is
representative of the general programming language community?
John
PS. Sorry about being sloppy about T's continuations. T of 1981
restricted continuations to those that allowed stack allocation of
control structure. You could not return from a continuation twice or
pass a continuation out of its defining environment. Thus, a more
correct statement is that CATCH and call of a T continuation was
syntax for stack-based continuations. In the interpreter, CATCH was
expanded to a lambda expression and a call to a procedure like
call-with-current-continuation, but the same restriction on the
continuations applied.
∂02-Jul-86 1652 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86 16:51:54 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86 19:49:14 EDT
Date: Wed, 2 Jul 86 19:50:46 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Remaining questions & remarks (2)
To: JMiller@OZ.AI.MIT.EDU
cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA,
RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 2 Jul 1986 08:13-EDT from JMILLER at MIT-OZ
Message-ID: <[AI.AI.MIT.EDU].64955.860702.JAR>
Date: 2 Jul 1986 08:13-EDT
From: JMILLER at MIT-OZ
I suggest the name APPLICABLE? instead of PROCEDURE?. I
personally do not regard continuations as procedures, but I
completely understand and empathize with people on the other
side. I think the notion of applicable is a legitimate
generalization and probably would solve Bill's portable printer
problem just as well.
It never occurred to me that the two words could mean anything
different. Certainly whatever the name is, the predicate would return
true of all applicable things, including CAR, things created by
CALL-WITH-CURRENT-CONTINUATION, and values of LAMBDA-expressions.
If the term for this kind of object changes, then the word "procedure"
must be replaced by "applicable object" throughout the entire report. The
term "procedure," which everyone has been so careful to use so far, would
become useless for any purpose I can think of, e.g. describing the
domains of procedures. That would be unfortunate.
∂07-Jul-86 0929 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU CL Compatiblity Package
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jul 86 09:29:21 PDT
Received: from A.ISI.EDU by MC.LCS.MIT.EDU 7 Jul 86 12:24:30 EDT
Date: 7 Jul 1986 12:23-EDT
Sender: VERACSD@A.ISI.EDU
Subject: CL Compatiblity Package
From: VERACSD@A.ISI.EDU
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-86 12:23:31.VERACSD>
Does anyone have a CommonLisp compatiblity package for Scheme
that they are willing to share? I have developed a rudimentary
package for MacScheme, but am interested in something more
complete.
-- Cris Kobryn
∂07-Jul-86 1254 @MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA votes and things
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jul 86 12:53:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Jul 86 15:51:53 EDT
Received: from indiana by csnet-relay.csnet id ai12245; 7 Jul 86 15:44 EDT
Date: Mon, 7 Jul 86 12:50:06 est
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: votes and things
Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA
The 3 in R↑3RALS is clever, but it looks just like a footnote
reference when the Report is cited. Such puns hurt others more than
they entertain us. How about just "Report on the Algorithmic
Language Scheme". That's different enough from all the previous
report names to avoid confusion, and brevity is a particular virtue
in things, such as titles, that are refered to repeatedly.
I strongly second John Ramsdell's comments about the introduction.
If not religated to the end, the historical material should at least
be in a seperate section following the introduction. I also agree
with him that call-with-{input,output}-PORT is better than ...-FILE
now that we have the ...-PORT? predicates.
I've used the words KEYWORD and IDENTIFIER for what Jonathan is
calling IDENTIFIER and VARIABLE, respectively. I agree with Dan that
VARIABLE is confusing, because it is often used to mean LOCATION.
But I don't feel strongly. However, it is best not to have one word
for both: if you ever mean "keyword and identifier" (or "identifier
and variable"), and not just "symbol", then say so.
My votes follow (I care most about the first and last):
1. (a) leave BEGIN alone
2. (b) flush <?, et al.
3. (b) flush REC (sigh) and NAMED-LAMBDA
4. flush SUBSTRING-MOVE-...
5. flush parallelism references, keep random order
6. (a) inexact like CL "floatness"
7. yes, objects (even ports) should never change type, or there will
be some big surprises.
8. flush MAGNITUDE
9. change ANGLE to PHASE
10. keep two-argument ATAN
11. add PROCEDURE?. For pedagogy I like to maintain a distinction
between primitives, closures (LAMBDA expression values) and reified
continuations, and I use "procedure" to refer to any applicable object.
The programmer shouldn't be able to tell the difference, so the language
should only support PROCEDURE?.
12. (c) Flush one armed IF, and replace by WHEN, as suggested by Kent
and Dan.
13. flush (define ((a b) c) ...)
14. keep LOAD as is
15. treat page breaks and tabs as whitespace, and say no more
17. EQ?, EQV? and EQUAL? should increase in strength monotonically,
as David suggested.
18. keep Clinger's accuracy wrt variables
19. Do we really need a dedication? If so, Strachey is more appropriate
than the PDP-6, Curry is better, and Church seems best.
20. SASL
21. one-based section numbering
22. Landin and Reynolds should be credited with introducing
first-class closures and continuations, but it should be emphasized
that Scheme was the first widely used language to support them and is
still the most used language that supports both.
23. note the difference between CATCH and continuations somewhere
24. CALL/CC should be listed under CALL-WITH-CURRENT-CONTINUATION as
an (optional) procedure. It should be mentioned in the following
discussion that it is an equivalent abbreviation, with no other
apology offered. Dispite objections to it by some, it is more widely
used and refered to than some other things that we have kept by way
of compromise.
Regards,
Chris Haynes
∂08-Jul-86 0538 @MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA display and write-char
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jul 86 05:38:31 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Jul 86 08:37:47 EDT
Received: from indiana by csnet-relay.csnet id ac19489; 8 Jul 86 8:37 EDT
Date: Tue, 8 Jul 86 01:17:19 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: display and write-char
Cc: rrrs-authors@MC.LCS.MIT.EDU
DISPLAY writes characters like WRITE-CHAR does.
It seems to me that this only works if the character type is
distinct from other types. I would not want display to print
an integer that happens to be a character (assuming integers
are used to represent characters) as the character value
instead of the expected sequence of numerals.
For example, if the character #\A is equivalent to the integer
65, then it seems that either
1) (write-char #\A) prints A and (display 65) prints A, or
2) (display 65) prints 65 and (write-char #\A) prints 65.
I think the original intent was that (write-char #\A) print A
and (display 65) print 65, even if #\A and 65 are the same.
Am I missing something?
Kent
∂08-Jul-86 2347 @MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jul 86 23:47:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 9 Jul 86 02:46:51 EDT
Received: from northeastern by csnet-relay.csnet id af28296; 9 Jul 86 2:44 EDT
Date: Tue, 8 Jul 86 13:43 EST
From: MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: remaining questions & remarks (2)
My comments on the "remaining questions" and a few other things:
I. I second Chris Haynes's comments on the title "R↑3RS..". It is not only
too cutesy, but also suggests an aura of impermanence: these guys are going
to keep going until....
II. Kent Dybvig should be an author, on the same basis as Kent Pitman.
Comments on the numbered issues:
1. (a) leave BEGIN essential, SEQUENCE optional.
2. (b) flush <?, etc.
3. (b) flush both REC and NAMED-LAMBDA. I feel very uneasy, however, about
the overall status of special forms, both system- and user-supplied. I will
be very unhappy if I can't have a conforming Scheme that happens to have a
REC. I suspect that this situation merely reflects our lack of understanding
of this issue.
5. Flush the possibility of parallel or interleaved argument evaluation.
7. Yes, a port must be a port forever, else what's an object for?
9. Sure, use PHASE (suppress gratuitous incompatibilities)
10. Keep 2-arg ATAN.
11. Include PROCEDURE?, and make it be true of continuations. I would also be
happy with the name APPLICABLE?, though I prefer PROCEDURE?. I strongly
oppose the name CLOSURE? .
12. (a) 2-argument IF should return the value of the 2nd arg if the first is
true. (when pred exp) is OK too.
13. Flush (define ((((a b) c) d) e) ...)
18. DEFINITELY keep Clinger's description of variable binding. It's the only
hope of sanity. As Dan pointed out, Scheme is closer to Algol than it is to a
functional language, and that's a good bit of why it's useful.
19. I vote for Chris Strachey. Church was still alive the last time I looked.
Curry was the one who died, but he had not thought much, so far as I know,
about the computational implications of his work (even though he did some
numerical analysis on the ENIAC in 1944-46, see Seldin & Hindley, "To H.B.
Curry..." 1980, p. x). I think Strachey's work, as amplified and expounded
through Scott, Stoy, Milne, etc., is a far more direct intellectual source of
our work (as expounded through Scheme) [the "our" here meaning the Scheme
community, not just me.].
20. For call-by-name, how about Algol? "This is distinct from the situation in
languages such as SASL or Algol 60, where arguments are passed by name, so
that an argument expression is not evaluated unless its value is needed by the
procedure". This sentence needs to be careful not to confuse call-by-name
with call-by-lazy or other similar things.
21. I vote for one-based section numbering. I think zero-basing is cutesy.
Also, if we are going to copy the Algol 60 typography, then sub*section
numbers should always be terminated by a period e.g.,
4.5.3.1. If statement. .... (Algol report, page 10).
23. I vote to keep the historical note about CATCH being provided by a
procedure, since Scheme IS (so far as I know) the first language to do this.
Mitch Wand
∂09-Jul-86 0340 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU mitch wand's comments
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Jul 86 03:40:15 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUL 86 06:39:47 EDT
Date: Wed, 9 Jul 1986 06:37 EDT
Message-ID: <HAL.12221269278.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: mitch wand's comments
In-reply-to: Msg of 8 Jul 1986 14:43-EDT from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
I second the vote for Strachey
∂10-Jul-86 1015 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 09:08:00 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86 12:07:13 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3966; Thu 10-Jul-86 12:08:18-EDT
Date: Thu, 10 Jul 86 12:09 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: number syntax
To: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
cc: rrrs-authors@MIT-MC.ARPA
Message-ID: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: Tue 17 Jun 86 16:00:31-CDT
From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
To: RRRS-Authors%mit-mc at CSNET-RELAY.ARPA
cc: Bartley%ti-csl.csnet at CSNET-RELAY.ARPA
Re: Number syntax
Message-Id: <12215615581.31.BARTLEY@CSC60>
One irritant in the Report that we have neglected to comment on until
now (sorry!) is the syntax of numbers. We believe that Scheme numbers
are essentially equivalent to Common Lisp numbers except for the new
notion of exactness. To the extent that that is so, it seems to be a
(shudder!) ``gratuitous difference'' from Common Lisp to have an
incompatible syntax.
The R↑3RS doesn't make clear which subset of the syntax of numbers is
essential and what is optional. As implementors of systems in which
Scheme and Common Lisp must co-exist, we're faced with two potential
compatibility issues: (1) going with an ``extended subset'' of the
Report's number syntax that is compatible with Common Lisp, or (2)
going with the full number syntax in the Report to be compatible with
all other Scheme implementations.
What we'd like to see is an essential syntax for numbers which is
compatible with Common Lisp's. Additional features, including
exactness, would be optional extensions. Even so, they should not
conflict with Common Lisp. For example, the use of `#s' and the order
of <sign> and <prefix> are different in the two languages.
Our motivation, of course, is that we'd like programmers to feel free to
use either language and exchange files of data without irritating
obstacles being thrown in their path. If we can't agree on a
consistent syntax for numbers, then we'll have to provide each language
with two readers and the user will have to know which one to use.
(There are other problems, of course, such as whether `:' is a
constituent of an identifier or associated with Common Lisp package
designations. We may have to go with separate readers/modes anyway.)
Does anyone agree with us? Is there time to make such a change before
R↑3RS goes to press?
I think everyone agrees with you, and that there is time. Could you
please write a concrete proposal, preferably something close to being
suitable for inclusion in the report. Also please provide BNF. Thanks.
Jonathan
∂10-Jul-86 1016 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU call-with-*put-file --> call-with-*put-port
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 09:58:39 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86 12:58:04 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3969; Thu 10-Jul-86 12:59:10-EDT
Date: Thu, 10 Jul 86 13:00 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: call-with-*put-file --> call-with-*put-port
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860710130002.6.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: Fri, 27 Jun 86 11:37:13 edt
From: ramsdell%linus at mitre-bedford.ARPA
To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
Re: r3rs presentation
[pg. 29] If call-with-current-continuation calls its argument with
the current continuation, should the I/O routines call-with-input-file
and call-with-output-file be renamed call-with-input-port and
call-with-output-port?
I think this is a good idea. Does anyone object?
Jonathan
∂10-Jul-86 1228 @MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU How big would a "minimal" scheme interpreter be?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 12:28:21 PDT
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT
Date: Thu 10 Jul 86 15:22:04-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: How big would a "minimal" scheme interpreter be?
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU>
Where minimal means just the interpreter no heap etc.
Michael
-------
∂10-Jul-86 1300 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA My comments on the R↑RS
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 12:56:30 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:38:51 EDT
Date: Thu, 10 Jul 86 12:39:26 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: jar%mit-mc@ads.arpa
Subject: My comments on the R↑RS
Cc: rrrs-authors%mit-mc@ads.arpa
Jonathan,
I've enclosed my comments on the R↑3RS in this note
separately from my answers to your specific questions you asked.
Hope this helps. By the way, I know that putting this all together
involves a lot of work (and sometimes a lot of refereeing), and you
should be aware that your contribution isn't going unappreciated. Thanks
for all the hard work you're putting in, and my apologies in advance
if I err here due to an insufficiently detailed reading of the report.
asc
------------------------------------------------------------------------
1. I am concerned that we have multiple conflicting goals in the
design of the document. Sometimes it is a reference manual,
and sometimes it is a technical report, and sometimes it is a
users' guide. Perhaps we must live with this if there is to
be only one report, but it might be a good idea to try to
separate out (say) the history from the reference manual parts.
This is reflected in the discussions about moving or removing
the history section, for example.
2. As you might expect, I would like to see a somewhat more vigilant
attitude in warding off the dark forces of Common Lisp. It is not
compatibilities or incompatibilities that are gratuitous; it is
the very act of being concerned with compatibility at all that is
gratuitous. We should have our own standards of what a good LISP
looks like and stick to them. The first job of a good language is
to be a good language, not to be just like another bad language
that's familiar (nor even just like another good language that's
familiar). Common Lisp's goals were nearly the opposite of
Scheme's, and however good a job the CL committee did, we owe them
no homage. I recognize that this is more an issue of the design
of Scheme than of its documentation in a report, but there seems
to me to be entirely too much concern for similarities and
dissimilarities w.r.t. Common Lisp in the report. It may be
appropriate to discuss the topic of Scheme vs. CL briefly in the
historical section, but there should be a very clear message to the
reader that CL followed Scheme -- and continues to, in the sense
that Scheme is meant to be a progressive attempt at (LISP) language
design rather than a codification and standardization of existing
ideas in prior LISPs. The CL people should be writing reports
that compare their work to ours, not the other way around. ``Let
them eat cake.'' [OK, flame off.]
3. On p.2 you list me as a Brandeis participant. Would that it were
true. I will leave to your judgement whether I should be listed
in the acknowledgements, as an author, or otherwise.
4. I agree with both your observations on the Syntax section (0.1)
-- that it makes sense to have one there and that it isn't clear
what it should say. Perhaps a fairly terse or brief description of
Scheme's simple syntax would do, e.g.
The syntax of Scheme, like that of most LISPs, provides
for great expressive power, largely due to its simplicity.
An important consequence of this simplicity is the
susceptibility of Scheme programs and data to uniform
treatment by other Scheme programs. As with other LISPs,
the ``read'' function actually parses its input; that is, it
performs syntactic as well as lexical decomposition of what
it reads, rendering input in a uniform internal representation
and making it particularly easy to manipulate Scheme programs
and data in a correspondingly direct and uniform fashion.
Scheme employs a parenthesized-list Polish notation to
describe programs and (other) data, with lists recursively
defined as being composed of lists and what are
sometimes referred to as ``atomic'' objects (numbers,
symbols, etc.) \foot{Unlike most LISPs, Scheme does not
explicitly provide a predicate for assessing atomicity,
although it does contain predicates for determining whether an
object is a list, symbol, number, etc.} The syntax of Scheme
expressions is described formally in greater detail later in
this report.
5. Identifiers & keywords: Sections 1.0 and 2.0 gave me pause,
because I have been concerned for some time with the keyword
problem in Scheme (and I admit to being dissatisfied with the
most common solution). The statement
``Any identifier which is not a syntactic keyword may be
used as a variable....''
which appears in both sections implies that there are keywords in
the language, although (a) there aren't guaranteed to be and (b)
you haven't said anything previously about keywords in the
document. The astute reader will then turn to the index to find
out what she has missed, only to discover that there is no entry
at all for keywords. Later on there is a discussion of keywords,
but it is essentially an afterthought, and by now the reader may
have decided that Scheme really is Pascal after all (Andrew, bite
your tongue). Something needs to be done to clear up the
potential confusion from the initial presentation of identifiers
vs. keywords. The inline "Note:" on p.6 probably does not serve
to clarify things as much as it might.
6. P. 6, SS 2.0: Yes, mention that there are no guarantees that a
``top-level'' exists. (Then encourage the rest of the RRRRS
authors read that paragraph....)
7. SS 2.1, p.6 implies that there are other values besides #f that
count as false. Except for the optional #!false, I'm not sure I
see what these are. Perhaps you count things like (NOT #T) as
false for the purposes of this section?
8. p. 7, SS3.0.2 -- Typo at bottom of page, ``combinations. .''
9. p.7 SS 3.0.2: It may not be clear to non-LISPophiles what
``+`` evals to, or why ``+'' gets evaluated in the example
(+ 3 4) => 7
((if #f + *) 3 4) => 12
The idea of a function name evaluating to a functional object
will not be intuitive for most readers, who probably think in
languages that don't have first-class procedures. Perhaps
something can be done to make this clearer.
10. There are a few minor report points that reflect major
underlying problems we really have yet to solve in the design
of Scheme, involving things like COND, IF, and perhaps LET. The
syntax definitions provided earlier on in the report make (COND ((X)))
a legal expression, and we've already had the n-armed IF argument.
Similarly, (LET () (DOSOMETHING)) is legal, although perverse and
not obviously useful. (The latter expression actually appears in
the report, at the top of p.10 col2, although I can see no reason
to have used it -- the example would have worked fine without it.)
I think what has happened is that we never resolved the issue of
``functions'' that don't return values. Instead we developed, or
permitted the random evolution of, a hodgepodge of mutually
inconsistent local solutions: DEFINE is not an expression, IF may
(or may not) have an undefined return value, (COND ((X))) returns
(X), etc. We still have design work to do.
11. On a related syntax (or is it design?) point, on p.9, SS3.1.0, the
expression (CASE TEST (() (FOO))) is permitted. It's not clear to me
why we want to permit this, nor what it means if we do. Strictly,
it would always be ignored, in which case it's spurious.
Similarly, (CASE TEST) is legal; strictly it returns <unspecified>
but seems senseless nonetheless.
12. I cannot refrain from observing that DO is truly ugly, a
veritable pig of a construct, and we could have done better.
We are indeed fortunate that its use under practical circumstances
is rarely necessary.
13. The Note: on p.11 about DO in which you describe assignment vs.
rebinding is guaranteed to be lost on the majority of readers.
An example of how it differs from other LISPs' DO might help.
14. On p.12 where QUASIQUOTE is introduced, as a purely typographic
observation, we really need a better backquote character. It's
very hard to read the character at all in the copy of the report
I have, especially at that point size. At first glance I thought
in all honesty that it was a speck of ink on my copy. (I believe
my hardcopy came from MIT, although its route was sufficiently
mysterious that it might have been printed at Berkeley instead.)
15. SS 4.0 talk about the ``top level,'' as if there is one; cf. my
point #6 above.
16. SS 4.1, p.12, first sentence: I find this ambiguous:
Definitions are not valid in all contexts where expressions
are allowed; they are only valid at the top level [sic] of
a <program> and at the beginning of a lambda body.
This could mean any of several things, e.g.:
Definitions are invalid in all contexts where expressions are
allowed (i.e. there are no contexts in which definitions are
valid where expressions are allowed)....
or
Definitions are invalid in some contexts where expressions
are allowed (i.e. there exist contexts where expressions are
allowed but wherein definitions are not allowed)....
This probably needs to be rephrased for people who don't already
know what it's trying to say.
17. Top of p.13 col1: You have ``(. <variable>) would be understood
to mean simply <variable>.'' Why permit this? It offers no
additional functionality and strikes me as an unclean misfeature.
18. p.14, SS 5.1: Misspelling, ``distint'' => ``distinct''.
19. p.17, SS5.2: Misspelling, ``decsription'' => ``description''.
20. Predicates: As far as I could see, we never actually commit to
putting ``?'' at the end of predicates, although we do
mention on p.18 that functions like ASSV don't end in ``?''
because they aren't predicates. This convention would be a good
thing to assert. (It also would blow the people who dislike >?
out of the water, I'm afraid.)
21. p. 18, SS 5.3, First sentence: ``entirely'' is massive
overstatement here. There are lots of bases for the utility of
symbols -- like their use as printable undoublequoted objects, which
seems to me to have been lost almost entirely [sic] on the
Scheme community (hence the rejection of upper/lower case
distinction). (Incidentally, CommonLisp also gets control of
UC/LC terribly wrong, to my eternal annoyance when I build
distributed multiprocessing mostly-LISP-based systems that want
to communicate by passing case-varying symbol tokens instead of
strings.)
22. p.28, SS 5.8: What happened to TeX in the middle of column 2
where it says ``The escape procedure''? Misplaced manual
linebreak, perhaps.
23. NOTES, p.35ff.: This material should stay somehow. We need to
make it clear that R↑3 Scheme is not being touted as Yet Another
Ultimate Solution To The Programming Language Problem, but rather
as a snapshot of a *process* of good design, for which not all
answers have yet been found. We also ought to use the opportunity
for publicity afforded us by SIGPLAN to advertise some of the thorny
unsolved problems that need further research, and encourage
language designers to work on them.
-------------------------------------------------------------------------
∂10-Jul-86 1313 @MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 13:13:16 PDT
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:59:39 EDT
Date: Thu 10 Jul 86 15:58:42-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221633641.27.MICHAEL@CS.COLUMBIA.EDU>
Return-Path: <@MC.LCS.MIT.EDU:Network←Server@MIT-MULTICS.ARPA>
Received: from MC.LCS.MIT.EDU by CS.COLUMBIA.EDU with TCP; Thu 10 Jul 86 15:53:57-EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:28:35 EDT
Received: from MC.LCS.MIT.EDU by MIT-MULTICS.ARPA TCP; 10-Jul-1986 15:28:06-edt
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT
Date: Thu 10 Jul 86 15:22:04-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: How big would a "minimal" scheme interpreter be?
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU>
Where minimal means just the interpreter no heap etc.
Michael
-------
-------
∂10-Jul-86 1342 @MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 13:42:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jul 86 16:09:15 EDT
Received: from indiana by csnet-relay.csnet id ah09559; 10 Jul 86 15:54 EDT
Date: Thu, 10 Jul 86 14:06:35 est
From: Perry Wagle <wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: Re: Remaining questions & remarks (2)
Cc: wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA
(2) <, >, etc are composed solely of "special symbols", and classically are
predicates. With this view in mind, perhaps the exception is not so big
as naive application of Occam's Razor would suggest. I support essential
<, >, etc, and the removal of their "xxx?" counterparts.
(5) Many otherwise portable Scheme programs would die under unrestrained
interleaving. I claim that a Scheme should have the semantics of a
single logical processor no matter what the underlying architecture is.
I think that mention of parallelism should be left out altogether, as
any mention would call for ad hoc measures (synchronization primitives?
bleagh!), and restraint to a "single logical processor" is probably an
obituary (within ten years or so?).
(7) I would like to guard input and output commands with INPUT-PORT? and
OUTPUT-PORT? respectively. I think closed ports SHOULD be ports, but
not input or output ports; I support the predicate: PORT?.
(11) I would very much like PROCEDURE? and consider continuation objects
to be procedures. While appealing, I don't support APPLICABLE? as it
would be the only type predicate that doesn't name the type its checking
for.
(12) I oppose one-armed IFs. I've been happy with WHEN and UNLESS that
return NIL when the condition isn't met.
(14) I have "meta"-procedures that invoke LOAD. I *demand* that you not cut
my arms and legs off for "esthetic reasons".
(15) I think that *all* ASCII characters should be "legibly typable" (e.g.
#\null, etc), but then I only run on ASCII machines.
∂10-Jul-86 1540 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA My answers to your thirty questions on R↑RS
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 15:35:50 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 18:30:06 EDT
Date: Thu, 10 Jul 86 15:31:12 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: jar%mit-mc@ads.arpa
Subject: My answers to your thirty questions on R↑RS
Cc: rrrs-authors%mit-mc@ads.arpa
Jonathan,
Here is my list of answers to the specific report-related questions
you posed to the group. I've only answered the ones I have strong
opinion on.
1. The presence of BEGIN in Scheme is frankly somewhat of an
embarrasment. It really should be flushed, but politically
it's probably too late. Still, I vote (b).
2. Keep the >? forms. All predicates should end in ? for
uniformity. This kind of consistency is much more important for
pedagogical purposes than is similarity to CL, Pascal, or any
other existing language.
4. Substring-move-*: flush. I think I have simple Scheme definitions
for these, if anyone needs them once they're flushed.
5. Simply make it clear that evaluation order is unspecified (and
should not be depended on); to guarantee sequential evaluation
of a collection of combinations, use SEQUENCE.
7. Port = port. Safer that way.
11. Yes, PROCEDURE? would be welcome.
12. (if x 1) vs. (cond ((x 1)): I suggest
(if x 1) => 1 iff x, else <unspecified>
(cond ((x 1))) => 1 iff x, else <unspecified>
(case (not (not x)) ((#t) 1)) => 1 iff x, else <unspecified>
This follows the general principle that if you fall off the end
of a control construct, the results are not guaranteed. If you
want a guaranteed return value in your program, you specify one
using ELSE or the two-armed IF as appropriate; that's what they're
there for. This should be phrased to say that ``it is an error''
to rely on the result of a control construct that returns an
<unspecified> result.
13. Flush (define ((((a b) c) d) e) ...) syntax.
14. To me, INCLUDE means "include." If we want the effect to be
equivalent to having the loaded text be lexically present,
INCLUDE is an excellent name, and helps avoid some of the
concerns people have had about what it means to have a dynamic
programming environment for a lexically scoped language. I would,
however, want to see a resolution to such problems as
(IF X (INCLUDE "FOO"))
If this evaluation depends on the dynamics of the binding
environment, then "LOAD" is more appropriate. INCLUDE would
have to be a non-expression statement, e.g. the above example
would only be syntactically correct if "FOO" happened to contain
exactly one or two expressions at the top level of the file, and
the INCLUDE would always get performed regardless of X's value.
21. One-based sections.
24. I guess some people don't like to type and have bad editors, or
maybe bad pretty-printers. CALL/CC is scarcely an intuitive
name; its chief virtue seems to be the number of characters it
contains. But it seems to be regionally entrenched; keep it
"informally optional" to the standard CALL-WITH-CURRENT-CONTINUATION
if necessary. (It will not appear in our Scheme implementations.)
26. FORCE and DELAY are new ideas to most readers of the report, at
least for its SIGPLAN incarnation. Good pedagogy suggests they
be put together if possible.
27. Yes for () in 3.0.2.
30. I thought the question of immutable objects was lightly treated
overall. Rather than remove the reference on p. 14 SS 5.1, I'd
prefer to see more detail, and perhaps (a) something explicitly
noting that set-car! and set-cdr! are destructors (or
mutators if you prefer) and (b) the explicit assertion that
destructors end in ``!'' in Scheme.
------------------------------------------------------------------------
Other topics:
-1+ : I prefer to see this kept, in inessential status. When I first
saw it, it struck me as the first time any LISP had gotten this
right. It says exactly what it means. Better no decrement
function at all, however, than using "1-" to mean decrement; "1-"
says exaactly what it *doesn't* mean.
Since there was a complaint, I might suggest ``minus one plus''
as the pronunciation for "-1+", as in "minus one plus 3" for
(-1+ 3) (or "negative one plus three," if you prefer). I
scarcely find SUCC pronounceable in any socially acceptable way,
and it certainly doesn't seem to me to be a serious alternative.
WHEN: This probably seems like a good idea to people who don't do
concurrent programming. When you deal with time in your
programs, ``when'' already has a confusing enough meaning without
overloading it to mean IF. For that matter, a couple years from
now we may want to use WHEN for event management.
S&ICP: I do not know what it means to (as one person admonished)
``fix the book''; in particular, I don't know how you recall
thousands of copies. Independent of the quality of the
presentation and choices reflected in S&ICP, which I admit to
admiring tremendously, I believe that this book has done
more for Scheme than any other single force in Scheme's history,
and I believe we should endeavor to support a Scheme compatible
with it. Most of my colleages who own the book have it because
they were interested in obtaining a good book on LISP or a good
book on programming, and to a person every one with whom I've
spoken agrees that it is probably the best available for both
purposes. Let's not kill the goose that lays our golden eggs.
∂10-Jul-86 1941 @MC.LCS.MIT.EDU:whill%hplabsc@hplabs.HP.COM Re: [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 19:41:01 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 10 Jul 86 22:35:05 EDT
Received: from hplabsc by hplabs.HP.COM ; Thu, 10 Jul 86 19:32:17 pdt
Received: by hplabsc ; Thu, 10 Jul 86 19:33:39 pdt
Date: Thu, 10 Jul 86 19:33:39 pdt
From: Walt Hill <whill%hplabsc@hplabs.HP.COM>
Message-Id: <8607110233.AA15511@hplabsc>
To: MICHAEL@CS.COLUMBIA.EDU, scheme@MC.LCS.MIT.EDU
Subject: Re: [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
MIT CScheme will run on an HP Integral PC with 1.5Meg RAM with room for only
40K items in the heap.
Walt Hill
∂11-Jul-86 0336 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU MacScheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 03:36:43 PDT
Received: from MEDIA-LAB.MIT.EDU by MC.LCS.MIT.EDU 11 Jul 86 06:31:52 EDT
Received: by MEDIA-LAB.MIT.EDU (5.31/4.8) id AA06695; Fri, 11 Jul 86 06:31:17 EDT
Date: Fri, 11 Jul 86 06:31:17 EDT
From: William H Coderre <bc@MEDIA-LAB.MIT.EDU>
Message-Id: <8607111031.AA06695@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: MacScheme
Can someone summarize the MacScheme situation?
I've played briefly with a fairly old version.
I heard there was a new version.
Graphics? Toolbox? Editor (I remember it being a loser)?
Compatibility?
Thank You
"Tzima Narki"......................,...........,.............bc
∂11-Jul-86 0925 @MC.LCS.MIT.EDU:gls@Think.COM My comments on the R↑RS
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 09:25:24 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 12:21:28 EDT
Received: from botolph by Godot.Think.COM via CHAOS; Fri, 11 Jul 86 12:18:24 edt
Date: Fri, 11 Jul 86 12:19 EDT
From: Guy Steele <gls@Think.COM>
Subject: My comments on the R↑RS
To: andy@sun3.ads.ARPA, jar%mit-mc@ads.ARPA
Cc: rrrs-authors%mit-mc@ads.ARPA, gls@AQUINAS.ARPA
In-Reply-To: <8607101959.AA12928@Zarathustra.Think.COM>
Message-Id: <860711121914.1.GLS@BOTOLPH.THINK.COM>
Date: Thu, 10 Jul 86 12:39:26 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
Jonathan,
I've enclosed my comments on the R↑3RS in this note
separately from my answers to your specific questions you asked.
Hope this helps. By the way, I know that putting this all together
involves a lot of work (and sometimes a lot of refereeing), and you
should be aware that your contribution isn't going unappreciated. Thanks
for all the hard work you're putting in, and my apologies in advance
if I err here due to an insufficiently detailed reading of the report.
Hear, hear!
...
2. As you might expect, I would like to see a somewhat more vigilant
attitude in warding off the dark forces of Common Lisp. It is not
compatibilities or incompatibilities that are gratuitous; it is
the very act of being concerned with compatibility at all that is
gratuitous. We should have our own standards of what a good LISP
looks like and stick to them. The first job of a good language is
to be a good language, not to be just like another bad language
that's familiar (nor even just like another good language that's
familiar). Common Lisp's goals were nearly the opposite of
Scheme's, and however good a job the CL committee did, we owe them
no homage. I recognize that this is more an issue of the design
of Scheme than of its documentation in a report, but there seems
to me to be entirely too much concern for similarities and
dissimilarities w.r.t. Common Lisp in the report. It may be
appropriate to discuss the topic of Scheme vs. CL briefly in the
historical section, but there should be a very clear message to the
reader that CL followed Scheme -- and continues to, in the sense
that Scheme is meant to be a progressive attempt at (LISP) language
design rather than a codification and standardization of existing
ideas in prior LISPs. The CL people should be writing reports
that compare their work to ours, not the other way around. ``Let
them eat cake.'' [OK, flame off.]
[a] I think that many papers on Common Lisp have correctly attributed its
debt to Scheme.
[b] I disagree that concern with compatibility is gratuitous. Perhaps that
concern should be subordinate to other concerns, but when everything else is
truly equal then compatibility is a reasonable criterion for breaking ties.
This is because it is better to be able to tie a feature to something already
familiar than to make a user learn something new.
[c] There should be a very clear message to the reader that Scheme certainly
does owe debts to other sources, and one of them is Common Lisp. While
Scheme certainly has been the pioneer in the treatment of closures and
functional programming in a Lisp framework, I think it is fair to say that
Common lisp pioneered a rational (forgive the pun) treatment of numeric data
types in a Lisp framework, and my impression is that Scheme learned
something in this area from the Common Lisp experience.
[d] Don't forget that there are some people who worked on both Scheme and
Common Lisp at the same time (I do not count myself as one, by the way), to
whom I am grateful because they learned certain lessons in both contexts at
once and served to transfer ideas in both directions.
12. I cannot refrain from observing that DO is truly ugly, a
veritable pig of a construct, and we could have done better.
We are indeed fortunate that its use under practical circumstances
is rarely necessary.
I strongly disagree. DO is a construct that emphasizes the notion that
an iteration can proceed by initializing some state variables and then
repeatedly transforming them while maintaining some invariant until
a condition is reached. In particular, it emphasizes the fact that
outputs of the iteration as well as inputs can and should be expressed
as iterator-controlled variables. This is a lesson that the "algebraic"
languages ought to learn. It is an abomination to see
sum = 0
do i = 1 to 10 by 1
sum = sum + a(i)
end do
instead of
do i = 1 to 10 by 1; sum = 0 by a(i); result sum od
23. NOTES, p.35ff.: This material should stay somehow. We need to
make it clear that R↑3 Scheme is not being touted as Yet Another
Ultimate Solution To The Programming Language Problem, but rather
as a snapshot of a *process* of good design, for which not all
answers have yet been found. We also ought to use the opportunity
for publicity afforded us by SIGPLAN to advertise some of the thorny
unsolved problems that need further research, and encourage
language designers to work on them.
Yes.
--Guy
∂11-Jul-86 0935 @MC.LCS.MIT.EDU:cscott@bfly-vax.bbn.com tiny scheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 09:35:10 PDT
Received: from BFLY-VAX.BBN.COM by MC.LCS.MIT.EDU 11 Jul 86 12:26:51 EDT
Date: Fri, 11 Jul 86 12:22:23 EDT
From: "Curtis A. Scott" <cscott@bfly-vax.bbn.com>
To: michael@cs.columbia.edu
cc: scheme@mc.lcs.mit.edu
Subject: tiny scheme
It depends on the level of functionality you desire. A minimal kernel
with only the basic operations as primitives could be very small. I
wrote a student subset kernel in Z80 assembler which was much less
than 32K bytes, and I believe someone did one for the Apple II of
similar size. You have then moved much of the size of the system off
into interpreted code in the heap. None of the "real" systems are
this small; the MIT handcoded 68000 scheme was around 64K of code.
∂11-Jul-86 1142 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: My comments on the R↑RS
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 11:42:36 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 14:42:04 EDT
Received: from ti-csl by csnet-relay.csnet id ab20493; 11 Jul 86 14:24 EDT
Received: by tilde id AA08236; Fri, 11 Jul 86 11:05:52 cdt
Date: Fri 11 Jul 86 10:59:37-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: My comments on the R↑RS
To: andy%sun3.ads@CSNET-RELAY.ARPA, jar%mit-mc%ads@CSNET-RELAY.ARPA
Cc: rrrs-authors%mit-mc%ads@CSNET-RELAY.ARPA,
Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: Message from "Andy Cromarty <andy@sun3.ads.ARPA>" of Fri 11 Jul 86 04:08:40-CDT
Message-Id: <12221852261.67.BARTLEY@CSC60>
>Date: Thu, 10 Jul 86 12:39:26 PDT
>From: Andy Cromarty <andy@sun3.ads.ARPA>
> [...]
>2. As you might expect, I would like to see a somewhat more vigilant
> attitude in warding off the dark forces of Common Lisp. It is not
> compatibilities or incompatibilities that are gratuitous; it is
> the very act of being concerned with compatibility at all that is
> gratuitous. ...
I feel that this point of view is not in Scheme's best interest. Although
many potential converts to Scheme are unsullied by contact with lesser
lisps, others must either be won away from Common Lisp or must live with
both. Gratuitous differences in syntax and in the naming of standard
procedures make it much more difficult for them to give Scheme a fair
trial. Also, many of us are working on implementations in which Scheme
and Common Lisp programs want to share data and call each other.
Gratuitous differences in the data types and in the syntax of numbers (for
example) can make this very frustrating. I fear that Scheme will usually
be the one that loses if a development team decides the two languages are
not sufficiently compatible.
> ... We should have our own standards of what a good LISP
> looks like and stick to them. The first job of a good language is
> to be a good language, not to be just like another bad language
> that's familiar (nor even just like another good language that's
> familiar). Common Lisp's goals were nearly the opposite of
> Scheme's, and however good a job the CL committee did, we owe them
> no homage. ...
Although a certain amount of compromise is necessary in agreeing on what
is "gratuitous", it certainly is true that any compromise that changed
Scheme from a "good" language to a "bad" one would not be gratuitous.
> ... I recognize that this is more an issue of the design
> of Scheme than of its documentation in a report, but there seems
> to me to be entirely too much concern for similarities and
> dissimilarities w.r.t. Common Lisp in the report. It may be
> appropriate to discuss the topic of Scheme vs. CL briefly in the
> historical section, but there should be a very clear message to the
> reader that CL followed Scheme -- and continues to, in the sense
> that Scheme is meant to be a progressive attempt at (LISP) language
> design rather than a codification and standardization of existing
> ideas in prior LISPs. The CL people should be writing reports
> that compare their work to ours, not the other way around. ``Let
> them eat cake.'' [OK, flame off.]
I think we've all agreed that explicit references to Common Lisp in the
Report should be minimized.
Regards,
David Bartley
-------
∂11-Jul-86 1642 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 16:41:58 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 JUL 86 18:04:12 EDT
Date: Fri, 11 Jul 86 18:04:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: test
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].68642.860711.JAR>
Test message. Please ignore.
∂12-Jul-86 1837 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Compatibility with Common Lisp: A meta comment
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Jul 86 18:37:17 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Jul 86 21:37:07 EDT
Date: 12 Jul 86 1835 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Compatibility with Common Lisp: A meta comment
To: rrrs-authors@MC.LCS.MIT.EDU
Andy Cromarty comments that it is ``the very act of being concerned with
compatibility at all that is gratuitous.''
I regard it as lucky that this message only went to RRRS-authors, because
it represents a low point in political thinking. Although I am not an
active participant in the Scheme design, many of you know that I use
Scheme in my teaching, my research papers, and my research. When put on
the spot regarding the future of Lisp - in any forum - I point to Scheme
as the hope for the future.
However, I regard myself as a member of the Common Lisp community, and I
had a fair amount to do with its design and acceptance. When I read Andy's
message I felt insulted. Perhaps someone less sympathetic to the Scheme
movement would be completely turned away from Scheme by reading his
message.
If Andy wants to battle the dark forces, they are indeed lined up at the
perimeter. To the vast audience, Common Lisp and Scheme are
indistinguishable. The alternative is C. If Lisp cannot make a go of it
because other languages are seen as `better,' there will be less interest
in learning Lisp, and fewer people will be able to see the beauty of
Scheme. The battle is to win people over to `lisp programming,' which in
its best clothes is Scheme programming.
To an outsider, a `gratuitious' difference between Common Lisp and Scheme
is seen as evidence that the Lisp world is too religious to understand
real-world concerns. Unless there is a compelling reason to vary from Common
Lisp, I think compatibility is wise.
The Common Lisp community has learned and is learning a lot about how
people are won over to a new standard, and this community has many members
who are Scheme lovers. Perhaps it is a smart move to avoid alienating
them with comments like Andy's? Perhaps the Scheme community would like to
enlist the aid of the large Common Lisp community in advocating Scheme?
Don't let anyone outside this list see Andy's message.
-rpg-
ps. To be a pissant about it. I guess Andy feels that, because the goals of
Common Lisp were nearly the opposite of Scheme's, the goals of Scheme
are to be:
non-common
non-portable
inconsistent
inexpressive
incompatible
inefficient
not powerful
unstable
Common Lisp's goals were not bad. They were the stated ones, plus several
others: gain support among competing dialects, gain advocates from the
commercial Lisp programming world, and develop compromises among enemies. The
stated goals plus these three are such that we are lucky that the result
is as reasonable as it is.
∂13-Jul-86 1528 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA Scheme's DO construct
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Jul 86 15:28:40 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 13 Jul 86 18:29:06 EDT
Date: Sat, 12 Jul 86 19:07:07 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: rrrs-authors%mit-mc@ads.arpa
Subject: Scheme's DO construct
Cc: andy@ads.arpa, gls%think@ads.arpa
Reply-To: andy@ADS.arpa
Hmm, I seem to have generated some controversy. I'll attempt to
provide clarifications and responses separately on each topic to
help keep the discussions distinct. I'll start with "DO."
------------------------------------------------------------------------
I cannot refrain from observing that DO is truly ugly.... [asc]
I strongly disagree. DO is a construct that emphasizes the
notion that an iteration can proceed by initializing some state
variables and then repeatedly transforming them while maintaining
some invariant until a condition is reached. ... [gls]
I think Guy misguessed the source of my displeasure with DO. So I'll
clarify. (Warning: not a short message.)
I have no prima facie objection to the use of iterative constructs,
and in particular, none to supporting iteration in Scheme. Indeed, I think
that it is often very effective to think procedurally and iteratively rather
than functionally and recursively. (I understand these are apples and
oranges, but the styles are usually associated with each other.)
There may be interesting extremist arguments in favor of relying solely on
recursion for repetition, presumably based on strict minimalism and some
arguments concerning the elegance of recursion. But I probably wouldn't buy
them, and in any case that's not what my complaint is about. If we were going
to be minimalism extremists, we wouldn't provide IF, COND, and CASE in the same
language. Instead, I think we are trying to design an effective programming
environment while remaining "reasonably" elegant. The touchstone for the
appropriate degree of minimalism is that we provide the constructs that
a programmer will need, separating functionality out when the programmer's
abstraction of the control process is different (as opposed to merely the
underlying computation being different; hence CASE, IF, and COND).
So given the assumption that we are going to have one or more iteration
constructs, what should they look like and how should we select them?
My claim is that the DO we are using is a poor choice, and moreover,
that it probably reflects a correspondingly poor choice in selection criteria.
In a nutshell, DO does too much. It creates variables, binds them,
provides iteration, rebinds variables at tactically pleasing times,
tests a conditional expression, applies an implicit SEQUENCE to most
of its arguments, returns the result of evaluating an optionally present
expression... whew!
I submit that we have CommonLisp's DO (which is in use in other LISPS too,
of course) principally because it was being used by other LISPs and no one
really stopped to think what a good iteration construct for Scheme would
look like starting from first principles. We just grabbed what (some) (LISP)
programmers currently are using without treating this as an important
design problem.
I also submit that DO is too complex and that this complexity violates
two fundamental principles of good programming language construct design:
1. Keep constructs simple so people can learn, understand, read, debug,
and maintain them easily.
2. Each function should do one thing, and do it well. (No pun intended.)
Just to take a few pot shots at DO: we don't need variable binding and
creation, since we already have the LET family to do that nicely for us.
We don't need to confuse conditional exit from an iteration (i.e. using
a predicate expression) with FOR-class iteration that occurs, e.g.,
a predictable number of times and/or over a predictable set of values.
Certainly it's nice to have all these things around when you want them;
my point is simply that an iteration construct doesn't need to provide
all of them, that we can make intelligent choices about which ones
a given construct is to provide, and that if DO needs to contain all of
them, then the burden of proof is on those who would make that claim.
To reframe the challenge, the question is not whether you can come up
with times when you need conditional exit, and times when you need
FOR-style iteration, and... etc.; but rather, whether you can convincingly
demonstrate that all are needed in one iteration construct that appears in
the language definition.
Let me pose a few alternatives. Bear in mind that these are strawman
options, for illustrative purposes. If you don't like keywords in your
control constructs, imagine the examples without them.
(FOR i IN <list> DO <forms>) -- Evaluates <forms>, to which an implicit
SEQUENCE is applied, with i bound to successive values of <list>.
[This is like FOR-EACH except that you have the current value bound to
a lexically apparent locally-created locally-bound variable i. This is about
as similar to FOR-EACH as, say, COND and CASE are to each other.]
(VARYING i FROM n TO m BY s DO <forms>) -- Binds i to n, n+s, n+2s, ...
and evaluates <forms>, to which an implicit SEQUENCE is applied, for
each such binding, until i>m. Returns the result of the last evaluation
of <forms>.
[This is the classic FOR-loop construct used when you know the range
of values in advance, e.g. when you are stepping through a vector.]
(REPEAT n TIMES <forms>) -- Evaluates <forms>, to which an implicit
SEQUENCE is applied, n times. Returns the result of the last evaluation
of <forms>.
[Not frequently used, but highly perspicuous on those occasions when
this is exactly what you want to do.]
(WHILE <test> DO <forms>) -- Repeatedly evaluates <forms>, to which an
implicit SEQUENCE is applied, until <test> evaluates to #F, like
Pascal's WHILE.
[There's some interesting research by Jeff Bonar, among others,
with empirical results suggesting that Pascal's WHILE loop is actually
a dangerous, hard-to-learn construct. This is because (a) the classic
phase problem that occurs when you use a WHILE loop in a PROCESS,READ
paradigm is harder to learn than the more intuitive READ,PROCESS model,
and (b) beginners often think that WHILE really means "while," i.e.
"whenever <test> is true, do <forms>" or "the moment <test> would become
false, exit the loop." I also dislike the cooption of this word for this
iterative processing application, since its more intuitive meanings
actually might be useful in concurrent processing applications. In any
case, when not used in a PROCESS,READ paradigm, the construct (whatever
its name) is often quite useful.]
Hmm, that's a lot of extra stuff in a language to take the place of
one DO construct, isn't it? But that's precisely the point. DO is
a microcosm of MacLisp's and, by inheritance, Common Lisp's invasive
featurism. In the extreme, we could create a function F(x) and specify
which entire program we wanted simply by feeding F the proper number.
Many people would regard such a Goedlization of programs as a positive
step, if only they could determine which number to feed F. But: we wouldn't
call it programming; we wouldn't call F a "control construct" in the
sense that we normally use the word; and perhaps most importantly, we
wouldn't know how to meaningfully specify the x. Forgiving the hyperbole,
that is also true of DO: it is an expert's construct with options sticking
out all over and no coherent design principles underneath, hard to learn
and remember and even harder to read and understand quickly on sight.
I have performed the following informal experiment. I had one or
two of the people working with me who were true devotees of LOOP
and DO go back and recode fairly large (5000-15000 lines) LISP programs,
ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping
functions. I should say that they did it "kicking and screaming," not
because of the work involved but because they so loved all the features
that LOOP offered. But a couple weeks later, they came back and said:
"You know, LOOP is really evil!"
"My code is infinitely easier to read and maintain now."
"I had no idea how ugly and impenetrable all that DO and LOOP code was
from all those `features' of DO and LOOP I was using."
"You have to have something seriously wrong with your head to be able to
use DO fluently."
"I'm not going to use LOOP again!"
I should say that the principal guy I have in mind here got his degree at
MIT. We're talking the hardest of sells, and when the dust had cleared,
he came to the conclusion that DO and LOOP are morally reprehensible.
We need to remember that programs are written not only to be executed,
but also to be read; and that well over 50% of programmer time is
spent maintaining existing code. Clear, clean, well-designed control
constructs can go a long way towards easing this burden. DO does not
seem to qualify as such a construct; rather, it seems like the incidental
union of numerous such constructs. We might be able to make a major
contribution to the utility of LISP in "practical" programming applications
by updating Scheme's iteration constructs so they provide better, cleaner,
more direct support for the variety of iteration models that are already
implicit in the code we write.
asc
∂14-Jul-86 0252 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Flaws of form
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 02:52:43 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 05:52:54 EDT
Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA28438; Sun, 13 Jul 86 10:01:39 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA21626; Sun, 13 Jul 86 10:04:09 PDT
Date: Sun, 13 Jul 86 10:04:09 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607131704.AA21626@tekchips.TEK>
Subject: Flaws of form
To: rrrs-authors@MC.LCS.MIT.EDU
I would prefer to see no dedication in preference to making the dedication
serious. I think a serious dedication would read as insincere because
the Scheme report is an obvious parody of the Algol 60 report.
As much for my asusement as for anything else, I wrote this explanation:
The Algol 60 report is gravely earnest. Among its many firsts, Algol was
first to use a grammar-like construct to define its syntax. The first
report -- "Preliminary report - International Algebraic Language" -- as
well as the revision, were published as cover stories in the
@i(Communucations of the ACM) (*). The report was the culmination of an
international effort, followed with international attention. In the style
of world war commentary, the reader learns of the Zurich meeting, the Paris
meeting, and of the seven European representatives who held a final
prepatory meeting in Mainz in December 1959. And let us not forget the
seven American representatives with a similar quest, in Boston that same
year. We are spared the details of the lunch meats; judged, with Ph.D.
precision I am certain, to be expendable from the accounting. In each
re-reading, I look (in vain) for the mention of Teller and Oppenheimer;
surely they were involved too. It is in this intensely sober context that
we read the full page eulogy of William Turanski (**), who died after being
struck by a car the day before the 1960 conference in Paris.
(*) CACM v1 #12, 1958; CACM v6 #1, 1963
(**) CACM v3 #5, 1960, p 298
Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
relatives the ideal names for those procedures? Scheme is as serious as
LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The
names are arbitrary and incidental; CAR and CDR remind us. Scheme is as
much an approach as a detailed concrete specification. But to be taken
seriously, for Scheme to be widely used, we must have the details and
concretions; they are essential but unimportant.
The Algol 60 report is almost ludicrous in its sobriety. If we use the form
of Algol 60 to present happy little Scheme, we cannot avoid the parody;
try as we might.
Still, I think there is good reason to use the form. Presenting Scheme in
the form of the Algol 60 report may capture the attention of those who
clump together and ignore all Lisp-like languages because the culture is so
different from what they know. The contrast with @i(Chine Nual) and
@i(CLtL) is important. Perhaps Lisp can be other than a bag of features of
a metastasizing runtime environment. Perhaps it can even be described in
the style of the day!
Following the model of Algol 60 exactly points out that the form of
description is itself an arbitrary convention; and the point is made in
perfect Scheme style. Just as Scheme can provide the "their" control
constructs, it can be described in "their" form.
The parody pokes fun at all those essential but unimportant details.
It is the perfect couch for Scheme.
So for all this, I find a serious dedication inappropriate. Algol 60's
dedication was grave; to an Algol soldier, killed in his prime (he was 35).
Scheme's dedication should be to something unimportant. "Dedicated to the
memory of dynamic binding.", as Jonathan once suggested, fits well. It
seems to me so much better than to try to be as somber and important as
Algol 60. I think we would look foolish in the attempt.
-Norman
-------
∂14-Jul-86 0325 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Flaws of form
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 03:24:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 06:25:26 EDT
Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA28438; Sun, 13 Jul 86 10:01:39 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA21626; Sun, 13 Jul 86 10:04:09 PDT
Date: Sun, 13 Jul 86 10:04:09 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607131704.AA21626@tekchips.TEK>
Subject: Flaws of form
To: rrrs-authors@MC.LCS.MIT.EDU
I would prefer to see no dedication in preference to making the dedication
serious. I think a serious dedication would read as insincere because
the Scheme report is an obvious parody of the Algol 60 report.
As much for my asusement as for anything else, I wrote this explanation:
The Algol 60 report is gravely earnest. Among its many firsts, Algol was
first to use a grammar-like construct to define its syntax. The first
report -- "Preliminary report - International Algebraic Language" -- as
well as the revision, were published as cover stories in the
@i(Communucations of the ACM) (*). The report was the culmination of an
international effort, followed with international attention. In the style
of world war commentary, the reader learns of the Zurich meeting, the Paris
meeting, and of the seven European representatives who held a final
prepatory meeting in Mainz in December 1959. And let us not forget the
seven American representatives with a similar quest, in Boston that same
year. We are spared the details of the lunch meats; judged, with Ph.D.
precision I am certain, to be expendable from the accounting. In each
re-reading, I look (in vain) for the mention of Teller and Oppenheimer;
surely they were involved too. It is in this intensely sober context that
we read the full page eulogy of William Turanski (**), who died after being
struck by a car the day before the 1960 conference in Paris.
(*) CACM v1 #12, 1958; CACM v6 #1, 1963
(**) CACM v3 #5, 1960, p 298
Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
relatives the ideal names for those procedures? Scheme is as serious as
LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The
names are arbitrary and incidental; CAR and CDR remind us. Scheme is as
much an approach as a detailed concrete specification. But to be taken
seriously, for Scheme to be widely used, we must have the details and
concretions; they are essential but unimportant.
The Algol 60 report is almost ludicrous in its sobriety. If we use the form
of Algol 60 to present happy little Scheme, we cannot avoid the parody;
try as we might.
Still, I think there is good reason to use the form. Presenting Scheme in
the form of the Algol 60 report may capture the attention of those who
clump together and ignore all Lisp-like languages because the culture is so
different from what they know. The contrast with @i(Chine Nual) and
@i(CLtL) is important. Perhaps Lisp can be other than a bag of features of
a metastasizing runtime environment. Perhaps it can even be described in
the style of the day!
Following the model of Algol 60 exactly points out that the form of
description is itself an arbitrary convention; and the point is made in
perfect Scheme style. Just as Scheme can provide the "their" control
constructs, it can be described in "their" form.
The parody pokes fun at all those essential but unimportant details.
It is the perfect couch for Scheme.
So for all this, I find a serious dedication inappropriate. Algol 60's
dedication was grave; to an Algol soldier, killed in his prime (he was 35).
Scheme's dedication should be to something unimportant. "Dedicated to the
memory of dynamic binding.", as Jonathan once suggested, fits well. It
seems to me so much better than to try to be as somber and important as
Algol 60. I think we would look foolish in the attempt.
-Norman
-------
∂14-Jul-86 0641 @MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA Re: Compatibility with Common Lisp: A meta comment
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 06:40:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 09:41:16 EDT
Received: from ti-csl by csnet-relay.csnet id aa01646; 14 Jul 86 9:37 EDT
Received: by tilde id AA09613; Mon, 14 Jul 86 08:20:24 cdt
Date: Mon 14 Jul 86 08:11:52-CDT
From: Don Oxley <OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Compatibility with Common Lisp: A meta comment
To: RPG%su-ai@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@su-ai.ARPA>" of Sat 12 Jul 86 18:35:00-CDT
Message-Id: <12222608155.17.OXLEY@CSC60>
I must second Dick Gabriel's reply. A little "friendly rivalry" with
Common Lisp is fine, but the ultimate acceptance of Lisp (of either
dialect) is the crucial concern. I am probably as biased toward Scheme
as anyuone, but if Scheme is to succeed, it will owe a significant debt
to Common Lisp.
--Don
-------
∂14-Jul-86 0741 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Common Lisp
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 07:41:27 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 14 Jul 86 10:41:54 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA19058; Mon, 14 Jul 86 10:41:36 EDT
Posted-Date: Mon, 14 Jul 86 10:38:32 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA07736; Mon, 14 Jul 86 10:38:32 edt
Date: Mon, 14 Jul 86 10:38:32 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607141438.AA07736@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Common Lisp
I certainly qualify an no fan of Common Lisp, however, I too would
like to point out a simple argument against gratuitous
incompatibilities with Common Lisp. Scheme's impact will be limited
if it is very difficult to convert CL code to Scheme, even if many
agree it is a superior language. The best way to port CL to Scheme is
in an environment that supports both languages. To me, Scheme would
be an excellent language in which to implement Common Lisp. A Scheme
implementation of Common Lisp would facilitate the conversion of CL
code by allowing versions the program to be written in a mixture of
both languages. Let's not make a Scheme implementation of Common Lisp
such a pain that no one will do it.
John
∂14-Jul-86 1008 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ANDY: dedication]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 10:08:39 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUL 86 13:09:07 EDT
Date: Mon, 14 Jul 86 13:08:53 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [ANDY: dedication]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].69636.860714.JAR>
Date: Mon 14 Jul 86 02:09:08-PDT
From: Andy Freeman <ANDY at sushi.STANFORD.EDU>
To: jar at AI.AI.MIT.EDU
Re: dedication
Message-ID: <12222563967.24.ANDY@sushi.STANFORD.EDU>
Has everyone else forgotten that Knuth dedicated his series to a 650
at case?
-andy
∂14-Jul-86 1337 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Use of DO in Common Lisp Code
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 13:33:33 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 16:33:54 EDT
Date: 14 Jul 86 1332 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Use of DO in Common Lisp Code
To: rrrs-authors@MC.LCS.MIT.EDU
I looked at a spectrum of code in the Lucid implementation of Common
Lisp to see how DO is used where DOLIST and DOTIMES could not
be used. The breakdown of use of iteration is this:
the frequency of use of DO is the same as the use of DOTIMES
and DOLIST combined
the use of LABELS/FLET is used as often as DOLIST.
The uses of DO in place of DOTIMES and DOLIST are interesting.
Sometimes the stepper is not CDR, so the use of DO is exactly
like DOLIST, but with the stepper (and end test) different; typically:
(DO ((current data-structure (next-data current)))
((empty-data current)) ...)
Sometimes the use is exactly like DOLIST, but the test is different.
(DO ((l l (cdr l)))
((end-test l))
(let ((x (car l)))
...))
But the most frequent use (by a margin of 3 to 1) is a combination of
DOTIMES and DOLIST:
(do ((l l (cdr l))
(i 0 (1+ i)))
((null l))
(let ((x (car l)))
...))
The use of DO outside of these paradigms is almost non-existent. Hairier
control structures are usually done with LABELS/FLET, and there are
3 large ATN's in the implementation, written with (glarg) TAGBODY.
One principle of Lisp design that DO follows is that the binding of the
iterator, its initial value, and its updator are apparent immediately upon
inspection - they are usually on one line. This principle is the basis of
(LET ((x value)) ...) being preferred to ((lambda (x ...) ...) value ...):
X and VALUE are not near each other on the page.
I don't have a proposal to make, but this data might be of use in thinking
about iteration in Scheme.
-rpg-
∂14-Jul-86 1448 @MC.LCS.MIT.EDU:goodhart%cod@nosc.ARPA Scheme Request
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 14:46:18 PDT
Received: from bass.ARPA by MC.LCS.MIT.EDU 14 Jul 86 17:27:39 EDT
Received: by bass.ARPA (5.31/4.7)
id AA09836; Mon, 14 Jul 86 14:25:49 PDT
Received: by cod.ARPA (5.31/4.7)
id AA13068; Mon, 14 Jul 86 14:25:46 PDT
Date: Mon, 14 Jul 86 14:25:46 PDT
From: Curtis L. Goodhart <goodhart%cod@nosc.ARPA>
Message-Id: <8607142125.AA13068@cod.ARPA>
To: scheme@mit-mc.ARPA
Cc: goodhart@nosc.ARPA
Subject: Scheme Request
-------
I am interested in obtaining a version of Scheme that will run on a
VAX 11/780 running VMS 4.2 OR a PDP-11/70 running Unix 2.9 .
Can you provide me some info on this?
I also recall that I may be able to FTP a copy of Scheme?
Are there user manuals available too?
Also, I will be at MIT in the Fall and probably take Ableson, and Sussman's
course, in which Scheme is used. Are there any crucial differences
between the version I might get through you and the version and MIT?
Thanks,
Curt Goodhart (goodhart@nosc on the arpanet)
-------
∂14-Jul-86 1514 @MC.LCS.MIT.EDU:andy@sun3.ads.ARPA Scheme vs. Common Lisp, #1: Politics
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 15:13:31 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 14 Jul 86 17:33:32 EDT
Date: Mon, 14 Jul 86 14:31:19 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: rrrs-authors%mit-mc@ads.arpa
Subject: Scheme vs. Common Lisp, #1: Politics
Cc: andy@ads.arpa, gls%think@ads.arpa, rpg%su-ai@ads.arpa
Reply-To: andy@ads.arpa
This is the first of two notes on CommonLisp vs. Scheme. I have
written two notes in an attempt to separate political concerns
from design concerns, in part to keep them clear in my own mind and
in part in consideration of those of you who, like me, generally
have neither the time nor the temperment for long political debates
on the ARPANET. This note concerns the politics, or what I
think of (perhaps a little unkindly) as the "form rather than
the content" of the CL-Scheme issue. Those of you who stick it out
and read through this note (and the ones that are sure to follow)
should bear in mind that, as we've already seen, politics is
necessarily a somewhat more personal discipline than is the
technology most of us are really interested in, and for that reason
writing styles for the political notes can be expected to differ
from those composed with primarily technical purposes in mind.
asc
------------------------------------------------------------------------
Shortly after receiving Dick's flame, the following scenario popped
into my head. You are listening in on a phone conversation somewhere
in Arlington, Virginia.
Squires: Clint, I hear a rumor that Andy Cromarty is concerned
about CommonLisp's influence on the development of
Scheme.
Kelly: Scheme?
Squires: Yes, another kinky LISP dialect being designed by some
researchers. It only has a fraction of CommonLisp's
features and they can't quite seem to decide what
it should look like.
Kelly: Well, Steve, I guess I'll have to ask you to simply
rescind DARPA's support for CommonLisp, then, and
from now on we'll require all our AI projects to
use Structured COBOL.
I suppose I should be flattered at the suggestion that a few sentences
from me would reshape the course of LISP history, especially coming as
it does from Dick Gabriel. But somehow I give the research funding
community and the commercial tool market a little more credit for
indepedence of thought than this scenario (or Dick's note) suggests.
Perhaps more importantly, I am somewhat troubled by the idea that
Dick would advocate censorship of ideas and opinions concerning LISP
design and development (viz. his instructions that we "Don't let
anyone outside this list see Andy's message."). My assumption is
that the RRRS-AUTHORS list exists for the purpose of supporting "open
discussion within a closed community" concerning what form Scheme
should take, and that we all implicitly agree to attempt to ground
our argumentation for our favored alternative views on a substantive
technical basis. In this regard, I probably agree with the
suggestion that my comment "represents a low point in political
thinking." I think the implied converse option -- that we all need
to suppress concern or public discussion about the *costs* of CL
compatibility, or for that matter, any other dangerous thoughts we
might have -- represents a new high water mark in politicization
of the Scheme design process, and I would not feel complimented to be
accused of having set that new standard. Certainly there are others
in the Scheme community with whom I disagree, but I cannot imagine
proposing (for example) that we censor Dan Friedman because his
ideas about internal DEFINE differ from mine. Quite the contrary: I
look forward to hearing why alternative views are held; and when I
decide I can't stand the heat, *I* get out of the kitchen.
But yes, please don't repeat my messages outside this community. I
think we all assume that our discussions are held reasonably private
by this community, since this is still a design-in-progress, and at
the present I'm sensitized by having been poorly quoted a little too
often in the press recently. (And anyway, if anyone at DARPA
wants to know what I think of CL, they have my phone number.)
Now let's take a good hard political look at who disagreed most
vocally with my comment. The few responses I've received so far all
have been from competent LISP designers and implementors, to be sure.
But it is also true that they have been from: the implementor(s) of
Texas Instruments' Common Lisp and Scheme products; the author of the
premier Common Lisp text; and the president of the most successful
and best know Common Lisp product company in the world. In addition,
many or most of these people were personally involved in the Common
Lisp design effort. Their credentials are impeccable, but their
goals and commitments may not be the same as those of, say, a
professor who is using Scheme for its pedagogical value and has no
career or financial stake per se in the long-term viability or
political acceptance of this year's best production quality LISP
environment. I certainly believe that having their views represented
is critical to a good Scheme's development, and I made it clear in my
original note that I do consider myself to be an outlying point in
the distribution of views on CL vs. Scheme. But I think they are,
too; and let us not assume that the most vociferous advocates of
extreme positions (myself included) represent either the norm or the
best compromise position to take.
Since Dick couldn't see from his location down the street that my
tongue was towards the side of my mouth when I used the term "dark
forces," let me say that (a) I think Common Lisp is one of the most
successful technology results of any standardization committee I've
seen and (b) my reference was to the risk of Scheme becoming just
like Common Lisp, rather than a criticism of the quality of Common Lisp
as a LISP. Overall, Common Lisp is very good at being what it tries to
be. I am utterly unconvinced that that's what Scheme is trying to
be, however. I will treat the question of the goals of the two
languages in my companion note, but for now suffice it to say that
the idea that these languages have (forgive the pun) common goals
strikes me as nonsensical. If that were true, we could submit Guy's
excellent book to SIGPLAN and retire this list. I might go so far as
to say that it is precisely because Scheme exists that Common Lisp
can be successful, in the following sense: Those of us who are
concerned with what LISP should look like for the next several
decades can preoccupy ourselves with design debates over Scheme
morality, while people like Dick and Guy go on to take a snapshot of
what the community knows about good LISP design and then integrate
that knowledge, addressing and overcoming all the political obstacles
along the way, to produce a viable, saleable LISP product. And good
luck to them; but I do not see that Lucid's chimeras need to be ours.
Rather than worry that people will learn that there is more than one
LISP, let's advertise the fact. Let's make it clear that LISP is an
ideal language for embedding new constructs in, and that the presence
of a good heavily-featured standardized dialect has not quenched the
long-standing historical drive for LISPers to remain at the
forefront of programming language and programming environment design.
Let's advocate a plethora of LISP-like languages to get people out of
the Pascal-derivative language design syndrome and instead get them
directly and cleanly addressing individual hard language design
problems, like the keyword shadowing problem, design of appropriate
multiprocessing constructs, embedding of evidential reasoning
techniques into a programming language, integration of advanced
database technology into the programming environment in a coherent
fashion, getting distributed inheritance graphs to work across
loosely-coupled processors, and (somebody, please!) developing a
reasonable model of I/O. Let's get them thinking that LISP is not
dead, that it is not a "solved problem," that it's there to
experiment with, and that there are and will continue to be good
reasons for all the debates we engage in on how languages should be
designed.
asc
p.s. Dick, if you're still pissed off at me, we can go out for
dinner at the LISP conference and you can throw darts at me.
∂14-Jul-86 1607 @MC.LCS.MIT.EDU:RPG@SU-AI.ARPA Politics
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 16:07:16 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 18:59:35 EDT
Date: 14 Jul 86 1557 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Politics
To: rrrs-authors@MC.LCS.MIT.EDU
Naturally I'm not pissed at Andy. Were I truly pissed, and truly
flaming, my message would have begun, ``Andy, you total and complete
bagbiter, you are such a big loser that they had to extend the
city limits to include....''
My point was that I could imagine someone forwarding Andy's vitriol
to Common-Lisp or ARPA-BBOARDS and thereby lose some allies that
we, who are Scheme lovers one and all, would prefer to not lose if
at all possible.
Someday I'd like Lucid to be the ``most successful and best-known
supplier of Scheme products,'' on that happy day when Common Scheme
becomes the standard.
Homage, an item of low cost to the RRRS-authors, buys a lot from the
Common Lisp troops. Messages like Andy's, keyboard-in-cheek as they
may be, possibly buy more grief than the fun of typing them gains.
Politics and science are not so radically removed from each other. When
one propose some technical viewpoint, his goal is to have it accepted,
usually before he dies. Having his viewpoint accepted helps his
self-esteem, his quest for fame as a scientist, his reach for tenure. This
isn't much different from politics, in which the goals are probably
self-esteem, fame, and a reach for office. Although there may be more
technical content to a technical debate, the tactics used in arguing for a
political end really don't differ significantly.
This design committee should aim at producing the best possible Lisp.
If that happens to mean that nothing in it is like the corresponding
thing in Common Lisp, that's fine. All technical debate regarding these
choices should be open. If nothing in Scheme is like the corresponding thing
in Common Lisp simply because Common Lisp is bad, and disjointness is a
goal, then I think this design committee will have blown it.
********************************
On a related note, now that there has been a fair bit of experience with
Common Lisp, it might be worthwhile for this group to ask some of the
Common Lisp hackers about their experience with the parts of Common Lisp
that the Schemers find objectionable. Similarly, it might be instructive to
look at what the Common Lisp hackers find nice about Common Lisp that might
be surprising.
-rpg-
∂14-Jul-86 1702 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA call-with-xput-port vs. call-with-xput-file
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 17:00:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 19:42:14 EDT
Received: from indiana by csnet-relay.csnet id ac02754; 14 Jul 86 19:26 EDT
Date: Mon, 14 Jul 86 11:47:21 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: call-with-xput-port vs. call-with-xput-file
I favor changing call-with-input-file and call-with-output-file to
call-with-input-port and call-with-output-port. However, I have some
questions related to the change and to ports in general.
1. I saw lots of confusion over the fact that you open a file (with
open-input-file and open-output-file) but close a port (with close-
input-port and close-output-port). Changing the "call-with" names
could increase the confusion. Should we change open-input-file and
open-output-file to open-input-port and open-output-port?
2. I have added string ports to Chez Scheme and need to choose names.
If we have call-with-...-file and open-...-file, I can introduce the
names call-with-...-string and open-...-string. On the other hand,
if we have call-with-...-port and open-...-port, I can introduce the
names call-with-...-string-port and open-...-string-port. The names
are longer but perhaps more descriptive. How do these names sound?
The point of this question is that any names we choose should
generalize to other types of ports.
3. Currently, there is no way to change the current ports to anything
other than a freshly-opened file (as with the inessential with-input-
from-file and with-output-to-file). Stylistically, I think it is
better to never change the standard ports. But if they can be changed,
I'd like to have a way for a debugger, say, to change them back to an
existing file (usually the original current ports), so that anything
the user executes goes to the expected place. Without this we cannot
hope to write a reliable portable debugger (and debug code with calls
to with-input-from-file or with-output-to-file).
4. Also, there is no way to change the current ports permanantly.
That is, it is not possible to write (set-current-input! <port>) or
(set-current-output! <port>). Again, I don't think this is good
practice, but some might rue the inability to do so.
5. Why is call-with-input-file essential and open-input-file not?
If call-with-input-file is analogous to call-with-current-continuation,
why do we not have (call-with-new-string <length> <proc>) instead of
make-string or (call-with-pair <obj1> <obj2> <proc>) instead of cons,
etc? Because call-with-current-continuation is special---a function
make-continuation would be problematic. In short, while I see the
merit in with-input-from-file since it closes the file and rebinds a
standard port, I cannot see the merit in call-with-input-file. Can
we flush call-with-input-file and call-with-output-file and promote
open-input-file and open-output-file to essential status?
∂14-Jul-86 1814 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme Request
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 18:06:40 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUL 86 21:00:38 EDT
Date: Mon, 14 Jul 86 20:58:54 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scheme Request
To: goodhart@NOSC-COD.ARPA
cc: goodhart@NOSC.ARPA, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 14 Jul 86 14:25:46 PDT from Curtis L. Goodhart <goodhart%cod at nosc.ARPA>
Message-ID: <[AI.AI.MIT.EDU].69927.860714.JAR>
Date: Mon, 14 Jul 86 14:25:46 PDT
From: Curtis L. Goodhart <goodhart%cod at nosc.ARPA>
I am interested in obtaining a version of Scheme that will run on a
VAX 11/780 running VMS 4.2 OR a PDP-11/70 running Unix 2.9 .
I think most or all of your questions are answered by the contents of
the file "LSPMAI;SCHEME IMPLS" available on Internet hosts MIT-MC,
MIT-MX, and MIT-AI (I have copied it around to improve its
accessibility, in case one or two of these machines are down).
By the way, I'll mail this file (about 17K) to anyone who requests it,
although if you can FTP it that's preferable. These machines aren't
finicky about usernames or passwords or things like that.
Jonathan
∂14-Jul-86 2156 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA the colon (:) in identifier syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 21:55:58 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:25 EDT
Received: from indiana by csnet-relay.csnet id aj05326; 15 Jul 86 0:48 EDT
Date: Mon, 14 Jul 86 21:34:01 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: the colon (:) in identifier syntax
Can we omit colon (:) from the enumeration of characters that can
be used in identifiers, to allow implementations to support some
sort of package system using colon as the separator?
∂14-Jul-86 2159 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA exp versus expt
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 21:59:46 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:33 EDT
Received: from indiana by csnet-relay.csnet id ak05326; 15 Jul 86 0:49 EDT
Date: Mon, 14 Jul 86 21:47:54 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: exp versus expt
We have a way to find an exponent of e (exp n) and of an arbitrary
base (expt b n). We have a function to find the log base e (log n)
but not the log in an arbitrary base. How about adding (log n b)?
Why do we have (expt b n)? We could instead give exp an optional
argument specifying the base, i.e., (expt b n) => (exp n b). Why
is it not done this way in Common Lisp, as it is for log? Perhaps
because the argument order would seem backwards?
Kent
∂15-Jul-86 0951 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU convergence
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 09:50:59 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86 12:51:31 EDT
Date: Tue, 15 Jul 86 12:51:27 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: convergence
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].70360.860715.JAR>
Apparently we could go on forever thinking of and arguing over ways to
improve the language. If you have changes you want considered for the
SIGPLAN version of the report, please send them right way (actually,
send them in several months ago). Otherwise PLEASE just sit on them for
a while, and when this report is out, then let's start discussing the
next version. For now, orient your messages towards achieving
stability. If you want perfection then nothing will ever get published.
And, as they say in the soaps, I need to get on with my life.
Thanks
Jonathan
∂15-Jul-86 1807 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Scheme's DO construct
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 18:07:03 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 21:07:47 EDT
Received: from tektronix by csnet-relay.csnet id aa14951; 15 Jul 86 20:49 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA29117; Tue, 15 Jul 86 15:50:33 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA19578; Tue, 15 Jul 86 15:52:54 PDT
Message-Id: <8607152252.AA19578@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: Scheme's DO construct
Date: 15 Jul 86 15:52:52 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
There are two things to be said in defense of Scheme's DO:
1. Unlike most general purpose iteration constructs, DO is useful
for functional programming.
2. DO is the only general purpose iteration construct in Scheme
that doesn't force you to think up a name (such as LOOP) for
the loop.
This is a long message, but the two points above are the gist of it.
It seems to me that Andy has missed the first point entirely, considering
his remarks that:
I have no prima facie objection to the use of iterative constructs,
and in particular, none to supporting iteration in Scheme. Indeed, I
think that it is often very effective to think procedurally and
iteratively rather than functionally and recursively. (I understand
these are apples and oranges, but the styles are usually associated
with each other.)
...
I have performed the following informal experiment. I had one or
two of the people working with me who were true devotees of LOOP
and DO go back and recode fairly large (5000-15000 lines) LISP programs,
ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping
functions. I should say that they did it "kicking and screaming," not
because of the work involved but because they so loved all the features
that LOOP offered.
LOOP is indefensible, but Andy is mistaken to lump DO with LOOP.
If by "mapping functions" Andy here means the standard Scheme mapping
functions, then MAP is the only functional alternative to DO that Andy
offered his people. MAP isn't general enough to replace DO, and DOLIST,
DOTIMES, and FOR-EACH are completely useless for functional programming.
Thus it seems that in the name of style Andy was coercing his people to
convert functional programs that use DO into non-functional programs.
It seems to me that if we truly want to discourage people from writing
functional programs, a more effective way to do it would be to change
Scheme so people can't program in the functional style until they master
a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL
into their programs.
Let's consider the functional alternatives to DO using a simple example.
The example is not too simple; it cannot easily be written using Scheme's
standard mapping procedures. (Aside: In the example, SEQUENCE is a
procedure, not a special form, so this is not portable Scheme code.
The name SEQUENCE was meaningful to my audience, so I used it anyway.
As I recall the discussion at Brandeis, SEQUENCE as a special form was
supposed to disappear over time so we could use the name for such higher
purposes, and I was very disappointed that the recent vote was phrased
as a referendum on dropping BEGIN rather than on dropping SEQUENCE.)
The example is:
(define find-word-break
(lambda (x k2)
(do ((x x (rest x)))
((or (empty? x) (not (break? (first x))))
(do ((x x (rest x))
(word '() (concat word (sequence (first x)))))
((or (empty? x) (break? (first x)))
(k2 word x)))))))
The most straightforward elimination of DO yields:
(define find-word-break
(lambda (x k2)
(letrec ((loop1
(lambda (x)
(if (or (empty? x) (not (break? (first x))))
(letrec ((loop2
(lambda (x word)
(if (or (empty? x) (break? (first x)))
(k2 word x)
(loop2 (rest x)
(concat word
(sequence (first x))))))))
(loop2 x '()))
(loop1 (rest x))))))
(loop1 x))))
This code is rather forbidding, so I would probably define loop1 and loop2
in a single LETREC. That works in this case but would not work if a
variable introduced by the outer DO were free within the inner DO.
REC or NAMED-LAMBDA would improve the code a little.
Can Scheme do better? I could instead use named LET, which would have
the advantage of moving the initialization expression for each loop
variable into proximity with its binding, and would make some of the
LAMBDAs invisible:
(define find-word-break
(lambda (x k2)
(let loop1
((x x))
(if (or (empty? x) (not (break? (first x))))
(let loop2
((x x)
(word '()))
(if (or (empty? x) (break? (first x)))
(k2 word x)
(loop2 (rest x)
(concat word (sequence (first x))))))
(loop1 (rest x))))))
This version still has two disadvantages: (1) I had to think about (or avoid
thinking about!) the names LOOP1 and LOOP2; and (2) it is hard to find the
new bindings for the loop variables. The way to overcome these disadvantages
is to invent a new special form that moves the expressions that compute the
new values for the loop variables next to their bindings (Dick Gabriel has
already pointed out the value of doing this) and to suppress the names of
the loops; in other words, to invent DO.
Having invented DO, we still have to decide on its syntax. The syntax of
Scheme's DO is less than optimal for functional programming primarily
because it is designed to support an additional feature: you can insert
non-functional statements to be executed every time around the loop.
Because Scheme is not a purely functional language, this is a reasonable
feature to support; even I use it on occasion. Unless we can come up with
a significantly better syntax, we might as well enjoy the advantages of
Lisp tradition and compatibility, while fixing any randomness (as we did
by flushing the implicit binding of RETURN and by using binding instead of
assignment for the loop variables).
I could go on and talk about why functional loops such as the ones you
write using tail recursion or DO are easier to understand than imperative
loops such as the ones you write using DOTIMES, DOLIST, FOR-EACH, or
Andy's straw FOR, VARYING, REPEAT, or WHILE, but I don't think it's
necessary for this audience.
Peace, William Clinger
∂15-Jul-86 2019 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU rrrs-authors
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 20:18:55 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86 23:19:19 EDT
Date: Tue, 15 Jul 86 23:19:07 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: rrrs-authors
To: adams%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 15 Jul 86 14:30:07 PDT from Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].70741.860715.JAR>
Date: Tue, 15 Jul 86 14:30:07 PDT
From: Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
To: jar at AI.AI.MIT.EDU
Re: rrrs-authors
Message-Id: <8607152130.AA18643@tekchips.TEK>
Who is on the rrrs-authors list? I'm just curious ... -N
Here's the current membership of the list. It's pretty much the same
people as were on the SCHEME mailing list before it was opened up to the
general public.
- Jonathan
;;; -*- Mode:LISP; -*-
;;; Authors of the Revised↑3 Report on the Algorithmic Language Scheme
;;; To be added or deleted, send mail to SCHEME-REQUEST.
;;; Sorted alphabetically by name of institution, and alphabetically
;;; within institution, except for MIT, which appears first.
(file [LSPMAI;RRRS MAIL]) ;Local archive file
(SCHEME-RRRS MIT-OZ) ;Oz people
;;; Also on SCHEME-TEAM
(LS.SRB EE)
(cherian vx)
YEKTA ;Yekta Gursel
JAR ;?
(katz vx)
(alco vx)
(CPH AI)
;;; Others
ALAN
NICK ;Nick Papadakis
RHH ;Bert Halstead
Daniel ;Daniel Weise
RDZ ;Ramin Zabih
;;; Non-MIT
(jleech aids-unix) ;AI & DS / Jay Leech
(william aids-unix) ; William Bricken
(andy aids-unix) ; Andy Cromarty
(wand%northeastern CSNET-Relay) ;Brandeis / Mitch Wand
(dyb%indiana CSNET-Relay) ;Indiana / Kent Dybvig
(scheme-rrrs%indiana CSNET-Relay) ;Indiana / ...
(linus!ramsdell Mitre-Bedford) ;MITRE / John Ramsdell
("#COMSCH.MSG[SCH,LSP]" SU-AI) ;Stanford / File archive
(ANDY SU-SUSHI) ; Andy Freeman
(RPG SU-AI) ; Dick Gabriel
KMP ;Symbolics / Kent Pitman
(adams%tekchips%tektronix csnet-relay) ;Tektronix / Norman Adams
(willc%tekchips%tektronix csnet-relay) ; Will Clinger
(Scheme-Local%TI-CSL CSNET-Relay) ;TI / ...
GLS ;TMI / Guy Steele
(patel CS.UCLA.EDU) ;UCLA / Dorab Patel
(Hudak Yale) ;Yale / Paul Hudak
(Kelsey Yale) ; Richard Kelsey
(Kranz Yale) ; David Kranz
(Philbin-Jim Yale) ; Jim Philbin
∂15-Jul-86 2105 @MC.LCS.MIT.EDU:jleech@sun6.ads the rrrs authors
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 21:05:30 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 16 Jul 86 00:05:50 EDT
Date: Tue, 15 Jul 86 21:03:00 PDT
From: jleech@sun6.ads (Jay Leech)
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: the rrrs authors
Cc: andy@sun3.ads.ARPA
Myself and a couple of others on the rrrs-authors mailing list were
associated with AI & DS.
We have changed our company name to Advanced Decision Systems, and
our arpanet address should now be ads or ads-unix.
Also, good work! I am looking forward to the publication of the report.
-- Jay Leech
∂16-Jul-86 1731 @MC.LCS.MIT.EDU:brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA Substring & friends
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86 17:31:44 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:21:33 EDT
Received: from ti-csl by csnet-relay.csnet id aq04187; 16 Jul 86 15:26 EDT
Received: by tilde id AA18614; Wed, 16 Jul 86 11:01:18 cdt
Date: Wed, 16 Jul 86 11:01:18 cdt
From: Gary Brooks <brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Substring & friends
As stated in the R↑3 Report, the documentation for the <start> and <end>
indices for substring & friends is consfused. The report states that
<start> and <end> must be valid indices (with <start> <= <end>). This
is certainly not the case if you are taking the substring of an entire
string, where the index for <end> must be one greater than the largest
valid index. The previous report, RRRS, included a paragraph explaining
that <start> is inclusive and <end> is exclusive, which is clearer
though still inconsistant with the documentation for substring. This
inconsistency should be rectified.
On the other hand <start> and <end> could be defined to both be
inclusive. Now, I realize that there are probably too many instances of
substring & friends running around, and that this would be incompatible
with CL's subsequence, but I for one dislike the notion of (exclusive)
indices that may not be (really) valid indices. Comments?
-- brooks
∂16-Jul-86 1732 @MC.LCS.MIT.EDU:Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA Re: number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86 17:32:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:22:46 EDT
Received: from ti-csl by csnet-relay.csnet id bn04187; 16 Jul 86 15:40 EDT
Received: by tilde id AA19590; Wed, 16 Jul 86 11:21:40 cdt
Date: Wed 16 Jul 86 10:53:32-CDT
From: David Bartley <Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA>
Subject: Re: number syntax
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA
Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA
In-Reply-To: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-Id: <12223161873.35.BARTLEY@CSC60>
> Date: Thu, 10 Jul 86 12:09 EDT
> From: Jonathan A Rees <JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA>
>
> Date: Tue 17 Jun 86 16:00:31-CDT
> From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
>
> One irritant in the Report that we have neglected to comment on until
> now (sorry!) is the syntax of numbers. We believe that Scheme numbers
> are essentially equivalent to Common Lisp numbers except for the new
> notion of exactness. To the extent that that is so, it seems to be a
> (shudder!) ``gratuitous difference'' from Common Lisp to have an
> incompatible syntax. [...]
>
> What we'd like to see is an essential syntax for numbers which is
> compatible with Common Lisp's. Additional features, including
> exactness, would be optional extensions. Even so, they should not
> conflict with Common Lisp. For example, the use of `#s' and the order
> of <sign> and <prefix> are different in the two languages. [...]
>
> Does anyone agree with us? Is there time to make such a change before
> R↑3RS goes to press?
>
>I think everyone agrees with you, and that there is time. Could you
>please write a concrete proposal, preferably something close to being
>suitable for inclusion in the report. Also please provide BNF. Thanks.
>
>Jonathan
Here's a stab at it---we expect and welcome debate over the details.
The major differences between the syntax of numbers in Common Lisp (CL)
and heretofore in Scheme (R↑3RS) are:
(1) CL has the prefix denoting base precede the sign; R↑3RS has the sign
precede the prefix, which includes the base specifier. I see no reason to
differ from CL.
(2) CL uses several exponent markers to specify levels of precision for
floating point numbers; R↑3RS specifies precision levels (S and L) in the
prefix. Again, why differ from CL?
(3) CL does not provide for the use of `#' to indicate insignificant
digits. Making this a non-essential feature in R↑3RS seems reasonable.
(4) CL provides only the #C(real real) notation for complex numbers; R↑3RS
provides infix notations for both polar and rectangular forms. For
compatibility with CL, R↑3RS should support the #C notation and the infix
forms should be non-essential extensions.
(5) CL integers may optionally terminate in a decimal point; R↑3RS permits
such a number to be treated as floating point and it is debated whether it
is to be considered exact. This is a serious problem, since many
procedures are defined to accept only integer values. Is the call
(INTEGER->CHAR 55.) valid? We propose that this be a non-essential
feature in R↑3RS.
(6) CL integers and ratios are not permitted to have exponent markers.
This feature should be a non-essential extension to Scheme.
(7) CL does not have the concept of exactness. Most (all?) existing
implementations of Scheme do not support this feature, so it should be
non-essential.
We propose the following syntax for numbers in Scheme. (Recall that
letter case is insignificant in the grammar and that the rules for <ureal
R>, <prefix R>, etc., should be replicated for R = 2, 8, 10, and 16.)
<number> --> <real> | #c( <real> <real> )
<real> --> <prefix R> <sign> <ureal R>
<prefix R> --> <exactness> <radix R>
<exactness> --> <empty> | #i | #e
<radix 2> --> #b
<radix 8> --> #o
<radix 10> --> <empty> | #d
<radix 16> --> #x
<sign> --> <empty> | + | -
<ureal R> --> <integer R> | <ratio R> | <flonum R>
<integer R> --> <digit R>+ #*
<ratio R> --> <digit R>+ #* / <digit R>+ #*
<flonum R> --> . <digit R>+ #* <expon>
| <digit R>+ . <digit R>* #* <expon>
| <digit R>+ #* . #* <expon>
<expon> --> <empty> | <expon-marker> <sign> <digit>+
<expon-marker> --> e | f | d | l | s
<digit 2> --> 0 | 1
<digit 8> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
<digit 10> --> <digit 8> | 8 | 9
<digit 16> --> <digit 10> | a | b | c | d | e | f
Although we have incorporated <exactness> and the use of `#' above, they
should be stated to be non-essential features of Scheme.
Nonessential feature: integers with optional decimal points.
<integer R> --> <digit R>+ #* .
Nonessential feature: integers and ratios with exponents.
<integer R> --> <digit R>+ #* <expon>
<ratio R> --> <digit R>+ #* <expon> / <digit R>+ #* <expon>
Nonessential number productions representing complex numbers. We worry
that the forms <real>+<ureal>i and <real>-<ureal>i can be hard to parse.
Perhaps combining the suffix `i' with the infix `+' or `-' would be
palatable to those who want this feature.
<number> --> <real> +i <ureal>
| <real> -i <ureal>
| <real> @ <real>
Regards,
David Bartley
Mark Meyer
-------
∂16-Jul-86 1921 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU July 15 draft sent
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86 19:20:50 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JUL 86 22:21:14 EDT
Date: Wed, 16 Jul 86 22:21:24 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: July 15 draft sent
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].71397.860716.JAR>
Today I US-mailed another draft to everyone (except GLS, KMP, and people
at MIT, who I'll get to Thursday or Friday, or who can steal them from
my desk). It is closer to done than the previous one was, but note that
it does NOT reflect any changes in number syntax, LOAD, or names of
call-with-*put-port. There are a few other things I didn't get to,
which I can't recall right now, but I'm confident that y'all will miss
them and tell me.
I probably won't start another pass over it until a week from tomorrow
(i.e. the 17th), so don't feel guilty if you don't send your remarks to
me before that. After the 20th is when you can start feeling guilty.
Jonathan
∂17-Jul-86 0851 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Substring & friends
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 08:50:17 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86 11:50:47 EDT
Date: Thu, 17 Jul 86 11:50:46 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: Substring & friends
To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 16 Jul 86 11:01:18 cdt from Gary Brooks <brooks%tilde%TI-CSL.CSNET at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].71736.860717.CPH>
I object to changing the substring indexing scheme. I chose the
imbalanced inclusive-start/exclusive-end pair because it has a some
nice properties:
1. The pair for the entire string is (0, length(string)), which is
trivially computable.
2. The pair for the empty string is (i, i) for any i <=
length(string). There is no natural representation for this if both
indices are inclusive.
Don't think that no thought went into this. I know that on first
encountering this scheme it seems unintuitive, but experience has
shown it to be quite effective, and once learned, easy to remember.
I don't think that the issue of whether or not the end index is a
valid index for the string is very interesting. In practice, it is
easy to decide whether a given index pair is valid:
0 <= start <= end <= length(string)
∂17-Jul-86 1217 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: Substring & friends
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 12:17:21 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86 15:00:16 EDT
Date: Thu 17 Jul 86 13:09:44-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: Substring & friends
To: CPH@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].71736.860717.CPH>
Message-ID: <12223437888.36.GJS@OZ.AI.MIT.EDU>
I agree with CPH about his choice of "half-open interval"
representations of strings. I believe that the choice he made is
pretty optimal because of good nesting and adjacency relations that
are clear if one thinks abstractly.
-------
∂17-Jul-86 1412 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [jtv%fingate.bitnet: Scheme Request]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 14:12:40 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86 17:01:37 EDT
Date: Thu, 17 Jul 86 16:39:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [jtv%fingate.bitnet: Scheme Request]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].71910.860717.JAR>
If someone could translate the following for me, or even identify what
language it's written in, I'd be grateful.
Thanks,
Jonathan
Date: Tue, 15 Jul 86 20:12:38 +0200
From: Jukka Virtanen <jtv%fingate.bitnet at WISCVM.ARPA>
To: JAR at AI.AI.MIT.EDU
Re: Scheme Request
Tjaah, ei meilla KAI ole schemea...
JOs on, en tieda siita. Juha Heinasella (tre)
jh@tut on sellainen REF manual, jota ketselin
katselin
chanlmersiin mentaessa.
Etkos tilannut scheme listat?
Vois ton tilata tuolta, jos viitsit.
Juki
∂17-Jul-86 1442 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Substring & friends
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 14:42:01 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jul 86 17:39:23 EDT
Received: from tektronix by csnet-relay.csnet id ah14030; 17 Jul 86 16:04 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA02159; Thu, 17 Jul 86 09:42:29 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA10005; Thu, 17 Jul 86 09:44:56 PDT
Date: Thu, 17 Jul 86 09:44:56 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607171644.AA10005@tekchips.TEK>
Subject: Re: Substring & friends
To: Gary Brooks <brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA>
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Gary Brooks <brooks%tilde%TI-CSL.CSNET@csnet-relay.CSNET>, Wed, 16 Jul 86 11:01:18 cdt
On the other hand <start> and <end> could be defined to both be
inclusive. Now, I realize that there are probably too many instances of
substring & friends running around, and that this would be incompatible
with CL's subsequence, but I for one dislike the notion of (exclusive)
indices that may not be (really) valid indices. Comments?
Here's a comment:
Currently, if given <start> and <length>, then <end> = <start> + <length>;
whereas with inclusive indices <end> = <start> + <length> - 1. I prefer
to not have to adjust by 1 in index computations.
-Norman
-------
∂18-Jul-86 0012 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Substring & friends
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jul 86 00:12:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 18 Jul 86 03:13:19 EDT
Received: from tektronix by csnet-relay.csnet id af00418; 18 Jul 86 2:58 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA19060; Thu, 17 Jul 86 15:26:12 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA14145; Thu, 17 Jul 86 15:28:40 PDT
Message-Id: <8607172228.AA14145@tekchips.TEK>
To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: Substring & friends
In-Reply-To: Your message of Wed, 16 Jul 86 11:01:18 cdt.
<8607170501.AA05456@tekchips.TEK>
Date: 17 Jul 86 15:28:38 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
An advantage of an inclusive <start> and an exclusive <end> is that
(substring s 0 (string-length s)) is the entire string. If both
were inclusive you'd have to say (substring s 0 (-1+ (string-length s))),
which seems less convenient. Using (- x 1) instead of (-1+ x) makes it
even harder to read.
An aside on -1+: As Marianne Moore said, I too dislike it. I can't
agree that it can't be pronounced, however, since I pronounce (-1+ x)
as "the predecessor of x" or "one less than x". As Kent Pitman once
pointed out, we can pronounce things however we like. (Kent wanted
things like EQ? to be pronounced "eek-pee". I propose that EQ? be
pronounced "eek-hunh?", with a rising inflection. Just kidding.)
By the way, I don't care whether 1+ and -1+ go or stay; whatever
Jonathan decides is fine with me.
Peace, Will
∂18-Jul-86 1428 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [jtv%fingate.bitnet: Scheme Request]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jul 86 14:27:42 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 JUL 86 17:23:00 EDT
Date: Fri, 18 Jul 86 17:22:04 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [jtv%fingate.bitnet: Scheme Request]
To: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 18 Jul 86 12:01:19 MDT from Fons Botman <mcvax!vu44!fons at seismo.CSS.GOV>
Message-ID: <[AI.AI.MIT.EDU].72425.860718.JAR>
Thanks to everyone who replied to my query about the Finnish mail I
received.
Jonathan
∂21-Jul-86 0448 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA typos
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 04:38:44 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 21 Jul 86 07:39:53 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA02999; Mon, 21 Jul 86 07:38:54 EDT
Posted-Date: Mon, 21 Jul 86 07:35:50 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA12384; Mon, 21 Jul 86 07:35:50 edt
Date: Mon, 21 Jul 86 07:35:50 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607211135.AA12384@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: typos
1) [Page 5, col 2, line 8] atsign => at-sign.
2) [Page 5, col 2, line -1] The note seems out of place.
I suggest deleting it.
3) [Page 5, col 1, line 19] #fand => #f and.
4) [Page 9, col 1, line 21] Odd indent.
5) [Page 10, col 2] Program example not indented correctly.
6) [Page 10, col 2, line -l] comma/at-sign/expression =>
comma at-sign expression OR comma-at-sign-expression.
7) [Page 12, col 2, line -14] In the phrase "equal? is the coarsest
or most liberal", liberal has too many meanings; I suggest
dropping the phrase "or most liberal".
8) [Page 20, col 1, line -20] rouding => rounding.
9) [Page 22, col 2, line -19] uppper => upper.
10) [Page 27, col 2] call-with-xxput-file => call-with-xxput-port.
11) [Page 38, col 1, ref 14] No page numbers.
Wow! What an improvement!
John
∂21-Jul-86 0737 @MC.LCS.MIT.EDU:Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU Performance and Evaluation of Scheme Systems...
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 07:37:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 21 Jul 86 10:35:36 EDT
Received: from wiscvm.wisc.edu by CSNET-RELAY.ARPA id aa26311;
21 Jul 86 10:33 EDT
Received: from (MIKE←WIL)CARLETON.BITNET by WISCVM.ARPA on 07/21/86 at
09:26:48 CDT
Received: from Mike←Wilson by CARLETON.BITNET on 21 Jul 86 08:37:12 EDT
Date: 21 Jul 86 08:04:00 EDT
From: Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA
Subject: Performance and Evaluation of Scheme Systems...
Hi,
I've just been looking through the book ←Performance and Evaluation
of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
results for several simple programs run on the more common lisp systems.
Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
interesting to see how we stack up. (I have to admit I am *impressed*
with their times for the IBM 3081 and CRAY-XMP. Oh well...)
.Mike
∂21-Jul-86 0808 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU schedule
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 08:08:44 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86 11:01:29 EDT
Date: Mon, 21 Jul 86 11:00:01 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: schedule
To: ramsdell%linus@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 21 Jul 86 07:47:45 edt from ramsdell%linus at mitre-bedford.ARPA
Message-ID: <[AI.AI.MIT.EDU].73291.860721.JAR>
Date: Mon, 21 Jul 86 07:47:45 edt
From: ramsdell%linus at mitre-bedford.ARPA
I cannot keep up with your schedule. I received the July 15th draft
on Friday afternoon, and did not have access to a computer until this
morning. There is no way I could have gotten my reply to you by July
20th.
Jeez, did I tell people to send me comments by the 20th? I meant to say
that I won't be doing anything until the 24th, so don't kill yourself to
get stuff to me before that. Within 5 days after the 24th would be very
nice. The main guideline is this: the report must absolutely be in its
final form before the Lisp conference; in fact, it probably has to be
done by Thursday July 31, so that there's time to make zillions of
copies of it to hand out at the conference.
Jonathan
∂21-Jul-86 0827 @MC.LCS.MIT.EDU:CLOWNEY@BLUE.RUTGERS.EDU Logic Continuations (Abstract)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 08:20:45 PDT
Received: from BLUE.RUTGERS.EDU by MC.LCS.MIT.EDU 21 Jul 86 11:18:22 EDT
Date: 21 Jul 86 11:11 EDT (Mon)
From: Les <Clowney@BLUE.RUTGERS.EDU>
To: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Cc: scheme@MC.LCS.MIT.EDU, clowney@BLUE.RUTGERS.EDU
Subject: Logic Continuations (Abstract)
Hi Chris,
I am generally interested in reports on Scheme that have come
out of Indiana University, and am currently interested in the report
on continuations as applied to the implementation of logic programming in
Scheme (Computer Science Department Technical Report No. 183). Where
should I inquire about this report and a general index of Scheme
related reports?
les
∂21-Jul-86 1014 @MC.LCS.MIT.EDU:gls@Think.COM Scheme's DO construct
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 10:14:48 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 21 Jul 86 12:40:47 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 12:36:35 edt
Date: Mon, 21 Jul 86 12:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Scheme's DO construct
To: andy@AIDS-UNIX.ARPA, rrrs-authors%mit-mc@AIDS-UNIX.ARPA
Cc: gls@AQUINAS.ARPA
In-Reply-To: <8607132227.AA23925@Zarathustra.Think.COM>
Message-Id: <860721123716.3.GLS@BOETHIUS.THINK.COM>
Well, you have constructed a great case based on anecdotal evidence,
which is worth having, but I think you have not even addressed my main
point. The other constructs you mentioned (FOR, REPEAT, and WHILE) have
what I regard as an important flaw: a reliance on side effects to
accomplish some part of the iterative process. There is seldom any use
in stepping just one variable in an iteration; you want to step two or
more. Because FOR, REPEAT, and WHILE (and for that matter DOLIST and
DOTIMES) each step at most one variable, it is necessary to have some
side effect in the body to get anything done.
DO is the only iteration construct we have (other than LOOP) that
encapsulates completely the notion of iteration: the iterative
transformation of a state (normally a compound state, therefore
consisting of two or more quantities) in such a way that an invariant is
maintained at each step, terminated when the state satisfies some
condition. The problem is not that DO has too many features, but that
each of the other iteration constructs is incomplete in a way that must
be patched up using side effects.
I would be quite happy to eliminate one feature of DO: the body! If the
body is used, then side effects are necessarily involved. The most
perspicuous uses of DO have no body.
The other problem with DO is that sometimes there is more than one
reason to exit. I admit that as a flaw; but then again, sometimes there
is reason to return more than one value from a function, and I believe
SCHEME is not yet addressing that either with explicit features.
(Having a body compensates somewhat for that:
(defun memq (x l)
(do ((z l (cdr z)))
((null z) nil)
(when (eql x (car z)) (return z))))
This leads me to propose that a good iteration construct would be
like DO but instead of having a body would have more COND clauses.)
--Guy
∂21-Jul-86 1057 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: Performance and Evaluation of Scheme Systems...
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 10:57:44 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 21 Jul 86 13:55:04 EDT
Received: from ti-csl by csnet-relay.csnet id aa27733; 21 Jul 86 13:37 EDT
Received: by tilde id AA15867; Mon, 21 Jul 86 11:06:17 cdt
Date: Mon 21 Jul 86 10:52:21-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Performance and Evaluation of Scheme Systems...
To: Mike←Wilson%CARLETON.BITNET%wiscvm.wisc.edu@CSNET-RELAY.ARPA,
scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: Message from "Mike Wilson <Mike←Wilson%CARLETON.BITNET%wiscvm.wisc.edu@CSNET-RELAY.ARPA>" of Mon 21 Jul 86 08:04:00-CDT
Message-Id: <12224472379.36.BARTLEY@CSC60>
>Date: 21 Jul 86 08:04:00 EDT
>From: Mike Wilson
>Subject: Performance and Evaluation of Scheme Systems...
>
> I've just been looking through the book ←Performance and Evaluation
>of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
>results for several simple programs run on the more common lisp systems.
>Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
>interesting to see how we stack up. (I have to admit I am *impressed*
>with their times for the IBM 3081 and CRAY-XMP. Oh well...)
I will be presenting a paper on TI's PC Scheme at the conference on LISP
and Functional Programming in Cambridge the first week of August. Part of
the paper consists of a brief comparison of PC Scheme and other PC-based
LISP implementations on 7 benchmark programs, some of which come from
Gabriel's test suite. After the conference, I'll be glad to forward this
information to anyone interested.
Regards,
David Bartley
-------
∂21-Jul-86 1143 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU Bobcat scheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 11:43:10 PDT
Received: from MEDIA-LAB.MIT.EDU by MC.LCS.MIT.EDU 21 Jul 86 14:40:25 EDT
Received: by MEDIA-LAB.MIT.EDU (5.31/4.8) id AA03625; Mon, 21 Jul 86 14:38:21 EDT
Date: Mon, 21 Jul 86 14:38:21 EDT
From: William H Coderre <bc@MEDIA-LAB.MIT.EDU>
Message-Id: <8607211838.AA03625@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Bobcat scheme
I did a rather trivial test between CScheme on Bobcat and MacScheme.
I suspect my data, since it appeared that CScheme was GCing a LOT.
Silly Question:
Does anybody know offhand how to tell unix to give Scheme more memory?
We have the "deluxe" bobcats with graphics stuff andapproximately 8
megs of core, and we'd like to use them!
"Tzima Narki"............................................................bc
∂21-Jul-86 1228 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Logic Continuations (Abstract)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 12:27:49 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86 15:08:31 EDT
Date: Mon, 21 Jul 86 15:06:42 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Logic Continuations (Abstract)
To: Clowney@BLUE.RUTGERS.EDU
cc: cth%indiana.csnet@CSNET-RELAY.ARPA, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 21 Jul 86 11:11 EDT (Mon) from Les <Clowney at BLUE.RUTGERS.EDU>
Message-ID: <[AI.AI.MIT.EDU].73379.860721.JAR>
Date: 21 Jul 86 11:11 EDT (Mon)
From: Les <Clowney at BLUE.RUTGERS.EDU>
... Where should I inquire about this report and a general index of
Scheme related reports?
I'm trying to maintain a moderately thorough bibliography. Here's what
it looks like at present (this is the bibliography for the new version
of the scheme report). If anyone has additions to suggest, please send
me mail.
- Jonathan
\begin{thebibliography}{99}
\bibitem{SICP}
Harold Abelson and Gerald Jay Sussman with Julie Sussman.
{\em Structure and Interpretation of Computer Programs.}
MIT Press, Cambridge, 1985.
\bibitem{Bartley86}
David H.~Bartley and John C.~Jensen.
The implementation of PC Scheme.
To appear in {\em Proceedings of the 1986 ACM Conference on Lisp
and Functional Programming}.
\bibitem{Scheme81}
John Batali, Edmund Goodhue, Chris Hanson, Howie Shrobe, Richard
M.~Stallman, and Gerald Jay Sussman.
The Scheme-81 architecture---system and chip.
In {\em Proceedings, Conference on Advanced Research in VLSI},
pages 69--77.
Paul Penfield, Jr., editor.
Artech House, 610 Washington Street, Dedham MA, 1982.
\bibitem{RRRS}
William Clinger, editor.
The revised revised report on Scheme, or an uncommon Lisp.
MIT Artificial Intelligence Memo 848, August 1985.
Also published as Computer Science Department Technical Report 174,
Indiana University, June 1985.
\bibitem{Clinger84}
William Clinger.
The Scheme 311 compiler: An exercise in denotational semantics.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming}, pages 356--364.
\bibitem{Dybvig86}
R.~Kent Dybvig, Daniel P.~Friedman, and Christopher T.~Haynes.
Expansion-passing style: Beyond conventional macros.
To appear in {\em Proceedings of the 1986 ACM Conference on Lisp and
Functional Programming.}
\bibitem{Eisenberg85}
Michael A.~Eisenberg.
Bochser: an integrated Scheme programming system.
MIT Laboratory for Computer Science Technical Report 349,
October 1985.
\bibitem{Feeley86}
Marc Feeley.
Deux approches \`{a} l'implantation du language Scheme.
M.Sc.~thesis, Department of Computer Science and Operations Research,
University of Montreal, May 1986.
\bibitem{Felleisen86}
Matthias Felleisen, Daniel P.~Friedman, Eugene Kohlbecker, and Bruce Duba.
Reasoning with continuations.
In {\em Proceedings of the Symposium on Logic in Computer Science},
pages 131--141.
IEEE Computer Society Press, Washigton DC, 1986.
\bibitem{Scheme311}
Carol Fessenden, William Clinger, Daniel P.~Friedman, and Christopher Haynes.
Scheme 311 version 4 reference manual.
Indiana University Computer Science Technical Report 137, February 1983.
\bibitem{Scheme84}
D.~Friedman, C.~Haynes, E.~Kohlbecker, and M.~Wand.
Scheme 84 interim reference manual.
Indiana University Computer Science Technical Report 153, January 1985.
\bibitem{Friedman85}
Daniel P.~Friedman and Christopher T.~Haynes.
Constraining control.
In {\em Proceedings of the Twelfth Annual Symposium on Principles of
Programming Languages}, pages 245--254.
ACM, January 1985.
\bibitem{Haynes84}
Christopher T.~Haynes, Daniel P.~Friedman, and Mitchell Wand.
Continuations and coroutines.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming,} pages 293--298.
\bibitem{Haynes86}
Christopher T.~Haynes.
Logic continuations.
In {\em Proceedings of the Third International Conference on
Logic Programming,\/} pages \todo{x--y}.
Springer-Verlag, July 1986.
% and to appear in {\it The Journal of Logic Programming.}
\bibitem{Engines}
Christopher T.~Haynes and Daniel P.~Friedman.
Engines build process abstracions.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming,\/} pages 18--24.
\bibitem{Henderson82}
Peter Henderson. Functional Geometry.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming}, pages 179--187.
\bibitem{Kohlbecker86}
Eugene Edmund Kohlbecker~Jr.
{\em Syntactic Extensions in the Programming Language Lisp.}
PhD thesis, Indiana University, August 1986.
\bibitem{Kranz86}
David Kranz, Richard Kelsey, Jonathan Rees, Paul Hudak, James Philbin,
and Norman Adams.
Orbit: An optimizing compiler for Scheme.
In {\em Proceedings of the SIGPLAN '86 Symposium on Compiler
Construction}, pages 219--233.
ACM, June 1986.
\bibitem{Landin65}
Peter Landin.
A correspondence between Algol 60 and Church's lambda notation: Part I.
{\em Communications of the ACM} 8(2):89--101, February 1965.
\bibitem{McDermott80}
Drew McDermott.
An efficient environment allocation scheme in an interpreter for a
lexically-scoped lisp.
In {\em Conference Record of the 1980 Lisp Conference,} pages
154--162.
The Lisp Conference, P.O.~Box 487, Redwood Estates CA,
August 1980.
\bibitem{MITScheme}
MIT Department of Electrical Engineering and Computer Science.
Scheme manual, seventh edition.
September 1984.
\bibitem{Muchnick80}
Steven S.~Muchnick and Uwe F.~Pleban.
A semantic comparison of Lisp and Scheme.
In {\em Conference Record of the 1980 Lisp Conference}, pages 56--64.
The Lisp Conference, August 1980.
\bibitem{Naur63}
Peter Naur et al.
Revised report on the algorithmic language Algol 60.
{\em Communications of the ACM} 6(1):1--17, January 1963.
\bibitem{Penfield81}
Paul Penfield, Jr.
Principal values and branch cuts in complex APL.
In {\em APL '81 Conference Proceedings,} pages 248--256.
ACM SIGAPL, San Francisco, September 1981.
Proceedings published as {\em APL Quote Quad} 12(1), ACM, September 1981.
\bibitem{Pitman83}
Kent M.~Pitman.
The revised MacLisp manual (saturday evening edition).
MIT Artificial Intelligence Laboratory Technical Report 295, May 1983.
\bibitem{Pitman80}
Kent M.~Pitman.
Special forms in Lisp.
In {\em Conference Record of the 1980 Lisp Conference}, pages 179--187.
The Lisp Conference, August 1980.
\bibitem{Rees82}
Jonathan A.~Rees and Norman I.~Adams IV.
T: A dialect of Lisp or, lambda: The ultimate software tool.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming}, pages 114--122.
\bibitem{Rees84}
Jonathan A.~Rees, Norman I.~Adams IV, and James R.~Meehan.
The T manual, fourth edition.
Yale University Computer Science Department, January 1984.
\bibitem{Reynolds72}
John Reynolds.
Definitional interpreters for higher order programming languages.
In {\em ACM Conference Proceedings}, pages 717--740.
ACM, \todo{month?}~1972.
\bibitem{Rozas84}
Guillermo J.~Rozas.
Liar, an Algol-like compiler for Scheme.
S.~B.~thesis, MIT Department of Electrical Engineering and Computer
Science, January 1984.
\bibitem{Smith84}
Brian C.~Smith.
Reflection and semantics in a procedural language.
MIT Laboratory for Computer Science Technical Report 272, January 1982.
\bibitem{Stallman80}
Richard M.~Stallman.
Phantom stacks---if you look too hard, they aren't there.
MIT Artificial Intelligence Memo 556, July 1980.
\bibitem{Imperative}
Guy Lewis Steele Jr.~and Gerald Jay Sussman.
Lambda, the ultimate imperative.
MIT Artificial Intelligence Memo 353, March 1976.
\bibitem{Declarative}
Guy Lewis Steele Jr.
Lambda, the ultimate declarative.
MIT Artificial Intelligence Memo 379, November 1976.
\bibitem{Debunking}
Guy Lewis Steele Jr.
Debunking the ``expensive procedure call'' myth, or procedure call
implementations considered harmful, or lambda, the ultimate GOTO.
In {\em ACM Conference Proceedings}, pages 153--162.
ACM, 1977.
\bibitem{Macaroni}
Guy Lewis Steele Jr.
Macaroni is better than spaghetti.
In {\em Proceedings of the Symposium on Artificial Intelligence and
Programming Languages}, pages 60--66.
These proceedings were published as a special joint issue of {\em
SIGPLAN Notices} 12(8) and {\em SIGART Newsletter} 64, August 1977.
\bibitem{Rabbit}
Guy Lewis Steele Jr.
Rabbit: a compiler for Scheme.
MIT Artificial Intelligence Laboratory Technical Report 474, May 1978.
\bibitem{CLoverview}
Guy Lewis Steele Jr.
An overview of Common Lisp.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming}, pages 98--107.
\bibitem{CLtL}
Guy Lewis Steele, Jr.
{\em Common Lisp: The Language.}
Digital Press, Burlington MA, 1984.
\bibitem{Scheme78}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The revised report on Scheme, a dialect of Lisp.
MIT Artificial Intelligence Memo 452, January 1978.
\bibitem{TAOTI}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The art of the interpreter, or the modularity complex (parts zero, one,
and two).
MIT Artificial Intelligence Memo 453, May 1978.
\bibitem{DOALBP}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
Design of a Lisp-based processor.
{\em Communications of the ACM} 23(11):628--645, November 1980.
\bibitem{Dream}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The dream of a lifetime: a lazy variable extent mechanism.
In {\em Conference Record of the 1980 Lisp Conference}, pages 163--172.
The Lisp Conference, August 1980.
\bibitem{Scheme75}
Gerald Jay Sussman and Guy Lewis Steele, Jr.
Scheme: an interpreter for extended lambda calculus.
MIT Artificial Intelligence Memo 349, December 1975.
\bibitem{Scheme79}
Gerald Jay Sussman, Jack Holloway, Guy Lewis Steele, Jr., and Alan Bell.
Scheme-79---Lisp on a chip.
{\em IEEE Computer} 14(7):10--21, July 1981.
\bibitem{Stoy77}
Joseph E.~Stoy.
{\em Denotational Semantics: The Scott-Strachey Approach to
Programming Language Theory.}
MIT Press, Cambridge, 1977.
\bibitem{TI85}
Texas Instruments, Inc.
{\em TI Scheme Language Reference Manual.}
Preliminary version 1.0, November 1985.
\bibitem{Wand78}
Mitchell Wand.
Continuation-based program transformation strategies.
{\em Journal of the ACM} 27(1):174--180, 1978.
\bibitem{Wand80}
Mitchell Wand.
Continuation-based multiprocessing.
In {\em Conference Re\-cord of the 1980 Lisp Conference}, pages 19--28.
The Lisp Conference, August 1980.
\end{thebibliography}
∂21-Jul-86 1325 @MC.LCS.MIT.EDU:gls@Think.COM Re: Scheme's DO construct
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 13:22:39 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 21 Jul 86 16:10:31 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 15:12:23 edt
Date: Mon, 21 Jul 86 15:13 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Scheme's DO construct
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
In-Reply-To: <8607152252.AA19578@tekchips.TEK>
Message-Id: <860721151311.0.GLS@BOETHIUS.THINK.COM>
Date: 15 Jul 86 15:52:52 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
...
It seems to me that if we truly want to discourage people from writing
functional programs, a more effective way to do it would be to change
Scheme so people can't program in the functional style until they master
a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL
into their programs.
Heh, heh, heh. Well put, Will!
--Guy
∂21-Jul-86 1357 @MC.LCS.MIT.EDU:YEKTA@AI.AI.MIT.EDU Bobcat scheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 13:56:49 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86 16:53:21 EDT
Date: Mon, 21 Jul 86 16:37:10 EDT
From: Yekta Gursel <YEKTA@AI.AI.MIT.EDU>
Subject: Bobcat scheme
To: bc@MEDIA-LAB.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 21 Jul 86 14:38:21 EDT from William H Coderre <bc at MEDIA-LAB.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73422.860721.YEKTA>
Just say "scheme -heap nnn" where "nnn" is the number of kilo-items...
I think the default is 150 and I have run programs with heaps as high as 1200.
(You should have enough swap space for that if you are planning run at that
heap value).
Best, Yekta
∂22-Jul-86 0710 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 07:10:16 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 10:11:32 EDT
Date: Tue, 22 Jul 86 10:10:29 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: title wars
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].73688.860722.JAR>
The title I chose for the report is under siege. I guess this means we
need to discuss what it should be. I think the complaint is that the
superscript will pose typesetting and pronunciation problems for people
who cite the report. But think of the hundreds of papers with "SL←2(R)"
in their title. Oh well.
The main thing that's important to me is that it be as similar as
possible to "Revised Report on the Algorithmic Language ALGOL 60".
Beyond that I don't much care. Here are other possibilities:
- Dan Friedman has suggested "Revised Report on the Algorithmic Language
SCHEME" but this could be confused much too easily with the "Revised
Report on Scheme".
- "Another Report on the Algorithmic Language SCHEME"
(suggestive of YACC.) I sort of like this one.
- "A Report on the Algorithmic Language SCHEME"
- "Thrice Revised Report on the Algorithmic Language SCHEME"
This raises fomatting problems, since without the "thrice" it's
already as wide as it can be without deviating from the Algol report
layout.
- "Fourth Report on the Algorithmic Language SCHEME"
This has the advantage that it makes the next version easier to name.
"Report #4 on...", "The Next Report on ..." [imitative of "the
next whole earth catalog"], ...
or we could give the language a new name? no.
∂22-Jul-86 0717 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 07:16:59 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 10:17:57 EDT
Date: Tue, 22 Jul 1986 10:16 EDT
Message-ID: <HAL.12224716985.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: title wars
In-reply-to: Msg of 22 Jul 1986 10:10-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
i like the title as it is.
∂22-Jul-86 1143 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 11:42:28 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 14:09:25 EDT
Date: Tue, 22 Jul 86 14:08:30 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: title wars
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 22 Jul 86 10:10:29 EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73801.860722.CPH>
A minor note: I'd prefer that the word "Scheme" not be upper-cased in
the report. While this is appropriate for an acronym like "ALGOL", it
does not seem to be for "Scheme", which is not an abbreviation for
anything.
I don't really feel strongly about this, I just thought I would point
it out.
BTW, if we *must* change the title, I vote for "Fourth Report...".
∂22-Jul-86 1157 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 11:57:24 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 14:58:42 EDT
Date: Tue, 22 Jul 86 14:57:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: title wars
To: CPH@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 22 Jul 86 14:08:30 EDT from Chris Hanson <CPH at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73822.860722.JAR>
Date: Tue, 22 Jul 86 14:08:30 EDT
From: Chris Hanson <CPH at AI.AI.MIT.EDU>
A minor note: I'd prefer that the word "Scheme" not be upper-cased in
the report. While this is appropriate for an acronym like "ALGOL", it
does not seem to be for "Scheme", which is not an abbreviation for
anything.
Rationale:
I agree that "Scheme" generally shouldn't generally be in upper case,
and I think that it's "Scheme" everywhere else in the report. However,
I wanted to capitalize it in the title because this helps make it look
like the Algol 60 report.
∂22-Jul-86 1243 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 12:43:15 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 15:44:34 EDT
Received: from ti-csl by csnet-relay.csnet id aa08670; 22 Jul 86 15:37 EDT
Received: by tilde id AA23855; Tue, 22 Jul 86 13:40:20 cdt
Date: Tue 22 Jul 86 13:32:20-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: title wars
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].73688.860722.JAR>
Message-Id: <12224763647.36.BARTLEY@CSC60>
I have no real problem with leaving the title the way it is. Another
alternative would be ``1986 Revised Report ...''.
David Bartley
-------
∂22-Jul-86 1252 @MC.LCS.MIT.EDU,@YALE-BULLDOG.ARPA:hudak@YALE.ARPA Re: Performance and Evaluation of Scheme Systems...
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 12:52:28 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 15:46:50 EDT
Received: from yale-bulldog.arpa by CSNET-RELAY.ARPA id aa08705;
22 Jul 86 15:45 EDT
Received: by Yale-Bulldog.YALE.ARPA; 22 Jul 86 15:13:41 EDT (Tue)
Date: 22 Jul 86 15:13:41 EDT (Tue)
From: Paul Hudak <hudak@YALE.ARPA>
Message-Id: <8607221913.AA06470@Yale-Bulldog.YALE.ARPA>
Subject: Re: Performance and Evaluation of Scheme Systems...
To: Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>
Cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To: Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>, 21 Jul 86 08:04:00 EDT
I've just been looking through the book ←Performance and Evaluation
of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
results for several simple programs run on the more common lisp systems.
Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
interesting to see how we stack up. (I have to admit I am *impressed*
with their times for the IBM 3081 and CRAY-XMP. Oh well...)
The following is an excerpt from the paper:
Kranz, D., Kelsey, R., Rees, J., Hudak, P., Philbin, J., and Adams, N.
"ORBIT: an optimizing compiler for Scheme" in Proceedings of ACM
SIGPLAN '86 Symposium on Compiler Construction, June 1986, pp. 219-233.
Also to be published as SIGPLAN Notices Vol. 21, No. 7, July 1986.
Orbit vs. Other Lisp Engines:
Orbit 3600 Dorado 8600 780
Program (SUN III) +IFU (Dec CL) (Dec CL)
-------------------------------------------------------
Tak 0.25 0.43 0.52 0.45 1.83
Takl 1.63 4.95 3.62 2.03 7.34
Boyer 15.84 9.40 17.08 12.18 46.79
Browse 40.28 21.43 52.50 38.69 118.51
Destructive 1.24 2.18 3.77 2.10 6.38
Deriv 3.62 3.79 15.70 4.27 13.76
Dderiv 4.92 3.89 17.70 6.58 19.00
IDiv2 0.24 1.51 3.43 1.65 5.00
RDiv2 0.36 2.50 4.08 2.52 9.84
Triangle 84.36 116.99 252.20 99.73 360.85
Fprint 2.18 2.60 2.93 1.08 3.94
Fread 2.62 4.60 1.57 2.34 7.24
Tprint 1.66 4.89 5.55 0.70 2.85
Orbit vs. PSL vs. Franz:
Orbit PSL Franz
Program DN300 DN300 Sun II
-------------------------------------
Tak 1.34 1.62 2.37
Takl 6.21 12.90 12.82
Boyer 63.16 46.92 37.94
Destructive 7.91 10.16 9.57
Dderiv 28.12 28.95 16.95
Orbit vs. Algol-like Languages:
DEC DEC
Program Orbit Unix C DEC C Pascal Modula II
---------------------------------------------------
Perm 1.26 2.6 2.5 2.5 2.0
Tower 1.65 2.6 2.7 2.6 1.9
ORBIT was built (primarily) at Yale, and its availability will be
announced at the upcoming LISP Conference. If you want more details
about ORBIT or the benchmarks, please read the above cited paper.
-Paul
∂22-Jul-86 1529 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 15:28:33 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 18:11:14 EDT
Received: from ti-csl by csnet-relay.csnet id al09489; 22 Jul 86 17:49 EDT
Received: by tilde id AA28902; Tue, 22 Jul 86 15:46:53 cdt
Date: Tue 22 Jul 86 15:37:57-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: title wars
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, CPH%ai.ai.mit.edu@CSNET-RELAY.ARPA
Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA,
Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].73822.860722.JAR>
Message-Id: <12224786515.36.BARTLEY@CSC60>
Date: Tue, 22 Jul 86 14:57:41 EDT
From: Jonathan A Rees <JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA>
Date: Tue, 22 Jul 86 14:08:30 EDT
From: Chris Hanson <CPH at AI.AI.MIT.EDU>
A minor note: I'd prefer that the word "Scheme" not be upper-cased in
the report. While this is appropriate for an acronym like "ALGOL", it
does not seem to be for "Scheme", which is not an abbreviation for
anything.
Rationale:
I agree that "Scheme" generally shouldn't generally be in upper case,
and I think that it's "Scheme" everywhere else in the report. However,
I wanted to capitalize it in the title because this helps make it look
like the Algol 60 report.
I agree with Chris -- Scheme is a word, not an acronym. ALGOL is an
acronym and should be written in all caps. If you want it to look EXACTLY
like the Algol 60 report, name the language ALGOL!
David Bartley
-------
∂22-Jul-86 1755 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU title
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 17:55:00 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86 20:56:23 EDT
Date: Tue 22 Jul 86 20:41:50-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: title
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12224830912.34.GJS@OZ.AI.MIT.EDU>
I think that the current title -- R↑4 and all -- is really nice.
-------
∂24-Jul-86 1244 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU call-with-xput-port vs. call-with-xput-file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:22:56 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JUL 86 15:24:28 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 4905; Thu 24-Jul-86 15:13:30-EDT
Date: Thu, 24 Jul 86 15:12 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: call-with-xput-port vs. call-with-xput-file
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860724151248.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: Mon, 14 Jul 86 11:47:21 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: call-with-xput-port vs. call-with-xput-file
I favor changing call-with-input-file and call-with-output-file to
call-with-input-port and call-with-output-port. However, I have some
questions related to the change and to ports in general.
1. I saw lots of confusion over the fact that you open a file (with
open-input-file and open-output-file) but close a port (with close-
input-port and close-output-port). Changing the "call-with" names
could increase the confusion. Should we change open-input-file and
open-output-file to open-input-port and open-output-port?
2. I have added string ports to Chez Scheme and need to choose names.
If we have call-with-...-file and open-...-file, I can introduce the
names call-with-...-string and open-...-string. On the other hand,
if we have call-with-...-port and open-...-port, I can introduce the
names call-with-...-string-port and open-...-string-port. The names
are longer but perhaps more descriptive. How do these names sound?
The point of this question is that any names we choose should
generalize to other types of ports.
I see these two points (together with general conservatism) as arguments
AGAINST changing the names. I am now inclined not to make the change.
5. Why is call-with-input-file essential and open-input-file not?
This resulted from a general spirit of minimalism at the Brandeis
meeting. The first is sufficient while the second isn't. Personally, I
never use the second.
If call-with-input-file is analogous to
call-with-current-continuation, why do we not have
(call-with-new-string <length> <proc>) instead of make-string or
(call-with-pair <obj1> <obj2> <proc>) instead of cons, etc? Because
call-with-current-continuation is special---a function
make-continuation would be problematic. In short, while I see the
merit in with-input-from-file since it closes the file and rebinds a
standard port, I cannot see the merit in call-with-input-file.
The merit is that it makes certain that the port gets closed. If we had to
deallocate resources and locks associated with allocated objects like strings,
then I think it would be a good idea to have call-with things for
those too.
Jonathan.
∂25-Jul-86 0022 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA Re: July 15 draft sent
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 00:22:18 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 03:24:07 EDT
Received: from ti-csl by csnet-relay.csnet id ab19183; 25 Jul 86 3:23 EDT
Received: by tilde id AA27498; Fri, 25 Jul 86 00:40:16 cdt
Date: Fri 25 Jul 86 00:35:05-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: July 15 draft sent
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA,
rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].71397.860716.JAR>
Message-Id: <12225408585.58.BARTLEY@CSC60>
I probably won't start another pass over it until a week from tomorrow
(i.e. the 17th), so don't feel guilty if you don't send your remarks to
me before that. After the 20th is when you can start feeling guilty.
I received my copy of the new revision to the R↑3RS yesterday (July 23)
and enclose my detailed comments below (boy, do I feel guilty!). I am
quite impressed overall with the current state of the document and want to
commend Jonathan for the success of his efforts! Nearly all of my
objections to the previous draft have been resolved satisfactorily. I
will repeat below some that have not, but in general I am content to leave
their resolution in JAR's hands.
[page 1]
I prefer to change "SCHEME" in the title to "Scheme", since it is not an
acronym.
[page 3]
I prefer to change "Snobol" to "SNOBOL", since it IS an acronym.
[page 4]
[line 4, left col] Change "if the feature is not AS essential feature"
to "if the feature is not AN essential feature".
[line 21, left col] Change "for a call to the procedures" (plural) to
"for a call to the procedure" (singular).
[line 29, left col] Change "indicates that THE in" to "indicates that, in".
[first bullet under 2.1] Remove the comma after "Certain identifiers".
[page 5]
[first paragraph of 2.2] Whitespace may also occur in the space
character (denoted by "#\ ").
[near the end of 2.3] You say that #T and #F are boolean CONSTANTs and
that #\ introduces a character CONSTANT; shouldn't you say that #(
introduces a vector CONSTANT also?
[last 2 lines of 2.3] If my proposed number syntax is adopted, #S and #L
will not exist.
[last 2 lines, right col] Flush the "Note: ..."; I assume it is a note
to yourself (?).
[page 6]
[section 3.2] Change "#fand" to "#f and".
[paragraph 6, sec 3.2] Change "Note that THAT the" to "Note that the".
[page 7]
[last paragraph of sec. 4.1.3] Change "Note also that in many
dialects..." to "{\em Note:} In many dialects...".
[page 8]
[line 6, right col] Shouldn't the notation (<test> => <recipient>) be
listed as a non-essential syntax in the heading rather than buried as an
implementation note in the body of the text?
[last paragraph, right col] I was very happy with your use of {\em
Syntax:} and {\em Semantics:} headers but they disappeared from AND
onward. I guess you ran out of time...
[page 9]
[first paragragh, sec 4.2.2] There is a mysterious whitespace at the
beginning of the fourth line of the paragragh.
[description of LET*] Shouldn't you replicate the description of
<bindings> and <body>? You do for LETREC.
Try to avoid the "widow" line for the heading of LET*.
[last line, right col] Here, and elsewhere, you have incomplete sentences
in which the subject is missing. This doesn't particularly offend me, and
it seems to read well, so I see no reason to correct it right away...
[page 10]
[end of 4.2.4] The indenting for the "(LET LOOP ((NUMBERS ..." example
has gone awry.
[page 12]
[end of 6.1] I'd like to see the example (EQ? NIL 'NIL) ==> #F added.
This reinforces the wording in the last paragraph of the left column,
which might be missed by someone looking only at the definition of NIL.
[page 14]
[last paragraph of the description of EQ?] Omit the words "instead of as
a subroutine call". It seems to imply that anything other than a pointer
comparison must be performed out of line, or that a pointer comparison
would necessarily be performed in line.
[page 17]
[lines 10, 11 of left col] Omit the sentence: "It is questionable
whether these features [slashification and uninterned symbols] are worth
their complexity, so they are not standard in Scheme." This editorial
comment is unnecessary and invites the response: "Then why is
SYMBOL->STRING worth while?"
[page 22]
[sec 6.6] Clarify the sentence: "This rule resolves the ambiguous case
... the space character AS AS the ...".
[page 30]
[sec 7.1.2, syntax of numbers] I mailed out a proposal for a syntax of
numbers compatible with Common Lisp last week but haven't received any
feedback. Did it fail to make it to the mailing list or is it that
non-controversial?
[page 36]
Try to avoid the "widow" line for the subtitle "EXAMPLE".
[Index]
Add #T and #F, and possibly #!TRUE and #!FALSE (page 12), to the index.
Regards,
David Bartley
-------
∂25-Jul-86 1026 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 10:17:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 13:19:12 EDT
Received: from tektronix by csnet-relay.csnet id ab23107; 25 Jul 86 12:51 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA08596; Wed, 23 Jul 86 11:48:49 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA29292; Wed, 23 Jul 86 11:51:24 PDT
Message-Id: <8607231851.AA29292@tekchips.TEK>
To: Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA
Cc: JAR@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: number syntax
In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT.
<12223161873.35.BARTLEY@CSC60>
Date: 23 Jul 86 11:51:22 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
After studying the recent proposal by David Bartley and Mark Meyer, I'm
afraid I have to object to using it in the report. I probably just don't
understand it, and I might change my mind if they'll explain it to me
better. I don't have much problem with the syntactic changes they propose.
The main problem I have with their proposal is that it addresses the syntax,
which I don't much care about, but doesn't address the semantic properties
like exactness and integer-ness. I have repeated most of their proposal
(indented two spaces) in order to point out the parts I object to.
(4) CL provides only the #C(real real) notation for complex numbers; R↑3RS
provides infix notations for both polar and rectangular forms. For
compatibility with CL, R↑3RS should support the #C notation and the infix
forms should be non-essential extensions.
Shouldn't the #C syntax be inessential also, since integer-only
implementations are allowed? Shouldn't all productions with decimal
points or slashes be inessential as well?
(5) CL integers may optionally terminate in a decimal point; R↑3RS permits
such a number to be treated as floating point and it is debated whether it
is to be considered exact. This is a serious problem, since many
procedures are defined to accept only integer values. Is the call
(INTEGER->CHAR 55.) valid? We propose that this be a non-essential
feature in R↑3RS.
It seems to me that most procedures that are currently defined to accept
only integer values should have been defined to accept only exact integer
values. Our concept of an integer needs to be tightened up. I propose
that INTEGER? be defined to be compatible with
(define integer?
(lambda (x)
(and (real? x) (= x (truncate x)))))
With a definition such as this it seems likely that 55. will be an integer.
The real question is whether it is exact. I haven't been able to answer
that question on the basis of the proposal.
We propose the following syntax for numbers in Scheme. (Recall that
letter case is insignificant in the grammar and that the rules for <ureal
R>, <prefix R>, etc., should be replicated for R = 2, 8, 10, and 16.)
<number> --> <real> | #c( <real> <real> )
<real> --> <prefix R> <sign> <ureal R>
<prefix R> --> <exactness> <radix R>
<exactness> --> <empty> | #i | #e
<radix 2> --> #b
<radix 8> --> #o
<radix 10> --> <empty> | #d
<radix 16> --> #x
<sign> --> <empty> | + | -
<ureal R> --> <integer R> | <ratio R> | <flonum R>
<integer R> --> <digit R>+ #*
<ratio R> --> <digit R>+ #* / <digit R>+ #*
<flonum R> --> . <digit R>+ #* <expon>
| <digit R>+ . <digit R>* #* <expon>
| <digit R>+ #* . #* <expon>
<expon> --> <empty> | <expon-marker> <sign> <digit>+
I believe the <digit>+ in the above production was intended to be
<digit 10>+.
<expon-marker> --> e | f | d | l | s
<digit 2> --> 0 | 1
<digit 8> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
<digit 10> --> <digit 8> | 8 | 9
<digit 16> --> <digit 10> | a | b | c | d | e | f
Although we have incorporated <exactness> and the use of `#' above, they
should be stated to be non-essential features of Scheme.
Nonessential feature: integers with optional decimal points.
<integer R> --> <digit R>+ #* .
This production is redundant, since all the strings it generates are
generated by the third production for <flonum R>. I judge by this
and other redundancies that the name of the non-terminal is intended
to carry semantic freight, but I can't tell what semantics is intended.
This is my fundamental objection to the proposal: it is a syntax
without a semantics.
Nonessential feature: integers and ratios with exponents.
<integer R> --> <digit R>+ #* <expon>
<ratio R> --> <digit R>+ #* <expon> / <digit R>+ #* <expon>
Similarly the production above for <integer R> is redundant, since it is
exactly the same as the first production for <flonum R>.
Nonessential number productions representing complex numbers. We worry
that the forms <real>+<ureal>i and <real>-<ureal>i can be hard to parse.
Perhaps combining the suffix `i' with the infix `+' or `-' would be
palatable to those who want this feature.
<number> --> <real> +i <ureal>
| <real> -i <ureal>
| <real> @ <real>
I'm not sure that this syntax is any easier to parse than the old syntax,
but it isn't any worse.
Regards,
David Bartley
Mark Meyer
-------
Peace, Will Clinger
∂25-Jul-86 1127 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (eqv? #e1 #i1)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 11:25:02 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUL 86 14:26:41 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 5047; Fri 25-Jul-86 14:24:41-EDT
Date: Fri, 25 Jul 86 14:25 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: (eqv? #e1 #i1)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860725142516.4.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: 22 Jul 86 11:31:02 PDT (Tue)
From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Technical question relating to exactness: Are 1 and 1.0 operationally
equivalent? (That is, if we wind up adopting the proposal that 1 be
read as an exact integer while 1.0 is read as an inexact integer, then
(EQV? 1 1.0) must be false. This is incompatible with the RRRS, which
says that EQV? returns true when its arguments are numbers that are
equal according to the = procedure. This incompatibility is not listed
in the notes on page 35. I wonder if the incompatibility was recognized
and intended.)
I assumed that this detail was an unintentional omission from RRRS.
Clearly #e1 and #i1 are distinguishable. I'll list this in the notes
section.
- Jonathan
∂25-Jul-86 1346 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA July 15th draft
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 13:46:05 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 25 Jul 86 15:47:55 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from clyde.sun.uucp by linus.MENET (1.1/4.7)
id AA09549; Fri, 25 Jul 86 15:45:49 EDT
Posted-Date: Fri, 25 Jul 86 15:42:54 edt
Received: by clyde.sun.uucp (2.0/SMI-3.0DEV3)
id AA01028; Fri, 25 Jul 86 15:42:54 edt
Date: Fri, 25 Jul 86 15:42:54 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607251942.AA01028@clyde.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: July 15th draft
On title wars, I am reminded of Norman's comments:
Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
relatives the ideal names for those procedures? Scheme is as serious as
LAMBDA, but as casual as CAR. Alas, what has become of dear PROGN? The
names are arbitrary and incidental; CAR and CDR remind us. Scheme is as
much an approach as a detailed concrete specification. But to be taken
seriously, for Scheme to be widely used, we must have the details and
concretions; they are essential but unimportant.
While publishers will most likely want to put out contracts on the
typing fingers of those who perpetrated the weird title, I think we
should have a little fun and keep the superscript in the title.
However, I do like the idea of NOT using all caps for Scheme in the
title.
David Bartley suggests changing "Snobol" into "SNOBOL" because it is
an acronym. If we do that, shouldn't we change "Algol" into "ALGOL"
and "Lisp" into "LISP"?
1) [Page 2, col 1, line 3] I am worried about the phrase "with
absolutely no restrictions on how they are composed". Certainly, the
expressions "1" and "2" should not be composed as "(1 2)". Doesn't
Scheme show that a small number of rules for forming expression
combined with a simple, uniform method of combining the expressions,
suffices to form a practical and efficient programming language?
2) [Page 5, col 1, paragraph 2] Too many parentheses. Only the first
pair are needed. Use commas for the others.
3) [Page 3, col 1, paragraph 3] Too many parentheses.
4) [Page 6, col 1, paragraph 1] From my reading of the paragraph, I
conclude that Common Lisp has no dynamic variables. After all, it
says that "To each place where a variable is bound in a program there
corresponds a region of the program text within which the binding is
effective." The lack of dynamic variables distinguishes Scheme from
Common Lisp and makes the above statement true.
5) [Page 10, col 1, line -16] Odd space between the words "region" and
"of".
6) [Page 10, col 2, line 1] Change to "general looping construct than
do, and may also be used to express recursive procedures."
7) [Page 14, col 1, line 22] The previous page states that there is
only one empty string. Therefore, (eqv? "" "") => #t, which implies
that (eq? "" "") => #t. If I am wrong, what does the statement about
the existence of one empty string mean?
8) [Page 27, col 2] I will simply say that, in my opinion,
call-with-xxput-port gives a user a better idea of what is going on,
as compared to call-with-xxput-file. In the interest of harmony, I
will rest my case unless I hear support from others.
John
∂26-Jul-86 2137 @MC.LCS.MIT.EDU:cth%iuvax.indiana.edu@CSNET-RELAY.ARPA corrections and suggestions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 21:37:14 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Jul 86 00:39:23 EDT
Received: from indiana by csnet-relay.csnet id ac11703; 27 Jul 86 0:39 EDT
Date: Thu, 24 Jul 86 17:21:19 est
From: Chris Haynes <cth%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: corrections and suggestions
I prefer "A Report ..." or "Fourth Report ...". In any case, remove
the bit about the ↑3 not being a footnote. No one is apt to mistake
the title's ↑3, for it is big and bold. It is *references* to the title
in other publications where the ↑3 will cause confusion, and the note
in the report won't do any good then.
I prefer "C.T. Haynes" in the author list, and "Christopher Haynes" in the
Background (p. 2).
In the summary, delete "and very few different ways to form expressions",
which is unnecessary and questionable.
p. 2: make those features --> make additional features
first real programming language -->
first widely used programming language
sub-dialects --> dialects
, while many others remain to be adopted. --> .
With Kent Dybvig, I would prefer that : not be an extended
alphabetic character, but be reserved for special uses.
2.3. unspecified future uses --> possible extensions in
discussion of [ ] and { }.
3.1. may name --> names
Question: Why say "A variable that does so is said to be bound to the
location." Is it possible to have variables that aren't bound to
locations? If so, how? The reader should not be kept in the dark.
Delete "Note: internale definitions not mentioned here."
3.2. #fand --> #f and
4.1 and 4.2. The "Syntax:" and "Semantics:" paragraph flags are
nice, but are not used after "case" (p. 8). I suggest flushing them.
Better to be consistent, and they aren't necessary for understanding.
4.2.4. Some implementations of Scheme permit a ... --> This ...
pretty printing of (let loop ...) is messed up.
5.1. consists a sequence --> consists of a sequence
6.2. if applying a mutation procedure to one causes the other to
change as well.
-->
if they have operationally equivalent values in corresponding
positions and applying a mutation procedure to one causes the
other to change as well.
For example, two pairs are equivalent if a set-car! operation on
one changes the car field of the other.
-->
For example, two pairs are not equivalent if a set-car!
operation on one does not change the car field of the other.
Questions: is "side-effect" defined anywhere? (A referee
recently critisized me for not defining it.)
6.4. (in the sense of eqv?) --> (in the sense of eq?)
[[the reader should be encouraged to think eq? on symbols]]
6.9, p. 27. is an ordinary Scheme procedure --> is a Scheme procedure
The classic use --> A common use
flush "when programmers need to do something fancy,"
I don't like the last sentence of 6.9. Opinions also differ on the
merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE
less than optional status by not listing it under BEGIN as an
(optional) form. List CALL/CC as a procedure under
CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a
statement that CALL/CC is equivalent. Several of us feel rather
strongly about this.
6.10.1. I also prefer CALL-WITH-*-PORT and OPEN-*-PORT.
Replace the last sentence of the WITH-*-*-FILE paragraph with
"Furthermore, when these procedures return, they close the
default port and restore the previous default. If an escape procedure
is used to escape from the continuation of these procedures, their
behavior is implementation dependent."
[[Rational: the existing "in constrast" statement is incorrect.
Where is the contrast? And more important, some systems will
automatically change the default port if the continuation is escaped,
but we probably don't want to even mention, let alone require, such
behavior.]]
6.10.4. Delete the LOAD rational. The LOAD description expressly
says that expressions and definitions are read, so any uses of LOAD to
load such things as compiled files are implementation extensions anyway.
Delete the TRANSCRIPT-* Note. We haven't provided elementary tips
to implementers anywhere else.
BIBLIOGRAPHY: add the following
Daniel P. Friedman, Christopher T. Haynes, and Eugene Kohlbecker,
Programming with continuations. {\it In Programming Transformation and
Programming Environments,\/} P. Pepper (Ed.), pages 263--274,
Springer-Verlag, 1984.
The Report reads quite well now, and has come a long way in the last
few months. Thanks for all your efforts, Jonathan.
Chris Haynes
∂28-Jul-86 0810 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Fault logic in eq? comment
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 08:10:43 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Jul 86 11:10:39 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
id AA27194; Mon, 28 Jul 86 11:08:54 EDT
Posted-Date: Mon, 28 Jul 86 11:06:06 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
id AA02270; Mon, 28 Jul 86 11:06:06 edt
Date: Mon, 28 Jul 86 11:06:06 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607281506.AA02270@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Fault logic in eq? comment
Opps! I used faulty logic in:
7) [Page 14, col 1, line 22] The previous page states that there is
only one empty string. Therefore, (eqv? "" "") => #t, which implies
that (eq? "" "") => #t. If I am wrong, what does the statement about
the existence of one empty string mean?
Please ignore it!
[Page 27, col 2] I think there is support for changing
call-with-xxput-file to call-with-xxput-port. I am not convinced that
open-xxput-port is any better than open-xxput-file, the latter
expresses what the function does just as well as the former does.
[Page 2] While the introduction implies Scheme has no dynamic
variables and no separate name spaces for global values and functions,
maybe that difference with existing Lisps should be made more
explicit. Thus, after "... in the same way as an operand position."
one might add "In contrast, many other dialects of Lisp associate two
values with some variables, and the bindings in effect at run time may
depend on the run time history of a program --- not simply the static
program structure."
John
∂28-Jul-86 1616 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: corrections and suggestions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 16:05:28 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jul 86 18:47:41 EDT
Received: from tektronix by csnet-relay.csnet id ai01735; 28 Jul 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA07871; Mon, 28 Jul 86 09:51:20 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA02924; Mon, 28 Jul 86 09:54:03 PDT
Message-Id: <8607281654.AA02924@tekchips.TEK>
To: cth%indiana.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: corrections and suggestions
In-Reply-To: Your message of Thu, 24 Jul 86 17:21:19 est.
<8607270553.AA19279@tekchips.TEK>
Date: 28 Jul 86 09:54:02 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
3.1. may name --> names
Question: Why say "A variable that does so is said to be bound to the
location." Is it possible to have variables that aren't bound to
locations? If so, how? The reader should not be kept in the dark.
There exist identifiers that are not syntactic keywords. According to the
first sentence of 3.1, any such identifier may be used as a variable. The
catch comes in an implementation with unbound variables, such as PC Scheme,
where just using an identifier as a variable does not make it name a
location; that must be done with a binding construct. I see your point,
but I suspect that many readers would prefer to remain in the dark about
this sort of thing until the next paragraph.
A related issue is that (top level) DEFINE is missing from the list of
binding constructs in the next paragraph.
I don't like the last sentence of 6.9. Opinions also differ on the
merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE
less than optional status by not listing it under BEGIN as an
(optional) form. List CALL/CC as a procedure under
CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a
statement that CALL/CC is equivalent. Several of us feel rather
strongly about this.
Whoa! Two wrongs don't make a right. Let's try to get rid of SEQUENCE
instead. Several of us feel rather strongly that CALL/CC ought to call
the C compiler. Seriously, to add alternative names for procedures now
would be inconsistent with our success in getting rid of =? et cetera.
Replace the last sentence of the WITH-*-*-FILE paragraph with
"Furthermore, when these procedures return, they close the
default port and restore the previous default. If an escape procedure
is used to escape from the continuation of these procedures, their
behavior is implementation dependent."
[[Rational: the existing "in constrast" statement is incorrect.
Where is the contrast? And more important, some systems will
automatically change the default port if the continuation is escaped,
but we probably don't want to even mention, let alone require, such
behavior.]]
The contrast is that WITH-*-*-FILE will close the default port whenever
you throw out of it without having done a CALL-WITH-CURRENT-CONTINUATION,
even if you stored the value of (CURRENT-*-PORT) in a global variable
before you did the throw. CALL-WITH-*-FILE would never do a thing like
that. To me, this is a striking contrast.
Peace, Will
∂29-Jul-86 1331 @MC.LCS.MIT.EDU:dyb@iuvax.indiana.edu critical problems with call---file, with---file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 13:01:13 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 15:58:06 EDT
Received: from indiana by csnet-relay.csnet id ab02982; 29 Jul 86 9:57 EDT
Date: Tue, 29 Jul 86 02:10:41 est
From: "R. Kent Dybvig" <dyb@iuvax.indiana.edu>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: critical problems with call---file, with---file
Cc: bartley%ti-csl.CSNET@CSNET-RELAY.ARPA, jar%mit-mc.CSNET@CSNET-RELAY.ARPA,
willc%tekchips@iuvax.indiana.edu
Regarding these quotes from the latest revision:
(under call-with-input-file, call-with-output-file)
If the procedure returns, then the port is closed
automatically and the value yielded by the procedure is
returned. If the procedure does not return, then Scheme
will not close the port unless it can prove that the
port will never again be used for a read or write operation.
(under with-input-from-file, with-output-to-file)
Furthermore, in contrast to call-with-input-file and
call-with-output-file, these procedures will arrange to
close the default port and restore the previous default
whenever the system can prove that the call to the
thunk will never return.
I have two problems with the wording of these two quotes. One of
these probems can be ignored, and we'll only have an ill-specified
and confusing set of procedures. The other cannot be ignored.
First, the one that cannot be ignored: From the wording of the
second quote, it is technically possible (and perhaps required!)
for a Scheme system to close a port out from under a procedure in
a way we do not intend. For example, if I write:
(with-input-from-file "foo.in"
(letrec ((loop (lambda ()
(write-char (read-char))
(loop))))
loop)),
it is clear that a clever Scheme system can prove that the thunk
will never return; however, it would be entirely inappropriate to
close the new default port and restore the old.
The second problem takes a little more explaining: I think that
most users will be very confused and rather upset that
call-with-input-file does not close the port automatically in the
case of a non-local exit, either programmed or through some sort
of error. Also, in the case of with---file, it is not clear
whether an implementation is required to close the port as soon as
it can prove that the call will never return, or sometime thereafter.
Furthermore, it is not clear how sophisticated the system must be
in proving this fact.
In the most recent version of Chez Scheme, ports are closed by the
storage manager once it determines there is no possibility of
reference. This will not necessarily occur as soon as the port
becomes inaccessible, but it is guaranteed that the system will not
run out of ports if there are any open, inaccessible ports around.
In addition, all ports are closed on exit from the system. This
is a much more general and reasonable solution to the problem of
closing ports than forcing the programmer to use confusing,
ill-defined procedures that don't necessarily help in the case
of non-local exits or errors.
It is fine to say that the port is closed when the procedure or thunk
returns, but we should flush the descriptions of what happens when
the procedure or thunk does not return, perhaps mentioning that, in
order to avoid running out of file-system resources, implementations
usually close ports it can prove are inaccessible. This would be
in the spirit of the earlier statement about not (usually!) running
out of storage (section 1.1, paragraph 4), and would also reinforce
the first-class status of ports.
Kent
p.s. We don't have much time, so please respond quickly.
∂29-Jul-86 1423 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU schedule
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 13:52:36 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86 16:52:21 EDT
Date: Tue, 29 Jul 86 16:35:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: schedule
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].77171.860729.JAR>
A version of the report is now at the printer. There will be a copy
in every Lisp conference registration packet.
As for SIGPLAN, I seem to have screwed up pretty badly; I thought that
having it done by early August would be good, since it would then get
into the October issue. However, I just found out from Wexelblat that
the October issue is proceedings for some conference. (This decision
was made rather late; the previous time I spoke with him, the October
issue was still open.) Therefore the earliest it can be out is the
November issue, and our new deadline is September 12.
For the Lisp conference version, I didn't do anything about number
syntax, since there seemed to be a bit of controversy remaining; also I
did nothing about the question of number input exactness, and didn't
rename the call-with-transput-pile procedures. What got printed was
rather close to the July 15 draft, incorporating, of course, most of the
corrections people sent me. Maybe we can fix these and other problems
by September, though.
Thanks to everyone who read the July 15 and other drafts so carefully.
If you won't be at the Lisp conference, let me know and I'll mail you a
copy of the latest thing.
Jonathan
∂29-Jul-86 1814 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: critical problems with call---file, with---file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:13:50 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 20:14:24 EDT
Received: from tektronix by csnet-relay.csnet id am07403; 29 Jul 86 18:48 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA06974; Tue, 29 Jul 86 15:23:57 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA22297; Tue, 29 Jul 86 15:26:48 PDT
Message-Id: <8607292226.AA22297@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: critical problems with call---file, with---file
Date: 29 Jul 86 15:26:46 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
...For example, if I write:
(with-input-from-file "foo.in"
(letrec ((loop (lambda ()
(write-char (read-char))
(loop))))
loop)),
it is clear that a clever Scheme system can prove that the thunk
will never return; however, it would be entirely inappropriate to
close the new default port and restore the old.
Nice example. Should we say instead that "If the procedure does not
return, Scheme will not close the port unless it can prove that the
continuation with which the procedure was called has become
inaccessible"?
I can't get very excited if ports aren't closed the instant they become
inaccessible, because I suspect that pairs aren't added to the free list
the instant they become inaccessible either. I can't see how it affects
my life.
As I read the report, implementations are not required to try to close
ports in the exceptional cases. Likewise, though implementations are
"permitted to reclaim the storage occupied by an object if they can
prove that the object cannot possibly matter to any future computation",
I don't see where implementations are actually required to reclaim
storage. I think it's clear that implementations are encouraged to do
both, and it's great that Chez Scheme is setting such a good example for
us to follow.
It would be reasonable to say that "in order to avoid running out of
file-system resources, implementations usually close ports it can
prove are inaccessible" if it were true. Is it?
Implementation note: In a very large multiprocessing implementation of
Scheme it might be more practical to remove limits on file-system
resources than to determine whether ports are accessible.
----------------------------------------------------------------
The section that describes differences between RRRS and R3RS should
note that (DEFINE (FOO ...) ...) is now equivalent to
(DEFINE FOO (LAMBDA (...) ...)) instead of to
(DEFINE FOO (REC FOO (LAMBDA (...) ...))).
Peace, Will
∂31-Jul-86 0732 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU rrrs authors meeting, lunch Tuesday
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 07:32:27 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 JUL 86 09:54:34 EDT
Date: Thu, 31 Jul 86 09:52:31 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: rrrs authors meeting, lunch Tuesday
To: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 30 Jul 86 17:01:20 PDT from Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].77967.860731.JAR>
Date: Wed, 30 Jul 86 17:01:20 PDT
From: Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
To: jar at AI.AI.MIT.EDU
It occurred to me that the bulk of the RRRS authoripods will be at
the lisp conference and that a meeting might bring quick resolution
to issues outstanding for the SIGPLAN edition of the R3RS. A
meeting might be fun even if there is nothing to resolve... What
say you? Perhaps there is not enough time to get a note out on
RRRS; maybe we could post something at the registration desk.
Good idea. What with Monday night being the banquet, and Tuesday night
being various Eulisp and Common Lisp meetings, I think lunchtime would
be best. Therefore I propose lunch on Tuesday, promptly following
cessation of the morning sessions.
If there's a major problem with this time then we can change it to lunch
Wednesday or some other time. I'll post something near the registration
desk in any case. See y'all there.
Jonathan
∂31-Jul-86 1111 @MC.LCS.MIT.EDU:fateman@DALI.BERKELEY.EDU Re: Performance and Evaluation of Scheme Systems...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 11:11:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 31 Jul 86 14:04:02 EDT
Received: from dali.berkeley.edu by CSNET-RELAY.ARPA id aa27481;
31 Jul 86 12:45 EDT
Received: by dali.Berkeley.EDU (5.53/1.14)
id AA17087; Thu, 31 Jul 86 08:49:56 PDT
Date: Thu, 31 Jul 86 08:49:56 PDT
From: Richard Fateman <fateman@DALI.BERKELEY.EDU>
Message-Id: <8607311549.AA17087@dali.Berkeley.EDU>
To: Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU,
scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: Re: Performance and Evaluation of Scheme Systems...
since the programs used for timing were allowed to be different from
the ones in RPG's book, (e.g. declarations) and at least some of the
programs are unrunnnable as given, the benchmark timings are somewhat
less useful than you might think. If YOU run them benchmarks on various
machines/lisps, you may get much different numbers.
∂04-Aug-86 0107 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 86 01:07:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Aug 86 03:41:37 EDT
Received: from waterloo by csnet-relay.csnet id ac03100; 4 Aug 86 3:32 EDT
Received: from cantuar.uucp by watmath; Mon, 4 Aug 86 03:02:42 edt
Date: Mon, 4 Aug 86 18:50:44+1200
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: SCHEME <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:SCHEME@MC.LCS.MIT.EDU>
Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme
We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please
reply through either: wolfgang%cantuar@waterloo.csnet OR
...watmath!cantuar!wolfgang. Thanks. w.kreutzer Univ. of Canterbury, NZ
∂04-Aug-86 0158 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 86 01:58:15 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 4 Aug 86 03:41:30 EDT
Received: from waterloo by csnet-relay.csnet id ab03100; 4 Aug 86 3:31 EDT
Received: from cantuar.uucp by watmath; Mon, 4 Aug 86 03:02:07 edt
Date: Mon, 4 Aug 86 18:50:44+1200
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: SCHEME <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:SCHEME@MC.LCS.MIT.EDU>
Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme
We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please
reply through either: wolfgang%cantuar@waterloo.csnet OR
...watmath!cantuar!wolfgang. Thanks. w.kreutzer Univ. of Canterbury, NZ
∂06-Aug-86 0150 @MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 86 01:50:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 6 Aug 86 04:49:37 EDT
Received: from waterloo by csnet-relay.csnet id aa13776; 6 Aug 86 4:32 EDT
Received: from cantuar.uucp by watmath; Wed, 6 Aug 86 03:54:00 edt
Date: Wed, 6 Aug 86 19:30:29 nzt
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: scheme <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:scheme@MC.LCS.MIT.EDU>
Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme
We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please
reply through either: wolfgang%cantuar@waterloo.csnet OR
...watmath!cantuar!wolfgang. Thanks. w.kreutzer Univ. of Canterbury, NZ
∂07-Aug-86 0136 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU non-list arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86 01:35:52 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 AUG 86 04:34:17 EDT
Date: Thu, 7 Aug 86 04:30:58 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: non-list arguments
To: rhh@MC.LCS.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU, t-discussion@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 1 Apr 86 15:26 EST from Robert Halstead <rhh at MIT-VAX.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].939050.860807.JAR>
Date: Tue, 1 Apr 86 15:26 EST
From: Robert Halstead <rhh at MIT-VAX.ARPA>
To summarize, I think it should be permissible for
(eq? ((lambda x x) l) l)
to return true, but it should not be a requirement. Furthermore, it
should be permissible for an implementation to report an error if l in
the above expression is not a true list, but an implementation should
not be required to do so. Of course, it would still be true that
((lambda x x) 3 4 5)
would return a freshly consed list, just like (list 3 4 5). An
interesting question: do people expect (apply list l) to return a
top-level copy of l? -b.
Permitting sharing between the argument passed to apply and the
rest-argument leads to all kinds of obscure bugs - especially if sharing
isn't guaranteed. In fact I have written and used interpreters which
shared the list, and I regretted it every time. Efficiency shouldn't
guide the design on this issue. A compiler could easily detect the
situation you described (a rest-variable referenced only as the last
argument to APPLY) and generate code which doesn't cons.
Jonathan
∂07-Aug-86 0301 @MC.LCS.MIT.EDU:Pase@DOCKMASTER.ARPA Scheme for the Atari ST
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86 03:01:42 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 AUG 86 06:00:12 EDT
Received: from DOCKMASTER.ARPA by MC.LCS.MIT.EDU 4 Apr 86 16:23:17 EST
Date: Fri, 4 Apr 86 00:59 EST
From: Bill Pase <Pase@DOCKMASTER.ARPA>
Subject: Scheme for the Atari ST
To: scheme@MIT-MC.ARPA
Message-ID: <860404055925.041933@DOCKMASTER.ARPA>
Does anyone know if Scheme is available for the Atari ST? I know there
are versions for the IBMPC and the Macintosh. It wouIt would seem
especially with the later that an Atari version should be easy. Does
anyone have any plans to develop it? /bill
∂07-Aug-86 0730 @MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA Re: Scheme for the Atari ST
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86 07:30:35 PDT
Received: from ORNL-MSR.ARPA by MC.LCS.MIT.EDU 7 Aug 86 10:29:37 EDT
Received: by ORNL-MSR.ARPA (4.12/4.9)
id AA05596; Thu, 7 Aug 86 10:24:46 edt
Date: Thu, 7 Aug 86 10:24:46 edt
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8608071424.AA05596@ORNL-MSR.ARPA>
To: scheme@mit-mc
Subject: Re: Scheme for the Atari ST
from Bill Pase (Pase@DOCKMASTER.ARPA)
>Does anyone know if Scheme is available for the Atari ST?
I recently asked similar questions here, which lead me to some
history which may be helpful. I'll summarize what I've learned from
people on this list and the archives.
The archives for this group contain some references to "Scheme 312".
This is the ancestor of MacScheme. MacScheme is actually being
developed on the Stride (Sage) computer under the CP/M-68K operating
system, so the author has an decent version working in that
environment. (The author is not interested in distributing or
supporting that version, however).
I have heard that the Atari ST runs GEM on top of CP/M-68K (or a
minor mutation of CP/M). If this is true, it might be easy to port
to the Atari -- maybe easier than porting to the Mac. Perhaps the
author is not aware of this possibility and would be interested in
doing the port?
The author's name is Will Clinger, and he used to be at
willc%indiana.csnet@csnet-relay.arpa which is Indiana U on CSnet
from my ARPAnet BSD Unix machine. I'm not sure if he monitors this
list... The MacScheme distributor address:
Semantic Microsystems
4470 SW Hall Street, Suite 340
Beaverton OR 97005
(503) 643-4539
Dave Alcocer (alco@mit-vax) was working with CScheme. He says this
public domain version is portable. Dave said he was interested
having it on his Amiga, but it might need to be trimmed down from
approximately 2 megabytes by removing some trimmings.
Wouldn't it be amazing to see a group of Mac, Amiga, and ST owners
cooperating on a public domain Scheme!
The GNU project has started distributing CScheme. I'm not sure why
they have decided to do so.
Good Luck -
- jim mullens / oak ridge national lab
∂08-Aug-86 0819 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86 08:19:18 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 AUG 86 11:18:43 EDT
Date: Fri, 8 Aug 86 11:16:47 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
To: wolfgang%cantuar%waterloo.csnet@CSNET-RELAY.ARPA
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 6 Aug 86 19:30:29 nzt from Facilities Committee <facility%cantuar.waterloo.edu at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].80950.860808.JAR>
Date: Wed, 6 Aug 86 19:30:29 nzt
From: Facilities Committee <facility%cantuar.waterloo.edu at CSNET-RELAY.ARPA>
To: scheme < at CSNET-RELAY.ARPA, at watmath.waterloo.edu:scheme@MC.LCS.MIT.EDU>
Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme
We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please
reply through either: wolfgang%cantuar@waterloo.csnet OR
...watmath!cantuar!wolfgang. Thanks. w.kreutzer Univ. of Canterbury, NZ
Implementation: Chez Scheme
Authored by: Kent Dybvig
Supported by: limited support by the author
Hardware: VAX
Operating Systems: 4.2 BSD UNIX (or ULTRIX)
Implementation: incrementally compiled to native code
Intended Use: education and research
Price: Per site: $400 for US colleges and universities,
and $1000 for companies who will use the
system for research and education only.
Chez Scheme was first released earlier this year and is now being used
at about 10 universities for classes and research. Chez Scheme supports
almost all of the required and optional features of the RRRS. The next
major release (in spring or summer 1986) will support 100% of the
required features of the standard.
In addition to the features of the RRRS, Chez Scheme provides error and
exception handling, engines, programmable cafes and waiters (fancy
read-eval-print loops), tracing and statistics- gathering facilities,
and fast-loading compiled files. Chez Scheme provides floating point
numbers, arbitrary-precision ratios, and arbitrary-precision integers,
but no imaginary numbers at this time.
Chez Scheme's biggest claim to fame is the speed and size of its
implementation. It outperforms Franz Lisp and DEC Common Lisp on most
programs, but the initial core image is less than 500K bytes, about half
of which is read-only and sharable.
For the license forms and ordering information, contact:
Kent Dybvig
Cadence Research Systems
620 Park Ridge Road
Bloomington, IN 47401
812/333-9269
You can also reach me during the day at 812/335-8653, or by electronic
mail to dyb.indiana@csnet-relay.
∂08-Aug-86 1230 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [Masinter.pa: synonym streams..]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86 12:29:48 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 AUG 86 11:20:48 EDT
Date: Fri, 8 Aug 86 11:19:12 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [Masinter.pa: synonym streams..]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].80953.860808.JAR>
How about a similar rule for Scheme? With the obvious extension to ports created by
with-input-file, etc.
- Jonathan.
Date: 5 Aug 86 11:09 PDT
From: Masinter.pa at Xerox.COM
To: common-lisp at su-ai.ARPA
Re: synonym streams..
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 5 Aug
86 09:05 PDT
Message-ID: <860805-111034-2460@Xerox>
I propose the following rule: "It is an error to attempt to close a
stream that wasn't created with open."
With this rule, it would follow that, since synonym, broadcast and
two-way streams are not created with open, it is an error to perform
"close" on them.
∂08-Aug-86 1712 @MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA "Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86 17:12:33 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Aug 86 20:16:20 EDT
Received: from ti-csl by csnet-relay.csnet id ai03255; 8 Aug 86 18:15 EDT
Received: by tilde id AA15700; Fri, 8 Aug 86 15:48:46 cdt
Date: Fri 8 Aug 86 15:20:50-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: "Final" comments on RRRRS
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12229239846.30.BARTLEY@CSC60>
Before I go on vacation, I'd like to submit a (very) few comments on the
current draft report for consideration for the SIGPLAN revision.
-- I'm very pleased with its appearance and happy that it was distributed
to all of the attendees at the LISP conference. Thanks again to Jonathon.
-- Kent Dybvig has asked that the colon (:) be removed from the set of
extended alphabetic characters (section 2.3). I agree completely. My
joint implementations of Scheme and Common LISP need a reasonable syntax
for Scheme procedures to refer to symbols in various Common LISP packages.
Using Common LISP's syntax seems best.
-- Reference [2] to our conference paper on PC Scheme may now be updated
to refer to pages 86-93 of the proceedings. The same goes for reference
[6] by Dybvig, Friedman, and Haynes. Reference [51] to the TI Scheme
manual should be changed from ``preliminary version 1.0, November 1985''
to ``Original issue: December 1985''.
-- I hope that Jonathon will be able to incorporate our proposed number
syntax.
Regards,
David Bartley
-------
∂11-Aug-86 0855 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:SRAUCH@UNBMVS1.BITNET Instructor's manual for S&ICP by Julie Sussman
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 86 08:55:45 PDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 11 Aug 86 11:50:28 EDT
Received: from UNBMVS1(MAILER) by MITVMA (Mailer X1.23) id 8365;
Mon, 11 Aug 86 11:48:58 EDT
Date: 11 Aug 86 10:34:28 ADT
From: <SRAUCH@UNBMVS1>
To: scheme@mc.lcs.mit.edu
Subject: Instructor's manual for S&ICP by Julie Sussman
Message-ID: <ID45752.D860811.T103428.SRAUCH@UNBMVS1>
- Can anyone tell me whether the "Instructors Manual" for
Structure and Interpretation of Computer Programs by Abelson and
Sussman, written by Julie Sussman is available? If so, how can it be
obtained? McGraw-Hill Canada doesn't seem to have heard of it. Any help
with this would be greatly appreciated.
Steve R.
SRAUCH@UNBMVS1.BITNET
∂13-Aug-86 0238 NET-ORIGIN@MC.LCS.MIT.EDU Re: define
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 86 02:38:35 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 AUG 86 05:32:10 EDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Apr 86 00:50:16 EST
Received: from tektronix by csnet-relay.csnet id ak29970; 17 Apr 86 0:43 EST
Received: by tektronix (5.31/5.14)
id AA20915; Wed, 16 Apr 86 13:06:21 PST
Received: by tekchips (5.31/5.14)
id AA02612; Wed, 16 Apr 86 13:06:41 PST
Date: Wed, 16 Apr 86 13:06:41 PST
From: Will Clinger <willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <8604162106.AA02612@tekchips>
To: SCHEME%MIT-MC%tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: define
Cc:
Roger Kirchner writes:
>Kent M Pitman said that there are other possible interpretations of
>(DEFINE (((...) ...) ...) ...)
>besides as an extended template for procedure definition.
>What would be the objections to making this interpretation standard?
Your interpretation is already standard, though not essential; see
page 18 of MIT AI Memo 848. Though other interpretations are possible,
they would be in conflict with the Revised Revised Report.
The extended syntax began in MIT Scheme and was picked up by MacScheme
and PC Scheme. T2 doesn't support it. I don't know about Chez Scheme
et cetera.
Peace, Will
∂14-Aug-86 1728 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Minutes from lunch 5 August 1986
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 17:28:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 20:27:24 EDT
Received: from tektronix by csnet-relay.csnet id aa00212; 14 Aug 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA09292; Thu, 14 Aug 86 12:57:59 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA24878; Thu, 14 Aug 86 13:00:49 PDT
Message-Id: <8608142000.AA24878@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Minutes from lunch 5 August 1986
In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT.
<[AI.AI.MIT.EDU].77171.860729.JAR>
Date: 14 Aug 86 13:00:46 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Minutes from lunch on Tuesday, 5 August 1986
Attendance was not taken.
Jonathan Rees was congratulated on getting a draft of the R↑3RS done in
time for the conference.
After lunch we drew up a list of language areas that need work. In a few
of these areas we have proposals on the table, while a few others are
difficult research areas:
ERRORS & INTERRUPTS. What are the errors? How are they signalled?
How are the handlers found, what do they do, how are they defined?
What about I/O devices?
OPAQUE TYPES. Three new procedures have been proposed for creating
and manipulating objects that answer false to all the standard type
predicates and cannot be taken apart by any of the standard deconstructors.
One procedure -- call it INJECT -- takes two objects and returns a new
opaque object consisting of the first object tagged by the second.
The second procedure -- call it IN? -- takes two objects and returns
true if the first object was created by calling INJECT with the second
object as the tag, and returns false otherwise. The third procedure --
call it PROJECT -- takes an opaque object and a tag object and returns
the object encapsulated by the opaque object provided the tags match.
Axiomatically:
(IN? (INJECT x y) y) ==> #t
(IN? (INJECT x y) z) ==> #f provided (NOT (EQV? y z))
(PROJECT (INJECT x y) y) ==> x
MACROS. Difficult research area. We're awaiting Eugene Kohlbecker's
thesis.
DYNAMIC-WIND. DYNAMIC-WIND seems like a good generalization of
UNWIND-PROTECT, but what about multiprocessing? Should an UNWIND/WIND
occur on every process switch? What about I/O? The formal semantics
of DYNAMIC-WIND is very operational, which I take to be a danger signal.
INPUT/OUTPUT. What should happen to the current ports on a process
switch? What should happen if the debugger gains control? What should
happen if a transcript is desired?
SYNCHRONIZATION. Ought to have some means of synchronization before we
have multiple processes.
MODULE SYSTEM. First class environments do most things right, but they
render inter-module constant folding (e.g. procedure integration)
impractical. I think we're finally agreed that the issue of first class
environments can usefully be separated from the question of incremental
definitions as used in S&ICP, and I don't think anyone is enthusiastic
about Common Lisp style packages as a mechanism for modularity.
SEMANTICS OF QUASIQUOTE, QUOTE. In question are things like (EQ? '(A) '(A))
and (SET-CAR! `(A B ,C) 3) and (SET-CAR! `(A B ,@C) 3). Does it matter to
the last two examples whether the compiler can determine that C is a
constant?
DECLARATIONS. It is important to be able to say things like "CAR is a
constant", "N is an exact nonnegative integer less than 2↑20", "This
procedure should be optimized for speed at the expense of space but
not safety". Which declarations signal an error if violated, and which
are merely hints for better performance? What is the syntax and scope
of a declaration?
SYNTAX CHECKER & CANONIZER. How about a program that converts programs
written in full Scheme into a canonical form that uses only the primitive
expressions, checking syntax as it does so? Tektronix has volunteered to
supply such a program.
VERIFICATION SUITE. How about a verification suite to locate bugs?
Someone volunteered to coordinate this, but I'm not sure I remember
who it was, so please re-volunteer.
BENCHMARK SUITE. This wasn't discussed at lunch, but I talked to
several people who would like to have a benchmark suite that generates
more meaningful and more easily interpreted numbers than do the Gabriel
benchmarks. For example, the Gabriel benchmarks test property lists
and fluid variables but don't do anything with lexical closures.
MULTIPLE RETURN VALUES. Two new procedures have been proposed for
multiple return values. One procedure -- call it RETURN -- takes
arbitrarily many values and returns them. The other procedure --
call it RECEIVE-VALUES -- takes a thunk and a procedure, and calls
the procedure on the (possibly multiple) values returned by the
thunk. The semantics that appears in R↑3RS was designed to work
with multiple return values, but we might want to change the help
function "single" so that extra return values (e.g. in the test
position of a conditional) are ignored as in Common Lisp. (With
the current version of "single", extra return values would be an
error.) Since RETURN doesn't do anything remotely like what RETURN
does in Common Lisp (and is identical to CL's VALUES function),
we might want to discuss the name. We might also want to discuss
the argument order for RECEIVE-VALUES.
OPTIONALS. Should there be a special syntax for optional arguments
so we don't have to use a rest argument and destructure it ourselves?
What should the syntax be?
∂14-Aug-86 1855 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: Minutes from lunch 5 August 1986
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 18:55:39 PDT
Received: from Sushi.Stanford.EDU by MC.LCS.MIT.EDU 14 Aug 86 21:34:10 EDT
Date: Thu 14 Aug 86 18:30:00-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Minutes from lunch 5 August 1986
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8608142000.AA24878@tekchips.TEK>
Message-ID: <12230868993.15.ANDY@Sushi.Stanford.EDU>
I'd be happier if the Scheme community said nothing about
multitasking, multiprocessing, or anything related to parallelism.
This isn't intended to discourage informal communication, but any hint
of agreement/standardization is premature.
Why is this coming up now anyway? We don't understand macros, errors,
interrupts, declarations, etc.
I'd rather have (hash) tables than project/inject/in?.
-andy
-------
∂14-Aug-86 2053 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA substring indexes
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 20:51:53 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 23:00:21 EDT
Received: from tektronix by csnet-relay.csnet id ab00212; 14 Aug 86 18:46 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA09635; Thu, 14 Aug 86 13:06:50 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA25920; Thu, 14 Aug 86 13:09:35 PDT
Message-Id: <8608142009.AA25920@tekchips.TEK>
To: kend%tekla.tek.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: substring indexes
In-Reply-To: Your message of 13 Aug 86 08:37:36 PDT (Wed).
<8608131537.AA25142@tekla.TEK>
Date: 14 Aug 86 13:09:33 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
The following comes from Ken Dickey (kend@tekla). I favor changing
the description of substring-fill! to say START *to* END. Peace, Will.
----------------------------------------------------------------
Will,
I have not yet read the full report, but R-cubed is a significant
improvement over R-squared. I did find section 6.7 on strings,
however, to be somewhat confusing. Some functions (eg substring) use
START *to* END, while others (eg substring-fill!) use START *through*
END.
I think it would be better to either maintain
0 <= START <= END < (string-length <string>)
XOR use 1 based indexing.
In both cases, I favor using start through end (both inclusive). The
latter is probably more in keeping with the spirit of Scheme in that
one based indexing seems more natural to naive programmers**.
Pax,
-Ken
-------------
** (based on my experience teaching Pascal and C).
∂14-Aug-86 2233 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA r-cubed syntax (nits)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 22:33:27 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 00:58:33 EDT
Received: from tektronix by csnet-relay.csnet id ag02938; 15 Aug 86 0:47 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA10107; Thu, 14 Aug 86 13:55:24 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA01706; Thu, 14 Aug 86 13:58:17 PDT
Message-Id: <8608142058.AA01706@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: r-cubed syntax (nits)
In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT.
<[AI.AI.MIT.EDU].77171.860729.JAR>
Date: 14 Aug 86 13:58:14 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
The following comes from Ken Dickey (kend%tekla@tek.csnet; my previous
note said kend@tekla, but I don't think that works unless you're at
Tektronix.).
----------------------------------------------------------------
Will,
parsimony: 7.1.1: <suffix>:
<digit> <digit>*
can be written <digit>+
ambiguity?: 7.1.3: <case clause> and <cond clause> both allow
(else <sequence>)
to be any clause, rather than the last clause. Is this intentional?
Again, let me say that this is the best language spec that I have read
in some time (I still have 7.2 to slog through).
-Ken
∂15-Aug-86 0902 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA Re: Minutes from lunch 5 August 1986
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86 09:02:09 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 11:50:44 EDT
Received: from indiana by csnet-relay.csnet id aa07414; 15 Aug 86 11:12 EDT
Date: Fri, 15 Aug 86 00:51:46 est
From: "R. Kent Dybvig" <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: Re: Minutes from lunch 5 August 1986
It was I who volunteered to coordinate the verification suite.
Kent
∂15-Aug-86 1106 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU r-cubed syntax (nits)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86 11:06:33 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 13:46:41 EDT
Date: Fri, 15 Aug 86 13:47:03 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: r-cubed syntax (nits)
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 14 Aug 86 13:58:14 PDT (Thu) from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Message-ID: <[AI.AI.MIT.EDU].84074.860815.JAR>
Date: 14 Aug 86 13:58:14 PDT (Thu)
From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
parsimony: 7.1.1: <suffix>:
<digit> <digit>*
can be written <digit>+
OK, will fix.
ambiguity?: 7.1.3: <case clause> and <cond clause> both allow
(else <sequence>)
to be any clause, rather than the last clause. Is this intentional?
I had it this way for a while, and decided that it was unnecessary
clutter in the syntax. You need to give two rules instead of one for
the syntax of cond (and case), and it looks really bad. But the fact
that someone noticed & cared is probably enough to indicate that I
should change it back to the more verbose, pedantic form.
∂15-Aug-86 1112 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU scheme report tar file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86 11:10:55 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 13:57:24 EDT
Date: Fri, 15 Aug 86 13:57:51 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: scheme report tar file
To: goodhart@NOSC-COD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 6 Aug 86 10:26:55 PDT from Curtis L. Goodhart <goodhart%cod at nosc.ARPA>
Message-ID: <[AI.AI.MIT.EDU].84083.860815.JAR>
OK, there's now a tar file for the draft of the scheme report on host
MIT-PREP in the file "/u/jar/r3rs.tar". Use user scheme password scheme
if user & password are required. The tar file is about .25 Mbytes.
Sorry this took so long.
Jonathan
∂15-Aug-86 1223 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU "Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86 12:23:14 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86 15:22:24 EDT
Date: Fri, 15 Aug 86 15:22:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: "Final" comments on RRRRS
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 8 Aug 86 15:20:50-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].84135.860815.JAR>
Date: Fri 8 Aug 86 15:20:50-CDT
From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
-- Kent Dybvig has asked that the colon (:) be removed from the set of
extended alphabetic characters (section 2.3). I agree completely. My
joint implementations of Scheme and Common LISP need a reasonable syntax
for Scheme procedures to refer to symbols in various Common LISP packages.
Using Common LISP's syntax seems best.
I have no strong objection to this. It's conceivable that it could be
construed by the uninitiated as an endorsement of read-time packaging,
but I think we should be able to guard against that.
I would like to hear from people who object to the this (Hanson?)
before making the change. If the screams aren't too loud I'll do it.
-- I hope that Jonathan will be able to incorporate our proposed number
syntax.
Sorry, I just won't have time to work on it, and I don't think there's
time for proper review. If you could prepare the changes in fine detail
(maybe edit the TeX sources yourself), this might be feasible, but a
last-minute change of this magnitude is bound to have problems with it.
Probably it would be best to just include a statement to the effect that
this change is being considered for a future revision of the report.
Jonathan
∂15-Aug-86 2150 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU "Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86 21:50:17 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 AUG 86 00:49:37 EDT
Date: Sat, 16 Aug 86 00:50:15 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: "Final" comments on RRRRS
To: JAR@AI.AI.MIT.EDU
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 15 Aug 86 15:22:44 EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].84332.860816.CPH>
Date: Fri, 15 Aug 86 15:22:44 EDT
From: Jonathan A Rees <JAR at AI.AI.MIT.EDU>
To: Bartley%ti-csl.csnet at CSNET-RELAY.ARPA
Date: Fri 8 Aug 86 15:20:50-CDT
From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
-- Kent Dybvig has asked that the colon (:) be removed from
the set of extended alphabetic characters (section 2.3). I
agree completely. My joint implementations of Scheme and
Common LISP need a reasonable syntax for Scheme procedures to
refer to symbols in various Common LISP packages. Using
Common LISP's syntax seems best.
I have no strong objection to this. It's conceivable that it could be
construed by the uninitiated as an endorsement of read-time packaging,
but I think we should be able to guard against that.
I would like to hear from people who object to the this (Hanson?)
before making the change. If the screams aren't too loud I'll do it.
I guess that I should respond to this. I really, truly abhor the
read-time package system and would strenuously object to any such
thing being introduced into Scheme. I have gone out of my way (a
little) to use colons in my code just to parody the package system
and, unfortunately, that would make my code non-portable given this
decision.
Understand, I have no really serious objections to this suggestion,
except that if anyone tries to define what `:' means when it appears
in an identifier, I promise to raise heck. But I don't mind agreeing
to disagree about it.
And, of course, anyone who implements this change will not be able to
port my code without significant rewriting. Sigh. I guess that would
be your loss, not mine.
(Seriously, though, what would the symbol
`rtl:interpreter-call:lookup' mean in a system with such a syntax?)
∂18-Aug-86 0051 @MC.LCS.MIT.EDU:ram@YALE.ARPA Re: The generality of define
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 00:51:37 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 AUG 86 03:41:46 EDT
Received: from yale-bulldog by MC.LCS.MIT.EDU 23 Apr 86 21:58:42 EST
Received: by Yale-Bulldog.YALE.ARPA; 23 Apr 86 21:46:26 EST (Wed)
Date: 23 Apr 86 21:46:26 EST (Wed)
From: Ashwin Ram <ram@YALE.ARPA>
Message-Id: <8604240246.AA12180@Yale-Bulldog.YALE.ARPA>
Subject: Re: The generality of define
To: andy@aids-unix.ARPA (Andy Cromarty)
Cc: SCHEME@MC.LCS.MIT.EDU
In-Reply-To: andy@aids-unix.ARPA (Andy Cromarty), Wed, 23 Apr 86 19:09:53 EST
Date: 21 Apr 1986 09:43-PST
From: andy@aids-unix (Andy Cromarty)
Subject: Re: The generality of define
Actually, a properly implemented
(define (square x) (* x x))
is not equivalent to
(define square (lambda (x) (* x x)))
at all, but rather to
(define square (rec square (lambda (x) (* x x))))
(define (fact1 n)
(if (<? n 2)
1
(* n (fact1 (-1+ n)))))
(define fact2
(lambda (n)
(if (<? n 2)
1
(* n (fact2 (-1+ n))))))
asc
-------
In T there is *no* difference between these two forms (except that you
get a named-lambda in the first case rather than a lambda).
> (pp copy1)
(LAMBDA (N) (IF (<? N 2) 1 (* N (FACT1 (-1+ N))))) <<<<| Both closed
| in the same
> (pp copy2) | environment.
(LAMBDA (N) (IF (<? N 2) 1 (* N (FACT2 (-1+ N))))) <<<<|
> (copy1 5)
20
> (copy2 5)
20
This makes sense to me since (DEFINE (FOO ...) ...) is specified to
be equivalent to (DEFINE FOO (LAMBDA (...) ...)). In both cases, FOO is
defined to be a closure whose environment is the environment of definition,
i.e., the REPL-ENV.
To get the definition analogous to your REC case, you need to use LABELS
explicitly:
> (define fact3
(labels (((fact3 n) (if (< n 2) 1 (* n (fact3 (-1+ n))))))
fact3))
> (define copy3 fact3)
> (define fact3 (lambda (x) x))
> (copy3 5)
120
It might make more sense to make this the default expansion since you
would usually expect the recursive call to refer to the definition-time
procedure (as opposed to its "name"), though now the variables FACT3 and
N have different reference semantics within the same form. In the case of
two or more mutually recursive functions, you still have to rely on the
run-time values of the cells that the variables in the closure refer to
in the environment that the closure was defined in. It's debatable,
therefore, whether special reference semantics for the name of the lambda
form is the "proper implementation", though it does seem more natural
albeit hairier.
-- Ashwin.
-------
∂18-Aug-86 1650 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA define syntax (an apology)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 16:50:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 18 Aug 86 19:44:47 EDT
Received: from tektronix by csnet-relay.csnet id ac01742; 18 Aug 86 18:44 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA07543; Mon, 18 Aug 86 10:42:41 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA03638; Mon, 18 Aug 86 10:45:31 PDT
Message-Id: <8608181745.AA03638@tekchips.TEK>
To: scheme@MC.LCS.MIT.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: define syntax (an apology)
In-Reply-To: Your message of Fri, 15 Aug 86 13:47:03 EDT.
<[AI.AI.MIT.EDU].84074.860815.JAR>
Date: 18 Aug 86 10:45:30 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
A message I sent several months ago recently made it to this mailing list.
By now, my message is incorrect. I wish to apologize for the confusion I
have caused.
There is an important difference between the 1985 Scheme standard (MIT AI
Memo 848) and the draft of the new 1986 Scheme standard (distributed at
the ACM Conference on Lisp and Functional Programming and expected to
appear in November SIGPLAN Notices). In the 1985 standard
(define (foo ...) ...)
was equivalent to
(define foo (rec foo (lambda (...) ...))).
In the 1986 standard (define (foo ...) ...) is equivalent to
(define foo (lambda (...) ...)).
As I understand it, the motivation for this change is that in the 1985
semantics, mutual recursion goes through the obvious binding of foo,
but self-recursion goes through the invisible (and therefore mysterious)
binding of foo created by the implicit rec. It's hard to explain why
self-recursion should behave differently from mutual recursion, so the
1986 semantics gets rid of the implicit rec and the mystery.
This change was inadvertently omitted from the list of changes that
appears in the draft distributed at the Lisp conference, so you have
to read the draft very carefully to spot it. By the way, the
(define ((foo ...) ...) ...) syntax was also dropped from the draft
as a simplifying measure.
Peace, Will
∂20-Aug-86 2002 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA numbers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 86 20:02:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 20 Aug 86 23:02:06 EDT
Received: from tektronix by csnet-relay.csnet id ag24407; 20 Aug 86 22:44 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA21860; Wed, 20 Aug 86 17:10:36 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA03947; Wed, 20 Aug 86 17:13:22 PDT
Message-Id: <8608210013.AA03947@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA,
adams%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: numbers
In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT.
<12223161873.35.BARTLEY@CSC60>
Date: 20 Aug 86 17:13:20 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Abstract: Scheme numbers are still inadequately specified in several
respects. I propose several improvements. Some are minor enough to
deserve incorporation in the SIGPLAN Notices publication of the Revised↑3
Report, but the others probably deserve more debate.
Some problems that I perceive with Scheme numbers are:
1. The quotient procedure is not adequately specified.
2. The floor etc procedures are not adequately specified.
3. The syntax for numbers has a redundancy.
4. The integer? procedure may not be adequately specified.
5. Valid indexes may not be adequately specified.
6. The read and string->number procedures are not adequately specified.
(David Bartley has also suggested that the syntax should be made more
compatible with Common Lisp and has proposed that the report be clearer
on which parts of the number syntax are essential and which are not
essential.)
1. Norman Adams pointed out to me that it is unclear from the description
of quotient in 6.5.4 whether (quotient -13 4) should be -3 or -4; likewise
(quotient 13 -4). I propose that the sentence beginning "For positive
integers n1 and n2" be followed by the sentence
For all integers n1 and n2 with n2 not equal to 0,
(= n1 (+ (* n2 (quotient n1 n2)) (remainder n1 n2))) ==> #t
2. In the description of floor, ceiling, truncate, round, and rationalize,
the sentence "Their results are not exact---in fact, their results are
clearly inexact, though they can be made exact with an explicit exactness
coercion" is incorrect. I propose that the sentence be replaced by "Their
results are exact if and only if their arguments are exact."
3. The third production for <ureal R> is redundant.
4. In MacScheme and a few other implementations, (integer? 4.0) evaluates
to #f. Even assuming that 4.0 is inexact, this seems wrong. I would like
to see an example in the report to show that it's wrong.
5. I believe the index or size arguments to list-tail, list-ref,
make-string, string-ref, string-set!, substring-fill!, make-vector,
vector-ref, and vector-set! should be required to be exact integers
instead of just integers.
6. It isn't clear from the report whether 3.0 reads as an exact or inexact
number. Indeed the same can be said of 3, or 3/1, or 3###-4###i. I propose
that this sort of thing be specified more formally, as in the following
example---which does not match up very well with the syntax and is not my
favorite proposal anyway.
exactness [ <real> + <ureal> i ] = exactness [ <real> - <ureal> i ]
= minexact (exactness [ <real> ], exactness [ ureal ])
exactness [ <real←1> @ <real←2> ]
= minexact (exactness [ <real←1> ], exactness [ <real←2> ]
exactness [ <sign> <ureal> ] = exactness [ <ureal> ]
exactness [ <prefix> <x> <suffix> ]
= if explicit [ <prefix> ]
then prexact [ <prefix> ]
else if empty [ <suffix> ]
then exactness [ <x> ]
else #f ; this is what I don't like
exactness [ <uinteger> <suffix> ]
= if empty [ <suffix> ] then exactness [ <uinteger> ] else #f
exactness [ <digit>+ #+ ] = #f
exactness [ <digit>+ ] = #t
exactness [ <uinteger←1> / <uinteger←2> ]
= minexact (exactness [ <uinteger←1> ], exactness [ <uinteger←2> ])
exactness [ <digit>+ #+ ] = #f
exactness [ <digit>+ ] = #t
exactness [ <digit>* . <digit>+ #* ] = #f
exactness [ <digit>* . #+ ] = #f
exactness [ <digit>+ . ] = #t
exactness [ <digit>+ #+ . ] = #f
minexact (b1, b2) = if b1 then b2 else #f
explicit [ ... #i ... ] = explicit [ ... #e ... ] = #t
explicit [ ... <empty exactness> ... ] = #f
prexact [ ... <exactness> ... ] = prexact [ <exactness> ]
prexact [ #i ] = #f
prexact [ #e ] = #t
Peace, Will
∂22-Aug-86 0555 @MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA a few more comments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86 05:38:43 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Aug 86 08:38:51 EDT
Received: from indiana by csnet-relay.csnet id ac02619; 22 Aug 86 8:33 EDT
Date: Fri, 22 Aug 86 03:03:54 est
From: "R. Kent Dybvig" <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: a few more comments
It may be too late to bother with any of this, but here are a few
comments on the R3RS copy handed out at the conference.
Functionality
-------------
char-ready? looks too much like char-lower-case?, char-alphabetic?,
etc., and not enough like read-char. I think read-char-ready? would
be much more appropriate. Besides, some implementation or future
RnRS may want to have a write-char-ready?. Is there any reason not
to change the name?
In the number formats, the syntax (exactness) is used within two of
the examples of 6.5.6, but this form is not explicitly allowed in
6.5.7. My feeling is that the modifier s or e should be required,
as implied in 6.5.7. The formats are pretty complicated as is.
What happens on string<?, string>?, string<=?, string>=?, string-ci<?,
string-ci>?, string-ci<=?, string-ci>=? when one string is longer
than the other? I would add "If two strings differ in length but
are the same up to the length of the shorter string, the shorter string
is considered to be lexographically less than the longer string".
The procedure substring-fill! is the only procedure left that sticks
out to me as unnecessary and rarely useful. Perhaps someone can
explain to me why it should be in the standard.
Why is there not a vector-null? function..., or why not delete null?
and string-null? to be consistent?
Presentation
------------
1.3.1 strike the word "will"
2.1 it is not clear what "extended alphabetic characters" are here;
I think that the list should be moved here from 2.3, which is, after
all, titled "other" notations. At the least, a forward pointer is
needed.
2.1 last sentence, replace "between" with "among"
2.3 mention that ) is used to close a vector constant
6.9 optional if syntax should not be used in example
True Nitpick
------------
7.3 in first case description...
(let ((key <key> )
↑ extra space
Kent
∂22-Aug-86 1208 @MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 1986 Lisp conference bibliography
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86 12:07:06 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:08:11 EDT
Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt
Date: Fri, 22 Aug 86 14:06 EDT
From: Guy Steele <gls@Think.COM>
Subject: 1986 Lisp conference bibliography
To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM>
With the help of Bill Scherlis, I have massaged the table of contents
(with some corrections) for the 1986 ACM Conference on Lisp and
Functional Programming into the form of a bibliography database suitable
for use with LaTeX/BibTeX and (almost) SCRIBE. The database has been
tested with BibTeX, and uses TeX conventions for forcing capitalization
and for accenting characters (there are three accents acute, one umlaut,
and one "i" with a circumflex over it). The database should require
only slight modification to make it suitable for use with SCRIBE.
I am mailing out the database in the interest of making it easier for
everyone to refer to all these great papers from the conference. The
database follows at the end of this message, followed by the BibTeX
transcription of it for a bibliography format very similar to that
required by CACM. (I considered just mailing out a pointer to an
FTP-able file, but I find that in practice this method is rather clumsy
and people don't use it.)
--Guy
----------------------------------------------------------------
@InProceedings(LAWS-IN-MIRANDA
,Key = "Thompson"
,Author = "Simon Thompson"
,Title = "Laws in {M}iranda"
,Pages = "1-12"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(MINI-ML
,Key = "Clement"
,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn"
,Title = "A Simple Applicative Language: {M}ini-{ML}"
,Pages = "13-27"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING
,Key = "Gifford"
,Author = "David K. Gifford and John M. Lucassen"
,Title = "Integrating Functional and Imperative Programming"
,Pages = "28-38"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP
,Key = "Alberga"
,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget"
,Title = "Experience with an Uncommon {L}isp"
,Pages = "39-53"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP
,Key = "Padget"
,Author = "Julian Padget and others"
,Title = "Desiderata for the Standardisation of {L}isp"
,Pages = "54-66"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP
,Key = "Brooks"
,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel"
,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp"
,Pages = "67-85"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(IMPLEMENTATION-OF-PC-SCHEME
,Key = "Bartley"
,Author = "David H. Bartley and John C. Jensen"
,Title = "The Implementation of {PC} {S}cheme"
,Pages = "86-93"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES
,Key = "Fairbairn"
,Author = "Jon Fairbairn and Stuart C. Wray"
,Title = "Code Generation Techniques for Functional Languages"
,Pages = "94-104"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES
,Key = "Knight"
,Author = "Tom Knight"
,Title = "An Architecture for Mostly Functional Languages"
,Pages = "105-112"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION
,Key = "Lemaitre"
,Author = "M. Lema\↑\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan"
,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction"
,Pages = "113-121"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CURRY-CHIP
,Key = "Ramsdell"
,Author = "John D. Ramsdell"
,Title = "The {CURRY} Chip"
,Pages = "122-131"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS
,Key = "Bloss"
,Author = "Adrienne Bloss and Paul Hudak"
,Title = "Variations on Strictness Analysis"
,Pages = "132-142"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXPANSION-PASSING-STYLE
,Key = "Dybvig"
,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes"
,Title = "Expansion-Passing Style: Beyond Conventional Macros"
,Pages = "143-150"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(HYGIENIC-MACRO-EXPANSION
,Key = "Kohlbecker"
,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba"
,Title = "Hygienic Macro Expansion"
,Pages = "151-161"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXACT-REAL-ARITHMETIC
,Key = "Boehm"
,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell"
,Title = "Exact Real Arithmetic: A Case Study in Higher Order Programming"
,Pages = "162-173"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS
,Key = "White"
,Author = "Jon L. White"
,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building"
,Pages = "174-191"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR
,Key = "Steenkiste"
,Author = "Peter Steenkiste and John Hennessy"
,Title = "{L}isp on a Reduced-Instruction-Set-Processor"
,Pages = "192-201"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW
,Key = "Sarkar"
,Author = "Vivek Sarkar and John Hennessy"
,Title = "Partitioning Parallel Programs for Macro-Dataflow"
,Pages = "202-211"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR
,Key = "Scheevel"
,Author = "Mark Scheevel"
,Title = "{NORMA}: A Graph Reduction Processor"
,Pages = "212-219"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(FOUR-STROKE-REDUCTION-ENGINE
,Key = "Clack"
,Author = "Chris Clack and Simon L. Peyton Jones"
,Title = "The Four-Stroke Reduction Engine"
,Pages = "220-232"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS
,Key = "Lee"
,Author = "Peter Lee and Uwe Pleban"
,Title = "On the Use of {L}isp in Implementing Denotational Semantics"
,Pages = "233-248"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES
,Key = "Nielson"
,Author = "Hanne R. Nielson and Flemming Nielson"
,Title = "Semantics Directed Compiling for Functional Languages"
,Pages = "249-257"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CONNECTION-GRAPHS
,Key = "Bawden"
,Author = "Alan Bawden"
,Title = "Connection Graphs"
,Pages = "258-265"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE
,Key = "Mauny"
,Author = "Michel Mauny and Asc\'ander Su\'arez"
,Title = "Implementing Functional Languages in the Categorical Abstract Machine"
,Pages = "266-278"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CONNECTION-MACHINE-LISP
,Key = "Steele"
,Author = "Steele, Guy L., Jr. and W. Daniel Hillis"
,Title = "Connection Machine LISP: Fine-Grained Parallel Symbolic Processing"
,Pages = "279-297"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(MYSTERY-OF-THE-TOWER-REVEALED
,Key = "Wand"
,Author = "Mitchell Wand and Daniel P. Friedman"
,Title = "The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower"
,Pages = "298-307"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS
,Key = "Mitchell"
,Author = "John C. Mitchell"
,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)"
,Pages = "308-319"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS
,Key = "Jayaraman"
,Author = "Bharat Jayaraman and Frank S. K. Silbermann"
,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming"
,Pages = "320-331"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES
,Key = "Thatte"
,Author = "Satish R. Thatte"
,Title = "Towards a Semantic Theory for Equational Programming Languages"
,Pages = "332-342"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING
,Key = "Lermen"
,Author = "Claus-Werner Lermen and Dieter Maurer"
,Title = "A Protocol for Distributed Reference Counting"
,Pages = "343-350"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION
,Key = "Hudak"
,Author = "Paul Hudak"
,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)"
,Pages = "351-363"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION
,Key = "Rudalics"
,Author = "Martin Rudalics"
,Title = "Distributed Copying Garbage Collection"
,Pages = "364-372"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
----------------------------------------------------------------
\bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP}
Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian.
Experience with an uncommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 39--53.
\bibitem{IMPLEMENTATION-OF-PC-SCHEME}
Bartley, David H., and Jensen, John C.
The implementation of {PC} {S}cheme.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 86--93.
\bibitem{CONNECTION-GRAPHS}
Bawden, Alan.
Connection graphs.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 258--265.
\bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS}
Bloss, Adrienne, and Hudak, Paul.
Variations on strictness analysis.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 132--142.
\bibitem{EXACT-REAL-ARITHMETIC}
Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J.
Exact real arithmetic: a case study in higher order programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 162--173.
\bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP}
Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P.
Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 67--85.
\bibitem{FOUR-STROKE-REDUCTION-ENGINE}
Clack, Chris, and Jones, Simon L. Peyton.
The four-stroke reduction engine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 220--232.
\bibitem{MINI-ML}
Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles.
A simple applicative language: {M}ini-{ML}.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 13--27.
\bibitem{EXPANSION-PASSING-STYLE}
Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T.
Expansion-passing style: beyond conventional macros.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 143--150.
\bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES}
Fairbairn, Jon, and Wray, Stuart C.
Code generation techniques for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 94--104.
\bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING}
Gifford, David K., and Lucassen, John M.
Integrating functional and imperative programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 28--38.
\bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION}
Hudak, Paul.
A semantic model of reference counting and its abstraction (detailed summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 351--363.
\bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS}
Jayaraman, Bharat, and Silbermann, Frank S. K.
Equations, sets, and reduction semantics for functional and logic programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 320--331.
\bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES}
Knight, Tom.
An architecture for mostly functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 105--112.
\bibitem{HYGIENIC-MACRO-EXPANSION}
Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce.
Hygienic macro expansion.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 151--161.
\bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS}
Lee, Peter, and Pleban, Uwe.
On the use of {L}isp in implementing denotational semantics.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 233--248.
\bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION}
Lema\↑\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B.
Mechanisms for efficient multiprocessor combinator reduction.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 113--121.
\bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING}
Lermen, Claus-Werner, and Maurer, Dieter.
A protocol for distributed reference counting.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 343--350.
\bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE}
Mauny, Michel, and Su\'arez, Asc\'ander.
Implementing functional languages in the categorical abstract machine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 266--278.
\bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS}
Mitchell, John C.
A type-inference approach to reduction properties and semantics of polymorphic expressions (summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 308--319.
\bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES}
Nielson, Hanne R., and Nielson, Flemming.
Semantics directed compiling for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 249--257.
\bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP}
Padget, Julian, et al.
Desiderata for the standardisation of {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 54--66.
\bibitem{CURRY-CHIP}
Ramsdell, John D.
The {CURRY} chip.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 122--131.
\bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION}
Rudalics, Martin.
Distributed copying garbage collection.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 364--372.
\bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW}
Sarkar, Vivek, and Hennessy, John.
Partitioning parallel programs for macro-dataflow.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 202--211.
\bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR}
Scheevel, Mark.
{NORMA}: a graph reduction processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 212--219.
\bibitem{CONNECTION-MACHINE-LISP}
Steele, Jr., Guy L., and Hillis, W. Daniel.
Connection machine lisp: fine-grained parallel symbolic processing.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 279--297.
\bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR}
Steenkiste, Peter, and Hennessy, John.
{L}isp on a reduced-instruction-set-processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 192--201.
\bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES}
Thatte, Satish R.
Towards a semantic theory for equational programming languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 332--342.
\bibitem{LAWS-IN-MIRANDA}
Thompson, Simon.
Laws in {M}iranda.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 1--12.
\bibitem{MYSTERY-OF-THE-TOWER-REVEALED}
Wand, Mitchell, and Friedman, Daniel P.
The mystery of the tower revealed: a non-reflective description of the reflective tower.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 298--307.
\bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS}
White, Jon L.
Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 174--191.
∂23-Aug-86 1738 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: numbers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Aug 86 17:37:49 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 AUG 86 20:38:18 EDT
Date: Sat 23 Aug 86 20:37:17-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: numbers
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8608210013.AA03947@tekchips.TEK>
Message-ID: <12233218691.23.GJS@OZ.AI.MIT.EDU>
The real numbers committee met today (all C of us, but we are not sure
if C=2↑Aleph0) in closed session!. We commend you, David Bartley and
Norm Adams for noticing our grievous errors and we thank you for the
nice suggestions. We move that suggestions 1-5 be immediately
adopted. Suggestion 6, concerning the syntax of exact/inexact
numerical constants is still not clear. What is your favorite
proposal anyway?
-------
∂25-Aug-86 2008 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Another nit; my favorite numbers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 20:03:12 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Aug 86 21:26:35 EDT
Received: from tektronix by csnet-relay.csnet id ae02269; 25 Aug 86 18:44 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA12524; Mon, 25 Aug 86 14:26:48 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA07580; Mon, 25 Aug 86 14:29:50 PDT
Message-Id: <8608252129.AA07580@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU, jar@MC.LCS.MIT.EDU
Subject: Another nit; my favorite numbers
In-Reply-To: Your message of Sat 23 Aug 86 20:37:17-EDT.
<12233218691.23.GJS@OZ.AI.MIT.EDU>
Date: 25 Aug 86 14:29:47 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
The description of map in section 6.9 says that its first argument must
be a procedure of one argument. The description should say instead
that "The {\it list}s must be lists, and {\it proc} must be a procedure
taking as many arguments as there are {\it list}s."
----------------------------------------------------------------
Gerry asked what my favorite proposal was for the implicit exactness
of numeric constants. It is:
1. Constants of the form x+yi, x-yi, and x@y are exact iff both x
and y are exact as real constants.
2. Constants of the form x/y are exact iff both x and y are exact
as integer constants and there is no explicit prefix that says
otherwise.
3. Constants that contain sharp signs to indicate imprecise digits
are inexact unless there is an explicit prefix that says
otherwise.
4. Constants that contain a nonempty exponent suffix are exact iff
they are exact after shifting the decimal point and/or adding
zeroes to eliminate the exponent. (For example, 1.1e6 would
be treated as 1100000, 40e-3 would be treated as .040, 2/3e2
would be treated as 200/3, and 2/3e-2 would be treated as 2/300.)
5. Constants that contain a decimal point but no exponent or sharp
signs indicating imprecise digits are exact iff there are no
digits to the right of the decimal point and there is no explicit
prefix that says otherwise.
6. Constants that contain no decimal point, exponent, or sharp
signs indicating imprecise digits are exact iff there is no
explicit prefix that says otherwise.
Whew! Rule 4 is probably the most controversial, followed by rule 5.
peace, Will
∂28-Aug-86 0849 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Minutes from lunch 5 August 1986
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86 08:49:31 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86 11:48:45 EDT
Date: 28 Aug 1986 11:11 EDT (Thu)
Message-ID: <JINX.12234426370.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: willc%tekchips.tek.csnet@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Minutes from lunch 5 August 1986
In-reply-to: Msg of 14 Aug 1986 16:00-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Wow! we have a full schedule ahead. Given the amount of flame which
just agreeing on the language has generated, I can imagine what trying
to agree on these issues will cause. I definitely look forward to it.
Something we might also think about standarizing is graphics
primitives. I realize this is hardware/system dependent, but it is
probably no harder than agreeing on interrupts and similar things.
It would be nice if simple graphics programs were also portable.
∂28-Aug-86 0908 @MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM Minutes/Standardize Graphics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86 09:08:20 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 28 Aug 86 12:07:54 EDT
Received: from hplmhw by hplabs.HP.COM ; Thu, 28 Aug 86 09:01:43 pdt
Received: by hplmhw ; Thu, 28 Aug 86 09:02:41 pdt
Date: Thu, 28 Aug 86 09:02:41 pdt
From: Henry M. Wu <mhwu%hplmhw@hplabs.HP.COM>
Message-Id: <8608281602.AA00425@hplmhw>
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: willc%tekchips.tek.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Bill Rozas's message of 28 Aug 1986 11:11 EDT (Thu)
Subject: Minutes/Standardize Graphics
One comment I have heard from talking to people around here is that
they are surprised Scheme is trying put everything into the language
specs rather than define libraries (like C, I guess).
I'm not claiming this is the right thing, but it does seem like
something worth pondering.
Henry
∂28-Aug-86 2012 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: Minutes from lunch 5 August 1986
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86 20:12:07 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86 14:23:45 EDT
Date: Thu 28 Aug 86 14:21:58-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: Minutes from lunch 5 August 1986
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <JINX.12234426370.BABYL@MIT-OZ>
Message-ID: <12234461088.59.GJS@OZ.AI.MIT.EDU>
I disagree that it is good to mix graphics in with other things.
I think that graphics is pretty poorly understood and rather idiosyncratic --
it will just cause lots of wasted flamage to work on that.
-------
∂29-Aug-86 1503 @MC.LCS.MIT.EDU:andy@ads.ARPA graphics for Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Aug 86 15:02:48 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 29 Aug 86 18:01:17 EDT
Date: Fri, 29 Aug 86 06:41:16 pdt
From: andy@ads.ARPA (Andy Cromarty)
To: rrrs-authors@mit-mc.ARPA
Subject: graphics for Scheme
A good alternative to providing graphics capability is to solve the
more general problem of designing a clean foreign function interface
standard. This would permit a variety of useful existing software
packages to be integrated into Scheme environments without requiring
that we deflect our attention from substantive language design issues
(and our plate is rather full already) to address ancillary and difficult
problems such as design of packages for graphics, window systems, etc.
This would also make Scheme much more attractive to people who actually
want to use Scheme as a programming language rather than as an object
of study.
Designing a good foreign function interface is nontrivial if we
wish to maintain a principled design approach. I suspect that
it would require us to revisit some of the thorny problems we've
brushed up against but not really solved in the past few months,
such as whether Scheme should be thought of as having a dynamic
binding environment vs. an essentially static one defined purely
by the lexical structure of our programs. In the former case,
a relatively conventional dynamic loading scheme might work best;
for the latter case, a declaration-based system might be more
appropriate. In either case, we would need a spec for translating
Scheme data structures into those of other languages. (Perhaps
the SUN xdr might be a good spec to work from for this part of
the problem.)
A foreign function interface might also make Scheme a better
base language environment for studying some difficult contemporary
programming paradigm problems, such as techniques for distributed
and parallel processing. Currently we achieve this locally at ADS by
extending our Scheme with functions written in C and linked in
statically by the linkage editor. This has the disadvantage of
requiring that the researcher know not only how to code the new
parallelism/distributed processing primitives, but also what the
internal structure of the Scheme environment is in some detail.
A foreign function interface would provide a sort of firewall that
would prevent the designer of new constructs from having to know
what the Scheme implementation's internals look like.
asc
∂02-Sep-86 1519 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU substring-vector-null-fill!, colitis, etc.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 86 15:18:30 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 SEP 86 18:18:38 EDT
Date: Tue, 2 Sep 86 18:19:59 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: substring-vector-null-fill!, colitis, etc.
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].90180.860902.JAR>
Here are changes I've made at the requests of people too numerous to
mention (I wish I could acknowledge everyone individually, but time
presses):
I've flushed SUBSTRING-FILL! and STRING-NULL?. If STRING-NULL? is
retained then VECTOR-NULL? should be added. These are both in a
somewhat different class than NULL? since NULL? is often used to
terminate recusrions but STRING- and VECTOR-NULL? aren't.
It's now clearly an error to alter an object returned as the value of a
constant expression, e.g. (string-set! "foo" 1 #\x) and (set-car! '(a b) 'c)
are errors.
The list of extended alphabetics has been moved from "other notations"
to "identifiers".
I'll try to flush the garbage about immutability from the eqv? section,
and leave the question of (eq? '(a) '(a)) unbreached.
Small organizational error fixed: the nonterminal <sequence expression>
is gone, and (begin <sequence>) is now an alternative right-hand side
for <derived expression>.
The equation defining exponentiation has been repaired.
-----
Questions:
- Advice sought on what to do about the grammar for COND and CASE. In
question is the treatment of non-final ELSE clauses. Two people have
mentioned that as it stands the grammar is too liberal. Should I change
it so that there are two rules for each, viz.
<derived expression> --> ...
| (cond <cond clause>+)
| (cond <cond clause>* (else <sequence>))
| ...
| (case <key> <case clause>+)
| (case <key> <case clause>* (else <sequence>))
| ...
? Seems to me it's not grave if it's left as is, since the text
explains that actually the else clause should come at the end.
- I can sort of see why VECTOR-FILL! exists (it has to exist internally in
any case, in order to support the optional argument), but symmetry
considerations would suggest either flushing it or adding STRING-FILL!.
Opinions? No change here so far.
- I don't think I have time to change number syntax, although I think
specifying default exactness on input is easier, since I can just copy
text from Will's messages. I have two small arguments with Will's rule
which says that 1e3 is exact. One is that this makes exactness somewhat
tricky to determine -- you have to be able to count in order to
determine whether a string represents an exact number or not. I prefer
the simpler rurule which says that the presence of an exponent marker
makes the number inexact by default. The second argument stems from CL
compatibility concerns: if Scheme's exact integers are identical to CL's
integers, and Scheme's inexact (rational) flonums are identical to CL's
flonums, then making 1e3 represent an exact number would be an
incompatibility between Scheme and CL. This correspondence seems
natural to me. I'd like to hear arguments in favor of Will's rule.
- I'm inclined to demote colon from alphabetic to unspecified (like \ and
|), although I'd like the case to be made more clearly. I would really
hate to see someone add Common-Lisp-like read-time packaging to any
Scheme, so I don't admit that as a good reason for this change, although
if foo:bar read in the same as (access bar foo) that wouldn't be so bad.
However, I'm primarily a Scheme-in-Common-Lisp user myself these days,
and the implementation and its integration into the host CL would indeed
be cleaner if colon weren't extended alphabetic, so I DO see CL
compatibility as a good reason for the change.
On the side of an alphabetic colon, I should mention that the
moderate-sized community of pro-Scheme people raised on Riesbeck,
Charniak, and/or McDermott's book(s), or otherwise immersed in Yale AI
Lisp culture, use colon pretty heavily as an alphabetic character.
Also, there are some other alternatives for CL <--> Scheme communication:
- A way to coerce packages to environments, so e.g. if you want
Lisp's ELT function you can say (access elt lisp-package). This is
what CLSCH does now.
- A procedure which makes Lisp symbols, e.g. (make-lisp-symbol 'lisp
'elt).
- A reader syntax such as #[Lisp-symbol lisp elt] or #>Lisp>elt.
None of these is quite as attractive as just saying lisp:elt.
I'll wait for more comments, then flip a coin.
- Jonathan
∂03-Sep-86 0424 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA call-with-xxput-port
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 04:23:54 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 3 Sep 86 07:24:24 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA03165; Wed, 3 Sep 86 07:17:30 edt
Date: Wed, 3 Sep 86 07:17:30 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Wed, 3 Sep 86 07:17:30 edt
Message-Id: <8609031117.AA03165@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: call-with-xxput-port
Please do not forget the change associated with
call-with-input-port and call-with-output-port.
I suggest changing the names of no other I/O routines.
John
∂03-Sep-86 0625 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU substring-vector-null-fill!, colitis, etc.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 06:25:11 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 SEP 86 09:05:17 EDT
Date: 3 Sep 1986 09:02 EDT (Wed)
Message-ID: <JINX.12235975868.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: substring-vector-null-fill!, colitis, etc.
In-reply-to: Msg of 2 Sep 1986 18:19-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
1) I vote to change the grammar to only allow the final ELSE case.
It does not seem like a very large change.
2) VECTOR-FILL! and STRING-FILL! are completely symmetric. They both
must exist internally for the MAKE-STRING and MAKE-VECTOR procedures.
FLush both or keep both, but I vote to flush both since they can be
written using VECTOR-SET! and STRING-SET!
3) I think that except in a few cases, it is not necessary to agree on
default exactness in the number syntax. Anybody who is going to use
advantage of it (whenever somebody implements it), will certainly want
to force the exactness/inexactness of his/her explicit numerals by
using prefixes, and nobody else will care, probably.
The only case that must be decided, in my opinion, is making things
like 3, 123, -456 ("obvious" integers) exact, so they can be used as
indeces to VECTOR-MUMBLE and STRING-MUMBLE.
Thus some implementations could agree to be compatible with CL, and
some to take a completely different approach, but the most common case
(and needed by non-numeric code) would be compatible.
4) I like alphabetic colon, and dislike the CL package system too, but
giving up colon seems like a very minor issue. There are too many
people trying to make a dual CL/Scheme environment, and we should not
make this job harder than it has to be. Thus I vote moving colon to
unspecified.
∂04-Sep-86 0858 @MC.LCS.MIT.EDU:F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU Scheme Books?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 08:58:39 PDT
Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 4 Sep 86 11:54:48 EDT
Received: from (F95THOMP)CARLETON.BITNET by WISCVM.WISC.EDU on 09/04/86
at 10:52:41 CDT
Received: from F95THOMP by CARLETON.BITNET on 03 Sep 86 17:37:10 EDT
Date: 03 Sep 86 17:11:00 EDT
From: DAVE THOMAS <F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU>
To: <scheme@MC.LCS.MIT.EDU>
Subject: Scheme Books?
What books are available for Scheme(other than S&ICP)?
Are there solution manuals available for any of these?
Thanks
∂04-Sep-86 1828 @MC.LCS.MIT.EDU:wecker%cookie.DEC@decwrl.DEC.COM Please delete me from this distribution list, thanks - dave
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 18:28:05 PDT
Received: from decwrl.dec.com by MC.LCS.MIT.EDU 4 Sep 86 20:41:23 EDT
Received: by decwrl.dec.com (5.54.2/4.7.34)
id AA00703; Thu, 4 Sep 86 17:39:12 PDT
Message-Id: <8609050039.AA00703@decwrl.dec.com>
Date: 04-Sep-1986 1022
From: wecker%cookie.DEC@decwrl.DEC.COM (DAVE TANSTAAFL WECKER)
To: scheme@MC.LCS.MIT.EDU
Subject: Please delete me from this distribution list, thanks - dave
∂05-Sep-86 1947 @MC.LCS.MIT.EDU:mh@BU-CS.BU.EDU list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Sep 86 19:46:59 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 5 Sep 86 22:44:06 EDT
Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa00483; 5 Sep 86 16:15 EDT
Return-Path: <mh>
Received: by bu-cs.bu.edu (5.31/4.7)
id AA04666; Fri, 5 Sep 86 11:11:29 EDT
Date: Fri, 5 Sep 86 11:11:29 EDT
From: Marek Holynski <mh@BU-CS.BU.EDU>
Message-Id: <8609051511.AA04666@bu-cs.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: list
Could you please delete me from the distribution list. Thank you.
∂08-Sep-86 0330 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA Beginners question: Advising methods in TI scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 03:30:35 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Sep 86 06:27:39 EDT
Received: from ubc by csnet-relay.csnet id aa08170; 8 Sep 86 6:19 EDT
Date: Mon, 8 Sep 86 02:28:14 pdt
Received: by ubc.csnet id AA11319; Mon, 8 Sep 86 02:28:14 pdt
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <121:shneider@cui.unige.chunet>
Subject: Beginners question: Advising methods in TI scheme
1) I started writing a program with lots of methods. Now it start loosing
"track".
-> How can I trace methods in Ti scheme?
i.e. is there an elegant way of doing it ?
2) Is there any person to whom I should send this kind of request ?
Thanks for any help
(and reply by e-mail)
-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) 22 20 93 33 ext. 2357
to VMS/BITNET: to UNIX/EAN (preferable):
BITNET: SCHNEIDER@CGEUGE51 shneider%cui.unige.chunet@CERNVAX
ARPA: SCHNEIDER%CGEUGE51.BITNET@WISCVM shneider%cui.unige.chunet@ubc.csnet
uucp: mcvax!cernvax!cui!shneider
X.400/ean: shneider@cui.unige.chunet
∂08-Sep-86 0826 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA Re: [THOMAS: Scheme Books?]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 08:25:59 PDT
Received: from yale-bulldog by MC.LCS.MIT.EDU 8 Sep 86 11:21:04 EDT
Received: by Yale-Bulldog.YALE.ARPA; 8 Sep 86 11:01:05 EDT (Mon)
Date: 8 Sep 86 11:01:05 EDT (Mon)
From: James F Philbin <philbin-jim@YALE.ARPA>
Message-Id: <8609081501.AA17146@Yale-Bulldog.YALE.ARPA>
Subject: Re: [THOMAS: Scheme Books?]
To: <Scheme@MC.LCS.MIT.EDU>
What books are available for Scheme ? Are there solution manuals
available for any of these?
Steven Slade had written and introductory programming book which
might be of interest. Contact SLADE@YALE for details.
- Jim
The T Programming Language: A Dialect of LISP
Stephen Slade
Prentice-Hall, Englewood Cliffs, N.J.
To appear: November, 1986
∂08-Sep-86 0848 @MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa scoops
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 08:48:32 PDT
Received: from utah-cs.ARPA by MC.LCS.MIT.EDU 8 Sep 86 11:34:07 EDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA22771; Mon, 8 Sep 86 09:32:07 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA03156; Mon, 8 Sep 86 09:32:04 MDT
Date: Mon, 8 Sep 86 09:32:04 MDT
From: carr%utah-orion@utah-cs.arpa (Harold Carr)
Message-Id: <8609081532.AA03156@utah-orion.ARPA>
To: scheme@mc.lcs.mit.edu
Subject: scoops
Could someone tell me how to obtain SCOOPS?
Thanks, Harold
∂08-Sep-86 1334 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA Beginners question: Advising methods in TI scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 13:33:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Sep 86 16:25:41 EDT
Received: from ubc by csnet-relay.csnet id aa00411; 8 Sep 86 15:19 EDT
Date: Mon, 8 Sep 86 11:24:54 pdt
Received: by ubc.csnet id AA13463; Mon, 8 Sep 86 11:24:54 pdt
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
Sender: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <122:shneider@cui.unige.chunet>
Subject: Beginners question: Advising methods in TI scheme
1) I started writing a program with lots of methods. Now it start loosing
"track".
-> How can I trace methods in Ti scheme?
i.e. is there an elegant way of doing it ?
2) Is there any person to whom I should send this kind of request ?
Thanks for any help
(and reply by e-mail)
-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) 22 20 93 33 ext. 2357
to VMS/BITNET: to UNIX/EAN (preferable):
BITNET: SCHNEIDER@CGEUGE51 shneider%cui.unige.chunet@CERNVAX
ARPA: SCHNEIDER%CGEUGE51.BITNET@WISCVM shneider%cui.unige.chunet@ubc.csnet
uucp: mcvax!cernvax!cui!shneider
X.400/ean: shneider@cui.unige.chunet
∂08-Sep-86 1509 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Good & bad news
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 15:09:43 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 SEP 86 18:10:23 EDT
Date: Mon, 8 Sep 86 18:11:24 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Good & bad news
To: rrrs-authors@MC.LCS.MIT.EDU
cc: slade@YALE.ARPA, meehan@YALE.ARPA
Message-ID: <[AI.AI.MIT.EDU].92170.860908.JAR>
The good news is that the scheme report is in the mail, and the editor
of SIGPLAN Notices will have it within a couple of days.
The bad news is that the November issue of SIGPLAN, like the October
issue, is devoted to conference proceedings for some conference or
other. So there is no room for the Scheme report.
Barring other unforeseen catastrophes, it will be in the December issue.
A few people have asked me whether page numbers are known, and I expect
they won't be until known until mid-December. I suggest calling Dick
Wexelblat on the phone around that time if you really want to know.
We plan to print this version as an MIT AI memo. I'll make the LaTeX
sources available on MIT-PREP sometime this week.
I'll also US mail hardcopy to the authors. If the Indiana CS department
is interested in issuing it as a new tech report, I'd be happy to mail a
magnetic tape with the sources & DVI file.
Jonathan
∂08-Sep-86 1614 @MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA substring-vector-null-fill!, coliti
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 16:14:21 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Sep 86 19:14:47 EDT
Received: from indiana by csnet-relay.csnet id ak01084; 8 Sep 86 16:19 EDT
Date: Mon, 8 Sep 86 13:10:49 est
From: Perry Wagle <wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: substring-vector-null-fill!, coliti
If |(set-car! '(a b) 'c)| is an error, how about |(set-car! '(d e) 'f)|?
That is, when do backquoted expressions denote constants? (I vote never).
[A related question is whether |`(d e)| returns the same list each time it
is executed. I suspect you may want to table the above paragraph.]
Vectors have constant length. Strings have variable length. With this
view it would make sense to "fill" a vector, but not a string.
Perry Wagle, Indiana University, Bloomington Indiana.
...!ihnp4!inuxc!iuvax!wagle (USENET)
wagle@indiana (CSNET)
wagle%indiana@csnet-relay (ARPA)
∂08-Sep-86 2212 @MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Advising methods in TI Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86 22:12:23 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 8 Sep 86 23:03:17 EDT
Received: from ti-csl by csnet-relay.csnet id aa02126; 8 Sep 86 18:03 EDT
Received: by tilde id AA26422; Mon, 8 Sep 86 15:25:20 cdt
Date: Mon, 8 Sep 86 15:25:20 cdt
From: Amitabh Srivastava <asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: schneider%cui.unige.chunet%ubc@CSNET-RELAY.ARPA
Subject: Advising methods in TI Scheme
Cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
>> 1) I started writing a program with lots of methods. Now it start loosing
>> "track".
>> -> How can I trace methods in Ti scheme?
>> i.e. is there an elegant way of doing it ?
The procedure %sc-method-env returns the environment containing
the methods of a class. By using this and advise-entry and advise-exit
different tracing macros can be written.
For example, we can write a special form trace-method-entry to trace
the entry of method m1 of class class1.
(trace-method-entry m1 class1)
=>
(macro trace-method-entry
(lambda (e)
(let ((method (cadr e))
(class (caddr e)))
`(ADVISE-ENTRY
(ACCESS ,method (%sc-method-env ,class))
(lambda (p a e)
(writeln " The method " ',method " of class " ',class
" is called with " a))))))
Similarly one can write a macro to trace exits.
- amitabh
∂09-Sep-86 0429 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Slade's book in bib?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 86 04:29:08 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 9 Sep 86 07:28:53 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA17988; Tue, 9 Sep 86 07:21:18 edt
Date: Tue, 9 Sep 86 07:21:18 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 9 Sep 86 07:21:18 edt
Message-Id: <8609091121.AA17988@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Slade's book in bib?
Maybe Stephen Slade's book on T should be added to
the r↑3rs bibliography. Would some one with access
to it, make a recommendation?
John
∂13-Sep-86 2054 @MC.LCS.MIT.EDU:fowler@rochester.arpa Re: Prolog in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Sep 86 20:53:51 PDT
Received: from ur-cayuga.arpa by MC.LCS.MIT.EDU 13 Sep 86 23:35:30 EDT
Received: from ur-seneca.arpa (ur-seneca) by ur-cayuga.arpa id AA08101 (4.12x); Sat, 13 Sep 86 23:09:58 edt
Received: by ur-seneca.arpa id AA05145 (4.12x); Sat, 13 Sep 86 23:11:43 edt
Message-Id: <8609140311.5145@ur-seneca.arpa>
Date: Sat, 13 Sep 86 23:11:43 edt
From: Rob Fowler <fowler@rochester.arpa>
To: scheme@MC.LCS.MIT.EDU, MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU
Cc: Rob Fowler <fowler@rochester.arpa>
Subject: Re: Prolog in Scheme?
If you get any responses I'd appreciate it if you could pass them along to
me. I'm currently teaching an "AI Programming" course entirely in Scheme
using MacScheme and I'd really like to get hld of a Prolog or even a subset
that I could turn the students loose on for a couple of weeks.
-- Rob Fowler (fowler@rochester.edu)
∂14-Sep-86 0204 @MC.LCS.MIT.EDU:MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU Prolog in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 86 02:04:32 PDT
Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 13 Sep 86 22:41:47 EDT
Received: from (MWILSON)CARLETON.BITNET by WISCVM.WISC.EDU on 09/11/86
at 09:16:21 CDT
Received: from MWILSON by CARLETON.BITNET on 09 Sep 86 16:08:31 EDT
Date: 08 Sep 86 15:49:00 EDT
From: Mike Wilson <MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU>
To: <scheme@MC.LCS.MIT.EDU>
Subject: Prolog in Scheme?
Hello,
Are there any implementations of Prolog written in Scheme? I'm
interested in any and all versions from minimal to full-featured.
.Mike
∂15-Sep-86 0450 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Prolog in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 04:50:44 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86 07:37:08 EDT
Date: Sun, 14 Sep 86 12:34:06 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Prolog in Scheme?
To: fowler@ROCHESTER.ARPA
cc: MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Sat 13 Sep 86 23:11:43 edt from Rob Fowler <fowler at rochester.arpa>
Message-ID: <[AI.AI.MIT.EDU].93903.860914.JAR>
Date: Sat, 13 Sep 86 23:11:43 edt
From: Rob Fowler <fowler at rochester.arpa>
If you get any responses I'd appreciate it if you could pass them along to
me. I'm currently teaching an "AI Programming" course entirely in Scheme
using MacScheme and I'd really like to get hld of a Prolog or even a subset
that I could turn the students loose on for a couple of weeks.
Why not just use the query system in Structure & Interpretation?
- Jonathan
∂15-Sep-86 1223 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Begin in the Formal Semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 12:23:38 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 15 Sep 86 15:22:59 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA16806; Mon, 15 Sep 86 15:15:40 edt
Date: Mon, 15 Sep 86 15:15:40 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 15 Sep 86 15:15:40 edt
Message-Id: <8609151915.AA16806@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Begin in the Formal Semantics
Begin is described in the abstract syntax, but there is
no semantic function for it. Later, on page 35, the
semantics of begin is given under the derived expression
types heading. Should begin be described in the abstract
syntax section?
John
∂15-Sep-86 1237 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Begin in the Formal Semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 12:36:19 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86 15:35:43 EDT
Date: Mon, 15 Sep 86 15:38:17 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Begin in the Formal Semantics
To: ramsdell%faron@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 15 Sep 86 15:15:40 edt from John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
Message-ID: <[AI.AI.MIT.EDU].94273.860915.JAR>
Date: Mon, 15 Sep 86 15:15:40 edt
From: John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
Re: Begin in the Formal Semantics
Organization: The MITRE Corp., Bedford, MA
Posted-Date: Mon, 15 Sep 86 15:15:40 edt
Message-Id: <8609151915.AA16806@faron.MENET>
Begin is described in the abstract syntax, but there is
no semantic function for it. Later, on page 35, the
semantics of begin is given under the derived expression
types heading. Should begin be described in the abstract
syntax section?
It should be flushed from the abstract syntax. I intended to do this
but only partially succeeded.
Jonathan
∂15-Sep-86 1243 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Begin in the Formal Semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 12:42:52 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86 15:36:31 EDT
Date: Mon, 15 Sep 86 15:39:29 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Begin in the Formal Semantics
To: ramsdell%faron@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].94274.860915.JAR>
Date: Mon, 15 Sep 86 15:15:40 edt
From: John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
To: rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
Re: Begin in the Formal Semantics
Organization: The MITRE Corp., Bedford, MA
Posted-Date: Mon, 15 Sep 86 15:15:40 edt
Message-Id: <8609151915.AA16806@faron.MENET>
Begin is described in the abstract syntax, but there is
no semantic function for it. Later, on page 35, the
semantics of begin is given under the derived expression
types heading. Should begin be described in the abstract
syntax section?
It should be flushed from the abstract syntax. I intended to do this
but only partially succeeded.
Jonathan
∂15-Sep-86 1910 @MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA Advising methods in TI Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 19:10:25 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Sep 86 22:06:12 EDT
Received: from ti-csl by csnet-relay.csnet id ag02059; 15 Sep 86 13:20 EDT
Received: by tilde id AA13084; Mon, 15 Sep 86 10:11:25 cdt
Date: Mon, 15 Sep 86 10:11:25 cdt
From: Amitabh Srivastava <asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: Advising methods in TI Scheme
Cc: shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA
>> 1) I started writing a program with lots of methods. Now it start loosing
>> "track".
>> -> How can I trace methods in Ti scheme?
>> i.e. is there an elegant way of doing it ?
The procedure %sc-method-env returns the environment containing
the methods of a class. By using this and advise-entry and advise-exit
different tracing macros can be written.
For example, we can write a special form trace-method-entry to trace
the entry of method m1 of class class1.
(trace-method-entry m1 class1)
=>
(macro trace-method-entry
(lambda (e)
(let ((method (cadr e))
(class (caddr e)))
`(ADVISE-ENTRY
(ACCESS ,method (%sc-method-env ,class))
(lambda (p a e)
(writeln " The method " ',method " of class " ',class
" is called with " a))))))
Similarly one can write a macro to trace exits.
- amitabh
∂17-Sep-86 1224 @MC.LCS.MIT.EDU:prlb2!vauclair@seismo.CSS.GOV Request for information on new releases.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 12:19:53 PDT
Received: from seismo.CSS.GOV by MC.LCS.MIT.EDU 17 Sep 86 15:15:29 EDT
Return-Path: <prlb2!vauclair>
Received: from prlb2.UUCP by seismo.CSS.GOV with UUCP; Wed, 17 Sep 86 11:27:06 EDT
Received: by prlb2.UUCP (4.12/4.7)
id AA04826; Wed, 17 Sep 86 17:24:59 -0100
Received: by prlb2.UUCP (4.12/4.7)
id AA04820; Wed, 17 Sep 86 17:24:41 -0100
Message-Id: <8609171624.AA04820@prlb2.UUCP>
To: scheme@mc.lcs.mit.edu
Cc: prlb2!louis@seismo.CSS.GOV
Subject: Request for information on new releases.
Organisation: Philips Research Laboratory Brussels, Belgium
Uucp-From: mvauclair@prlb2.UUCP
Date: 17 Sep 86 17:24:35 N (Wed)
From: Marc Vauclair <prlb2!vauclair@seismo.CSS.GOV>
First, sorry for sending this request to scheme@mit-mc instead of
scheme-team@mit-mc but when trying the last address I got the message
reproduced at the end of this one.
For more than a year by now, we are using the MIT Scheme implementation
(Microcode version 6.1, Runtime version 11.2) on our Vax with Unix 4.2. In few
words, we greatly appreciate both the language and its implementation. There
are only two dark spots :
- the lack of documentation of the implementation (the only
documentation I have at my disposition are the "Structure and
Interpretation..." book and the revised revised report
- the slowness of the terminal i/o and in some circumstances of the
interpreter itself.
Is a newer version for VAX Unix available ? Does it include a compiler ? Is a
version for SUN 3 available ? How can we get these new versions ? Is it
possible to get some documentation on the implementation ?
Regards,
Marc.
[*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*]
From: Communications Satellite <seismo!MC.LCS.MIT.EDU!COMSAT>
Subject: Msg of Wednesday, 17 September 1986 06:35-EDT
To: "prlb2!vauclair@seismo.CSS.GOV"
Message-Id: <[MC.LCS.MIT.EDU].88830.860917>
============ A copy of your message is being returned, because: ============
"SCHEME-TEAM" at MC.LCS.MIT.EDU is an unknown recipient.
============ Failed message follows: ============
Received: from seismo.CSS.GOV by MC.LCS.MIT.EDU 17 Sep 86 06:35:14 EDT
Return-Path: <prlb2!vauclair>
Received: from prlb2.UUCP by seismo.CSS.GOV with UUCP; Wed, 17 Sep 86 06:15:00 EDT
Received: by prlb2.UUCP (4.12/4.7)
id AA26873; Wed, 17 Sep 86 11:28:57 -0100
Received: by prlb2.UUCP (4.12/4.7)
id AA26863; Wed, 17 Sep 86 11:28:23 -0100
Message-Id: <8609171028.AA26863@prlb2.UUCP>
To: scheme-team@mit-mc.arpa
Cc: prlb2!louis@seismo.CSS.GOV
Subject: Request for information on new releases.
Organisation: Philips Research Laboratory Brussels, Belgium
Uucp-From: mvauclair@prlb2.UUCP
Date: 17 Sep 86 11:27:54 N (Wed)
From: Marc Vauclair <prlb2!vauclair@seismo.CSS.GOV>
∂22-Sep-86 1441 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 86 14:41:18 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 SEP 86 17:37:29 EDT
Date: Mon, 22 Sep 86 17:39:42 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Revised↑3 Report on Scheme
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].97185.860922.JAR>
Announcement:
The "Revised↑3 Report on the Algorithmic Language Scheme" has been
completed. It is an updated version of the "Revised Revised Report on
Scheme" which appeared in summer 1985. A draft of this report was
circulated at the Lisp and Functional Programming Conference last month;
the final version is practically the same as that draft.
The "Revised↑3 Report" will appear in SIGPLAN notices in December of
this year. It will also be printed as MIT AI Memo 848a and as an
Indiana University CSD technical report. I'll send a separate message
as soon as I receive ordering information from MIT's publications
office, so everyone who wants one can get one.
- Jonathan Rees
∂24-Sep-86 0739 @MC.LCS.MIT.EDU:DLW@ALDERAAN.SCRC.Symbolics.COM [MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 07:39:12 PDT
Received: from ALDERAAN.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 24 Sep 86 10:34:13 EDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6731; Wed 24-Sep-86 10:32:24 EDT
Date: Wed, 24 Sep 86 10:36 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?]
To: Scheme@MIT-MC.ARPA
In-Reply-To: <860915140445.8.SGR@GROUSE.SCRC.Symbolics.COM>
Message-ID: <860924103627.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 15 Sep 86 14:04 EDT
From: Stephen G. Rowley <SGR@STONY-BROOK.SCRC.Symbolics.COM>
Answers, if any, to the Scheme mailing list at MIT:
Date: 08 Sep 86 15:49:00 EDT
From: Mike Wilson <MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU>
To: <scheme@MC.LCS.MIT.EDU>
Subject: Prolog in Scheme?
Hello,
Are there any implementations of Prolog written in Scheme? I'm
interested in any and all versions from minimal to full-featured.
.Mike
It would likewise be interesting to know if there are any versions of
Scheme written in Prolog.
∂24-Sep-86 0936 @MC.LCS.MIT.EDU:searfus@lll-icdc.arpa please add me ...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 09:36:12 PDT
Received: from lll-icdc.arpa by MC.LCS.MIT.EDU 24 Sep 86 12:31:11 EDT
Date: 24 Sep 86 07:50:00 PDT
From: "Searfus, Robert" <searfus@lll-icdc.arpa>
Subject: please add me ...
To: "scheme" <scheme@mc.lcs.mit.edu>
Reply-To: "Searfus, Robert" <searfus@lll-icdc.arpa>
to the scheme mailing list.
<bob> searfus@lll-icdc.arpa
------
∂25-Sep-86 0750 @MC.LCS.MIT.EDU:TIM@cis.upenn.edu prolog in scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86 07:50:23 PDT
Received: from linc.cis.upenn.edu by MC.LCS.MIT.EDU 25 Sep 86 09:53:06 EDT
Posted-Date: Thu, 25 Sep 86 09:42 EDT
Message-Id: <8609251352.AA02609@linc.cis.upenn.edu>
From: Tim Finin <Tim@cis.upenn.edu>
Subject: prolog in scheme
To: scheme@mc.lcs.mit.edu
Date: Thu, 25 Sep 86 09:42 EDT
We tried using the query system in "Structure & Interpretation" in our
freshman class last year and found it wanting in some respects. (1) It
doesn't handle disjunctions unless the disjuncts contain the same variables.
(2) It is extremely slow. We were using it in TI's PC Scheme on AT's. We
gave some very simple logic programming problems (e.g. the standard kinship
relations) and found that the students we spending 10 or 15 minutes waiting
for the query system to finish! They found this very frustrating.
I'd think I would like to cover the query system from S&I in class because
it's clear and simple and have the students use a more suped-up version that
is reasonably efficient. In addition, facilities like "retract",
"reconsult", etc. would easy it's use in homeworks.
I'd also like to consider using a system which uses a prolog-like
depth-first backtracking search.
Tim
∂25-Sep-86 1309 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU prolog in scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86 13:08:50 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 SEP 86 14:48:06 EDT
Date: 25 Sep 1986 13:27 EDT (Thu)
Message-ID: <JINX.12241791234.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: Tim Finin <Tim@CIS.UPENN.EDU>
Cc: scheme@MC.LCS.MIT.EDU
Subject: prolog in scheme
In-reply-to: Msg of 25 Sep 1986 09:42-EDT from Tim Finin <Tim at cis.upenn.edu>
We tried using the query system in "Structure & Interpretation" in our
freshman class last year and found it wanting in some respects. (1) It
doesn't handle disjunctions unless the disjuncts contain the same variables.
(2) It is extremely slow. We were using it in TI's PC Scheme on AT's. We
gave some very simple logic programming problems (e.g. the standard kinship
relations) and found that the students we spending 10 or 15 minutes waiting
for the query system to finish! They found this very frustrating.
(1) GJS consistently updates the query language and fixes versions as bugs
appear. You should get in touch with him, the bug may have been
fixed.
(2) I have observed this also on MacScheme. I don't know about PC
Scheme, but in the case of MacScheme the reason is probably that
streams have no interpreter support, they are written in scheme. This
is unlike MIT Scheme, for which the code was originally written. PC
Scheme may have the same problem. While it is not blindingly fast on
our machines at MIT, it only becomes slow with relatively complicated
programs, and is adequately fast for the class. 10 or 15 mins. is way
longer than I've ever seen it take while solving the S&ICP problems.
∂28-Sep-86 0818 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Prolog in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 86 08:18:29 PDT
Received: from Cs.Ucl.AC.UK by MC.LCS.MIT.EDU 28 Sep 86 11:14:15 EDT
Received: from vax1.cs.ucl.ac.uk by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP
id ab02098; 28 Sep 86 16:06 WET
Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id a001696;
28 Sep 86 16:12 BST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a009979; 28 Sep 86 16:07 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sun, 28 Sep 86 16:04:02 -0100
Message-Id: <28548.8609281504@aiva.ed.ac.uk>
To: scheme@mc.lcs.mit.edu
Subject: Prolog in Scheme
Unfortunately, the query system in Structure and Interpretation is
not Prolog. In particular, it doesn't handle cut. While this
may not metter much to some (especially those who think cut should
be fluched anyway), it does make the system considerably
less interesting as an implementation of Prolog.
∂30-Sep-86 0507 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Refering to the Revised↑3 Report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 86 05:07:06 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 30 Sep 86 08:03:09 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by linus.MENET (1.1/4.7)
id AA02723; Tue, 30 Sep 86 08:04:40 EDT
Date: Tue, 30 Sep 86 08:04:40 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Tue, 30 Sep 86 08:04:40 EDT
Message-Id: <8609301204.AA02723@linus.MENET>
To: scheme%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Refering to the Revised↑3 Report on Scheme
I've seen "The Revised Revised Report on Scheme or
An UnCommon Lisp" referenced as "R3S". I would like
to discourage this and suggest using "RRRS" or "R2RS".
The "Revised↑3 Report on the Algorithmic Language Scheme"
will be in December SIGPLAN. The obvious reference is
"R3RS" which is why I would like to discourge the use
of "R3S" for the UnCommon Lisp report.
John
∂01-Oct-86 1416 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R↑3RS sources
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 86 14:16:32 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 OCT 86 15:44:25 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 11868; Wed 1-Oct-86 15:44:55-EDT
Date: Wed, 1 Oct 86 15:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: R↑3RS sources
To: rrrs-authors@MC.LCS.MIT.EDU
cc: carr@UTAH-ORION.ARPA
Message-ID: <"861001154411.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Those of you with Internet FTP capabilities should now be able to get
the report sources from MIT-PREP. Login as user scheme password scheme,
and get the file
/scheme/r3rs.tar
if you can use a unix tar file, otherwise get all the files in the
directory "/scheme/documentation/r3rs".
∂02-Oct-86 0803 @MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA Lost mail
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86 08:03:29 PDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU 2 Oct 86 10:58:19 EDT
Date: Thu 2 Oct 86 07:56:36-PDT
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: Lost mail
To: scheme@MC.LCS.MIT.EDU
cc: Goerz@SUMEX-AIM.ARPA
Message-ID: <12243598741.13.GOERZ@SUMEX-AIM.ARPA>
Unformtunately I made the big mistake to erase the SCHEME mail between
Aug. 4 and Sep. 30 before having read it. As completely.
As there were some very interesting items on the list, let me please
ask you whether there is a simple way to remail the stuff to me.
Sorry for the inconvenience, it was just my fault!
---Guenther
-------
∂02-Oct-86 1013 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Lost mail
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86 10:13:06 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 OCT 86 11:35:37 EDT
Date: Thu, 2 Oct 86 11:36:35 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Lost mail
To: GOERZ@SUMEX-AIM.ARPA
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 2 Oct 86 07:56:36-PDT from Gunther Goerz <GOERZ at SUMEX-AIM.ARPA>
Message-ID: <[AI.AI.MIT.EDU].101186.861002.JAR>
Use FTP. Connect to MIT-MC, use an arbitrary user name and password,
and get the file LSPMAI; SCHEME MAIL. (Note that the file name has
spaces in it.)
You can send questions like this to Scheme-Request@MC.
Jonathan
∂02-Oct-86 1114 @MC.LCS.MIT.EDU:mohammad%utah-orion@utah-cs.arpa Can anyone hear me?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86 11:14:44 PDT
Received: from utah-cs.ARPA by MC.LCS.MIT.EDU 2 Oct 86 11:42:10 EDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA24166; Thu, 2 Oct 86 09:41:35 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA24813; Thu, 2 Oct 86 09:41:32 MDT
Date: Thu, 2 Oct 86 09:41:32 MDT
From: mohammad%utah-orion@utah-cs.arpa (Mohammad Pourheidari)
Message-Id: <8610021541.AA24813@utah-orion.ARPA>
To: scheme@mc.lcs.mit.edu
Subject: Can anyone hear me?
Hello, My name is Mohammad Pourheidari. I am a member of PASS group down
at the University of Utah. I have made a couple of attempts to get a hold of
Dr. Henry Lieberman; unfortunately both times unsuccessful. The net address
I have been using is : henry@mit-mc. Can anyone tell me whether this is the
best place to send him mail, or even better can anyone tell me what is the
best way to get a hold of him.
Thank you,
Mohammad
∂02-Oct-86 1714 @MC.LCS.MIT.EDU:zorn@kim.Berkeley.EDU I am interested in gathering `significant' Scheme programs...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86 17:14:00 PDT
Received: from kim.Berkeley.EDU by MC.LCS.MIT.EDU 2 Oct 86 20:08:30 EDT
Received: by kim.Berkeley.EDU (5.53/1.17)
id AA01376; Thu, 2 Oct 86 17:08:00 PDT
Message-Id: <8610030008.AA01376@kim.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu
Subject: I am interested in gathering `significant' Scheme programs...
Date: Thu, 02 Oct 86 17:07:57 PDT
From: Benjamin Zorn <zorn@kim.Berkeley.EDU>
My name is Ben Zorn, and I'm working on the SPUR Multiprocessor Lisp
system at UC Berkeley. My particular interest is multiprocessor
garbage collection. My current plans include taking `significant'
Scheme programs and studying the object manipulation behavior that
they have. By significant, I mean programs that are large enough to
generate reasonable amounts of garbage, and are also considered to be
important programs that are frequently used. Multiprocessor programs
would be of even more interest to me. If you have publically
available programs that would be of interest to me, I would greatly
appreciate hearing from you. I will make a list of the replies
available to this mailing list in a few weeks.
-Ben Zorn (zorn@kim.berkeley.edu)
∂06-Oct-86 2336 @MC.LCS.MIT.EDU:dan%umass-boston.csnet@CSNET-RELAY.ARPA SCHEME implementations
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 86 23:36:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 7 Oct 86 02:25:36 EDT
Received: from umass-boston by csnet-relay.csnet id ab00520; 6 Oct 86 17:08 EDT
Received: by umb.csnet (4.12/4.7)
id AA11551; Mon, 6 Oct 86 17:01:38 edt
Date: Mon, 6 Oct 86 17:01:38 edt
From: Dan Stefanescu <dan%umass-boston.csnet@CSNET-RELAY.ARPA>
To: scheme%MC.LCS.MIT.EDU@RELAY.CS.NET
Subject: SCHEME implementations
Cc: dan@UMASS-BOSTON.CSNET
Are there any for AT&T hardware, in particular for UNIX PC's and
AT&T 3B2-400 machines ? Any pointers will be greatly appreciated.
Dan
∂15-Oct-86 0606 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Object-Oriented Schemes
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 86 06:06:22 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 15 Oct 86 08:57:28 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA01933; Wed, 15 Oct 86 08:51:14 edt
Date: Wed, 15 Oct 86 08:51:14 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Wed, 15 Oct 86 08:51:14 edt
Message-Id: <8610151251.AA01933@faron.MENET>
To: scheme%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Object-Oriented Schemes
Cc: ramsdell@mitre-bedford.ARPA
I am wondering if people on this list would
like to discuss Object-Oriented Schemes.
Three implementations come to mind at this time.
The oldest I know about is T[1]. TI has put its
Object-Oriented system called SCOOPS in the public
domain, as is T. I have had no experience with
SCOOPS. Oaklisp[2] adds to the T idea of first
class objects and operations, the idea of first
class types. I'm not sure what this contributes.
Are there any other implementations you would
like to discuss?
John
[1] Rees, J. & N. Adams IV, "T: a dialect of Lisp or,
Lambda: the ultimate software tool", 1982 Lisp and
Functional Programming, August 1982.
[2] Lang, K. & B. Pearlmutter, "Oaklisp: an
Object-Oriented Scheme with First Class Types",
OOPSLA '86, Sep-Oct 1986.
∂16-Oct-86 1410 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Public Domain
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 86 14:10:04 PDT
Received: from Cs.Ucl.AC.UK by MC.LCS.MIT.EDU 16 Oct 86 16:05:42 EDT
Received: from vax1.cs.ucl.ac.uk by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP
id aa03935; 16 Oct 86 19:28 WET
Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id a006787;
16 Oct 86 19:43 BST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a006756; 16 Oct 86 19:43 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 16 Oct 86 19:43:23 -0100
Message-Id: <5570.8610161843@aiva.ed.ac.uk>
To: scheme@mc.lcs.mit.edu
Subject: Public Domain
Date: Wed, 15 Oct 86 08:51:14 edt
From: "John D. Ramsdell" <ramsdell%faron@arpa.mitre-bedford>
To: scheme <scheme%edu.mit.lcs.mc@arpa.mitre-bedford>
Subject: Object-Oriented Schemes
I am wondering if people on this list would
like to discuss Object-Oriented Schemes.
Three implementations come to mind at this time.
The oldest I know about is T[1]. TI has put its
Object-Oriented system called SCOOPS in the public
domain, as is T.
Well, I would like to discuss such things, but what I'd like to know
at the moment is this: is T now in the public domain? How might I
obtain a copy of it or of SCOOPS.
I'm sorry if this isn't the proper forum for such questions, but
my options seem somewhat limited from here.
-- Jeff
P.S. I do have a t2.8, with licence. Am I now free to copy it
to other machines?
∂20-Oct-86 0417 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Re: Public Domain
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86 04:17:37 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 20 Oct 86 07:12:26 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from faron.MENET by linus.MENET (1.1/4.7)
id AA26459; Mon, 20 Oct 86 07:14:57 EDT
Received: by faron.MENET (4.12/4.7)
id AA07286; Mon, 20 Oct 86 07:06:48 edt
Date: Mon, 20 Oct 86 07:06:48 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 20 Oct 86 07:06:48 edt
Message-Id: <8610201106.AA07286@faron.MENET>
To: jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK, scheme@mc.lcs.mit.edu
Subject: Re: Public Domain
The best way to find out the status of the
T project is to write to one of the following address:
t-project@yale.ARPA
decvax!yale!t-poject.UUCP
tproj@YALECS.BITNET
John
∂20-Oct-86 1205 @MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM [harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86 12:05:45 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 20 Oct 86 14:18:03 EDT
Received: from hplmhw by hplabs.HP.COM ; Mon, 20 Oct 86 11:16:01 pdt
Received: by hplmhw ; Mon, 20 Oct 86 10:55:43 pdt
Date: Mon, 20 Oct 86 10:55:43 pdt
From: Henry M. Wu <mhwu%hplmhw@hplabs.HP.COM>
Message-Id: <8610201755.AA00122@hplmhw>
To: scheme@mit-mc
Subject: [harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]]
From: Warren Harris <harris@hplabs>
Date: Wed, 15 Oct 86 16:56:50 PDT
Subject: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]
To: mhwu@hplabs
In-Reply-To: Your message of 15-Oct-86 13:34:39
X-Mailer: NMail [$Revision: 2.6 $]
Henry:
Please forward my interest in object-oriented extensions to scheme.
I am familiar with scoops and have a paper describing the system's many
shortcommings.
Warren Harris
-------
∂27-Oct-86 1824 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values: A Survey
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 18:24:23 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:21:24 EST
Received: from ti-csl by csnet-relay.csnet id ag12153; 27 Oct 86 18:08 EST
Received: from (home.ARPA) by tilde id AA25293; Mon, 27 Oct 86 16:12:30 cst
Received: by id AA29154; Mon, 27 Oct 86 16:08:57 cst
Date: Mon, 27 Oct 86 16:08:57 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272208.AA29154@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values: A Survey
Multiple Values: A Survey
--------------------------
The current proposal (from Will's lunch minutes) for multiple return
values consists of the two functions:
(receive-values <fcn> <mv-thunk>)
which applies <fcn> to the multiple values returned by <mv-thunk>. And:
(return <v1> ... <vN>) or
(values <v1> ... <vN>)
which returns the values <v1> ... <vN>.
Also, in the semantics there is an auxiliary function single, which
currently raises an error if multiple values are returned. Question (3)
deals with issue of making the auxiliary function available in the
language and questions (7) and (10) indirectly deal with the semantics
for single.
1) Syntactic questions:
1a) What argument order do we want for receive-values?
1b) Do we want to use a different name for receive-values? Eg.
Multiple-value-call, multiple-value-apply, or something else?
1c) What name do we want for the multiple value return construct?
Return, values, something else?
2) Do we want receive-values and return to be essential or
non-essential?
3) Do we want to incorporate the auxiliary semantic function single
into the language (see also (6b)) as:
(single <mv-thunk>)
such that
(single (lambda () (return <v1> ... <vN>))) => <v1>.
Should it be essential or non-essential?
4) Should receive-values allow multiple multiple-value-thunks in a manner
similar to Common Lisp's multiple-value-call? That is all the values
from the various multiple-value-thunks would be "concatenated" before
being passed to the function.
5) Interaction with call-with-current-continuation. How are multiple
values returned from a continuation? Presumably,
(call/cc
(lambda (cont)
...
(cont (return <v1> ... <vN>))))
does not work since the (return <v1> ... <vn>) is in argument position.
Furthermore, I presume that
(call/cc
(lambda (k)
(receive-values
k
(lambda () (return <v1> ... <vN>)))))
won't work, since the escape procedure generated by call/cc is a
"function" of one argument, which would make the above application of
receive-values analogous to:
(receive-values (lambda (x) ...)
(lambda () (return <v1> ... <vN>)))
which (presumably) is an error.
5a) Modify continuations to take a variable number of arguments that
are returned as the multiple values of the continuation. Eg.
(k <v1> ... <vN>)
5b) Add a new procedure called
call-with-multiple-values-current-continuation (or call/mv/cc for short)
that takes a function of one argument, a multiple value escape
procedure. The escape procedure takes a thunk as an argument and
transmits the values returned by the thunk. Eg.
(call/mv/cc
(lambda (k)
(k (lambda () (return <v1> ... <vN>)))))
5c) Somehow modify the existing version of call/cc so that when the
escape procedure k is invoked, (k v) returns v and
(receive-values k (lambda () (return <v1> .. <vN>)
returns <v1> ... <vn>.
5d) Somehow modify multiple values so that they can be cohesively
returned in argument position. I.e. so (cont (return <v1> ... <vN>)
would work. (See Opinion message.)
5e) Something else?
6) What forms pass multiple values through?
More likely than not the following (relatively) tail recursive forms
pass back multiple values.
6a) Do LAMBDA, LET and LETREC pass back multiple values from their
bodies?
6b) Do IF, COND and CASE pass back multiple values from the arms of
the conditional?
6c) Does explicit and implicit BEGIN blocks pass back multiple values
from the last form in the block?
But what about other forms?
6d) Does DO pass back multiple values from the last form in the exit
clauses?
6e) Do AND and OR pass back multiple values from the last form? Or
in OR's case from any form?
6f) Can FORCE return multiple values? (If so how is DELAY
implemented (i.e. how is make-promise written))
6g) What other forms pass back multiple values?
6h) Are there any forms that never pass back multiple values?
7) What happens when multiple values are returned to a context which
doesn't expect them as in predicate position within a conditional or
argument position within an application. For example:
(if (return v1 ... VN)
<then>
<else>)
or
(f (return v1 ... VN) ...)
7a) Coerce the multiple values to a single value as in Common Lisp.
7b) Instantiate a (first class) multiple values object (see Opinion
message)
7c) It would be an error.
7d) An error would be signaled.
7e) Other?
8) Do we want to augment existing binding forms (let, let* letrec) to
destructure multiple values or introduce a multiple value version for
each binding form, or not include such a capability? In each of the
following examples, b1 would be bound to <v1> ... and bN to VN. Which
is preferred?
8a) (let (((b1 ... bN) ;; i.e. ((ids*) <exp>)
(return <v1> ... <vN>))
<other-bindings>)
<body>)
or (perhaps)
8b) (multiple-value-let or (8c) (multiple-value-let
(b1 ... bN) (((b1 ... bN)
(return <v1> ... <vN>) (return <v1> ... <vN>))
<body>) <other-bindings>)
<body>)
or
8d) other
Should (a)-(d) (if any) be essential or non-essential?
9) Similarly, do we want to augment set! and define to accept multiple
values, define new versions of these constructs or not include these
constructs? (In the case of define, augmentation would be incompatible
with the non essential forms of define.) Do we want to make this
essential or non-essential syntax? In the case of set!, which of the
following is preferred?
9a) (set! (id1 ... idN) (return <v1> ... <vN>))
And (b) or (c) for define.
or
9b) (multiple-value-set! (id1 ... idN) (return <v1> ... <vN>))
(multiple-value-define (id1 ... idN) (return <v1> ... <vN>))
or
9c) (multiple-value-set! id1 ... idN (return <v1> ... <vN>))
(multiple-value-define id1 ... idN (return <v1> ... <vN>))
or
9d) other
10) For those constructs that expect multiple values (presumably,
receive-values, multiple-value-let, multiple-value-let*,
multiple-value-letrec, and multiple-value-set!) what happens when too
few or too many values are returned. For example in:
(multiple-value-let
(((Id1 ... IdM) (return <v1> ... <vN>)))
<body>)
M arguments are expected and N arguments are returned.
10a) N > M More values returned than expected.
1) Ignore extra values.
2) It is an error.
3) An error is signaled.
4) other.
10b) M > N More values expected than returned.
1) Return as many as needed additional default values.
2) It is an error.
3) An error is signaled.
4) other.
11) What (if any) other constructs do we want for returning multiple
values? What should their names be? Do we want a thunk or an
expression for the multiple values form (see (6c)). Should these
constructs be essential or non-essential?
11a) the equivalent of (receive-values (lambda x x) <mv-form>)
1) (multiple-value-list <mv-thunk>) or
2) (values->list <mv-thunk>) or
3) none
4) other
11b) The equivalent of (apply values <list>)
1) (values-list <list>)
2) (list->values <list>)
3) none
4) other
11c) The equivalent of
(receive-values (lambda x (list->vector x)) <mv-form>)
1) (multiple-value-vector <mv-thunk>) or
2) (values->vector <mv-thunk>) or
3) none
4) other
11d) The equivalent of (apply values (vector->list <vector>))
1) (values-vector <vector>)
2) (vector->values <vector>)
3) none
4) other
11e) Any others?
∂27-Oct-86 1859 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 18:58:50 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:15:18 EST
Received: from ti-csl by csnet-relay.csnet id af12153; 27 Oct 86 18:08 EST
Received: from (home.ARPA) by tilde id AA25245; Mon, 27 Oct 86 16:11:46 cst
Received: by id AA29149; Mon, 27 Oct 86 16:08:22 cst
Date: Mon, 27 Oct 86 16:08:22 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272208.AA29149@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values
I'd like to see a consensus emerge on multiple values. To that end I
have summarized the existing proposal and questions from Will's lunch
minutes and added a number of other questions and issues. As the text
of these questions and issues is somewhat long (280 lines) I have
submitted it in a separate message entitled "Multiple Values: A Survey".
Also, since my own responses to the survey depend on a particular view
of multiple values, I have submitted yet another message explaining my
views on these issues and my response to the survey. The latter message
is entitled "Multiple values: An Opinion". Enjoy!
-- brooks
∂27-Oct-86 2205 @MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA Multiple Values: An Opinion
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 22:04:37 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Oct 86 01:03:52 EST
Received: from ti-csl by csnet-relay.csnet id ah12153; 27 Oct 86 18:09 EST
Received: from (home.ARPA) by tilde id AA25301; Mon, 27 Oct 86 16:13:04 cst
Received: by id AA29167; Mon, 27 Oct 86 16:09:35 cst
Date: Mon, 27 Oct 86 16:09:35 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272209.AA29167@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values: An Opinion
Multiple Values: An Opinion
----------------------------
Values Objects
--------------
My view on multiple values is based on the principle that everything in
the language should be first class. For multiple values I postulate an
*IMMUTABLE* values object type. Values objects are created by the
values function. So,
(values <v0> ... <vN>)
creates a values object with values <v0> ... <vN>. Since values
objects are first class objects it would makes sense to bind a values
object to a (single) variable or cons up multiple value objects in a
list.
Components of a values object can be explicitly extracted with the
values-ref function. Like vectors, values object indexing is 0-based:
So,
(values-ref (values <v0> ... <vI> ... <vN>) I) ==> <vI>
Note that the function single can be simply defined as:
(lambda (vals) (values-ref vals 0))
The number of values in a values object can be computed with the
function values-length. Eg.
(values-length (values <v0> ... <vN>)) ==> N+1
Lastly, values objects can be identified by the predicate values?.
Values Objects and Identity
---------------------------
Since values objects are immutable they are intentionally
(operationally) identical (eqv?) if they have the same number of values
and if all the values are intentionally identical. Thus,
(eqv? (values <x1> <x2>) (values <y1> <y2>)) ==> #T
iff (eqv? <x1> <y1>) ==> #T and
(eqv? <x2> <y2>) ==> #T
Because of their immutability, The extensional identity (eq?-ness) of
multiple values is left unspecified. The contention here is that asking
the eq?-ness of values objects is uninteresting (maybe even
meaningless). It would be analogous to asking whether two bignums are
eq?.
Returning Values Objects
------------------------
A Values object is returned (directly or indirectly through a
continuation) just like any other type of object is returned.
Applying Functions to Values Objects
------------------------------------
Multiple-value-call takes a function and an expression which evaluates
to a values object and applies the function to the values in the values
object.
(multiple-value-call (lambda (x y) (+ x y)) (values 1 2)) => 3
Also, LAMBDA is augmented so that a lambda expression with a single
(unparenthesized) formal parameter (eg. (lambda x x)) is applied via
multiple-value-call, the formal parameter is bound to a values object of
all the actual parameters (Note BVL). Thus,
(multiple-value-call (lambda x x) (values 1 2)) <=> (values 1 2)
(Note: In (apply (lambda x x) ...), x would get bound to a list,
while in (multiple-value-call (lambda x x) ...), x would get bound to a
values object. I'm not enthused about the overloading of the single
unparenthesized bvl variable, but could not think of better syntax.)
Summary
-------
First class multiple values, values objects, are desirable for several
reasons:
1) It simplifies specifying which forms pass multiple values
through. Simply put, multiple values are passed through any form just
like any other values.
2) It simplifies from where multiple values can be returned. They can
be returned from anywhere. In contrast, in Common Lisp multiple values
can only be returned from the last form in an OR expression. In this
scheme multiple values can be returned from any form in an OR
expression.
3) In contrast to the original, thunkified proposal, the forms that
expect multiple values (multiple-value-call, single, etc.) could be
redefined such that the cumbersome multiple value thunks are replaced
with a simpler multiple value expression.
Eg. (single (lambda () (mvs ...))) => (single (mvs ...))
4) It simplifies the interaction with call/cc. To return multiple
values from a continuation just incant (cont (values <v0> ... <vN>)).
5) It allows programmers to manipulate multiple values without having
to inefficiently and unaesthetically coerce them to and from list structures.
Consider:
Expression oriented as opposed to thunk oriented.
(set! l (set! l
(cons (mvs ...) ...)) (cons
(multiple-value-call
list
(lambda () (mvs ...))
...)))
(multiple-value-call f (car l)) (apply f (car l))
Efficiency considerations
-------------------------
The immutability of values objects allows the compiler in cohoots with
the runtime system much latitude in representing multiple values. A
compiler/runtime strategy could be to return multiple values spread out
on the stack or in registers. When multiple values are returned to a
context which expects them the corresponding values object would never
have to be reified. For example, in
(define mvs (lambda (a b c) (values a b c)))
(multiple-value-let
(((x y z) (mvs 1 2 3)))
...)
a values object would not be allocated. Value objects would only have
to be allocated in the heap when multiple values are returned to a
context which is not expecting multiple values. For example,
(cons (values <v0> ... <vN> ) ...)
would require a values object to be allocated. However, a smart
compiler could avoid allocating a values object in many situations where
multiple values are indirectly expected. For instance, if the
equivalent of Common Lisp's (multiple-value-prog1 <exp1>... <expN>) was
implemented as:
(let ((x <exp1>))
<exp2>
...
<expN>
(multiple-value-call values x))
a smart compiler could avoid the allocation of the multiple values bound
to x by:
1) Leaving the multiple values returned by <exp1> spread out on the
stack.
2) Evaluating <exp2> through <expN>.
3) returning the spread out values of <exp1>.
Similar optimizations could be applied to multiple values returned by
know continuations, like cont, in:
(call/cc
(lambda (cont)
...
(cont (values <v0> ... <vN>))
...))
where the presence of the return in argument position would normally
require a values object to be allocated.
In even more esoteric situations, the compiler could represent (a
single group of) multiple values in a values object as well as spread out
on the stack. For example, in
(let [[[x (mvs ...)]]]
; spread x out on the stack for
; fast access
(multiple-value-call frob x) ; use the spread out values
(foo x) ; use the values object bound to x
(multiple-value-call frob x) ; use the spread out values, since
; we don't have to worry about
; foo side-effecting the values
; in x.
...)
My Answers to the Survey
------------------------
1) (a & b) (multiple-value-call <f> <mv-expression>)
(c) (values <v0> ... <vN)
2) Make multiple-value-call and values essential.
3) Include single as (single <mv-expression>) and make it non-essential.
4) Don't allow multiple multiple-value expressions in
multiple-value-call.
5) call/cc is not a problem with first class values objects.
6) Multiple values (i.e. values objects) are passed through forms just
like any other value is.
7) Just return a (first class) values object.
8, 9 & 10) Include:
(multiple-value-let (((ids*) form)*) <body>),
(multiple-value-let* (((ids*) form)*) <body>),
(multiple-value-letrec (((ids*) form)*) <body>) (maybe),
(multiple-value-set! (ids*) <form>), and
(multiple-value-define (ids*) <form>)
(maybe with mv-* nicknames) as non-essential. In any of the constructs
signal an error if too many or too few values are returned.
11) a) Include (values->list <mv-expression>) as non-essential.
b) Include (list->values <list>) as non-essential.
c) Include (values->vector <mv-expression>) as non-essential.
d) Include (vector->values <vector>) as non-essential.
e) other
include (values-ref <values-object> <index>) as essential
(values? <object>) as essential
∂28-Oct-86 0556 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 05:56:14 PST
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Oct 86 08:55:41 EST
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA21551; Tue, 28 Oct 86 08:49:57 est
Date: Tue, 28 Oct 86 08:49:57 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 28 Oct 86 08:49:57 est
Message-Id: <8610281349.AA21551@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Multiple values
Cc: ramsdell@mitre-bedford.ARPA
I do not see any need for anything other than
some thing like the T version of multiple values.
That is RECEIVE-VALUES, RETURN (possibly called
VALUES), and the macro RECEIVE.
It would be nice if escape procedures can be applied
to a variable number of arguments, so that the following
would work:
(receive-values
(lambda (x y) (list x y))
(call-with-current-continuation
(lambda (k) (k 1 2)))) => (1 2).
but given how often call-with-current-continuation is
used, I think we should be content to pass back list
structure in those rare cases.
I strongly object to Gary Brook's proposal for multiple
values. The idea of adding a new data structure
smacks of a case of reading the semantic specification
of Scheme too literally. Using sequences as arguments
to expression continuations is a trick to get around
the fact that functions only take one argument in the
lambda calculus. The T experience shows that trick
is not needed in real implementations.
The most serious objection I have to Gary Brook's
proposal was the design philosophy that is implicit
in the proposal. There seemed to be no attempt to
explain why his proposal had any merit over the much
simpler version as proposed by Will Clinger. Any proposal
to solve one single language problem with a large addition of
functions and macros must be accompanied by an explanation.
While such proposals may be the norm in the Common Lisp
community, we must all remember that the Scheme report
starts its introduction with the words "Programming languages
should be designed not by piling feature on top of feature,
but by removing the weaknesses and restrictions that make
additional features appear necessary."
John
∂28-Oct-86 0615 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 06:15:42 PST
Received: from geneva by MC.LCS.MIT.EDU 28 Oct 86 09:14:34 EST
Received: by GENEVA.AI.MIT.EDU; Tue, 28 Oct 86 09:13:52 est
Date: Tue, 28 Oct 86 09:13:52 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8610281413.AA14222@geneva>
To: ramsdell%faron%mitre-bedford.ARPA@mc
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: John D. Ramsdell's message of Tue, 28 Oct 86 08:49:57 est
Subject: Multiple values
I agree completely! All the extra mechanism proposed seems
unnecessary.
A single comments though,
What is the problem with having continuations expect multiple
arguments when they in fact are capable of returning them?
It seems to me that, it is not only the case that it would be nice if
(receive-values
(lambda (x y) (list x y))
(call-with-current-continuation
(lambda (k) (k 1 2)))) => (1 2).
worked, but instead it SHOULD work. Certainly the simplest
implementation of the whole mechanism that I can think of would take
care of this.
∂28-Oct-86 1358 @MC.LCS.MIT.EDU:andy@hobbes.ARPA Re: Multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 13:58:20 PST
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 28 Oct 86 16:46:55 EST
Date: Tue, 28 Oct 86 13:48:40 PST
From: andy@hobbes.ARPA (Andy Cromarty)
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Multiple values
If multiple values are to be defined for Scheme, I personally
would prefer that
(a) They be assigned inessential status, and
(b) Some comment be made in the R?RS admonishing implementors to
attempt to make lists be of roughly equivalent efficiency, or
suggesting some stylistic conventions for MV use.
The latter suggestion is motivated by frequent observation of
what seem to me to be excessive or abusive instances of MV use in
practical code written in other LISPs.
Returning both the number-theoretic quotient and the remainder
from a division routine seems like a use of MV's about which
few people would complain; but using MV's instead of creating
and passing composite data structures for related values that are
meant to be treated as an abstract object seems an unnecessary and
obfuscatory use of MV's. Often it seems people use MV's in such
cases either out of lack of aesthetic sense or because consing up
a data structure is too costly. An admonition to programmers could
address the former problem; and admonition to implementors, the latter.
asc
∂30-Oct-86 0139 @MC.LCS.MIT.EDU:harris%hplwhh@HPLABS.HP.COM Re: Multiple Values: An Opinion
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86 01:37:19 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 29 Oct 86 05:34:37 EST
Received: from hplabs.hp.com by CSNET-RELAY.ARPA id aa01350; 28 Oct 86 14:42 EST
Received: from hplms1. by hplabs.HP.COM ; Tue, 28 Oct 86 11:34:15 pst
Received: from hplwhh (hplwhh) by hplms1; Tue, 28 Oct 86 11:33:33 pst
Return-Path: <harris@hplwhh>
Received: by hplwhh ; Tue, 28 Oct 86 11:33:38 pst
From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Message-Id: <8610281933.AA05914@hplwhh>
Date: Tue, 28 Oct 86 11:33:30 PDT
Subject: Re: Multiple Values: An Opinion
To: brooks%home%ti-csl.csnet%csnet-relay.arpa@CSNET-RELAY.ARPA,
rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa@CSNET-RELAY.ARPA
In-Reply-To: Your message of 27-Oct-86 16:09:35
X-Mailer: NMail [$Revision: 2.6 $]
I'm sorry, I know I'm not supposed to be on this line, but I just had
to state my opinion of multiple values. I think this is one (!) of the
most poorly thought out (and most haphazardly integrated) concepts in
common lisp. I'd hate to see scheme suffer from the same disease.
First of all, I see no need for the construct whatsoever. Each of
the functions to deal with multiple values can be replaced by existing
scheme functions:
(values <v1> ... <vn>) => (list <v1> ... <vn>)
(receive-values <fn> <mv-thunk-or-1st-class-mv-obj>) => (apply <fn> <list>)
(single <mv-thunk-or-1st-class-mv-obj>) => (car <list>)
(multiple-value-set! (<id1> ... <idn>) <mvs>) =>
(map set! '(<id1> ... <idn>) <list>)
Therefore, the multiple value constructs add no new functionality to the
language (shame). They are simply included to increase lisp's efficiency
(a job which is best left up to the compiler). In light of todays cdr-coded
lists I would think consing can be accomplished as efficiently as vector
allocation for multiple-value objects. I would assume the same tricks could
be employed for register or stack allocation of some lists, as they are
returned to functions which immediately destructure them.
All of your efficiency considerations still hold:
Efficiency considerations
-------------------------
A compiler/runtime strategy could be to return lists spread out on the
stack or in registers. When lists are returned to a context which
expects them the corresponding list object would never have to be
reified. For example, in
(define mvs (lambda (a b c) (list a b c)))
(let* ((m (mvs 1 2 3))
(x (first m))
(y (second m))
(z (third m)))
...)
a list object would not be allocated. List objects would only
have to be allocated in the heap when lists are returned to a context
which is not expecting a list. For example,
(cons (list <v0> ... <vN> ) ...)
would require a list object to be allocated. However, a smart
compiler could avoid allocating a list object in many situations where
lists are indirectly expected. For instance, if the equivalent of
Common Lisp's (multiple-value-prog1 <exp1>... <expN>) was implemented
as:
(let ((x <exp1>))
<exp2>
...
<expN>
x)
a smart compiler could avoid the allocation of the list bound
to x by:
1) Leaving the list returned by <exp1> spread out on the
stack.
2) Evaluating <exp2> through <expN>.
3) returning the spread out list of <exp1>.
Similar optimizations could be applied to lists returned by
know continuations, like cont, in:
(call/cc
(lambda (cont)
...
(cont (list <v0> ... <vN>))
...))
where the presence of the list in argument position would normally
require a list object to be allocated.
-----
Lets work at optimizing the compiler, not giving the programmer
his own hooks to optimize. I think most people avoid multiple values
anyway.
Warren Harris
HP Labs, bld 3U
1501 Page Mill Rd.
Palo Alto, CA 94040
harris%hplwhh@hplabs.HP.COM
P.S. How about a nice destructuring facility similar to multiple-value-bind
except for lists (like zetalisp's destructuring-bind). For example, what
could be implemented with multiple values as:
(defun foo (x y z) (values x y z))
(multiple-value-bind (x y z) (foo 1 2 3))
or regular lists as:
(defun foo (x y z) (list x y z))
(let* ((all (foo 1 2 3))
(x (first all))
(y (second all))
(z (third all)))
...)
could be more concisely stated as:
(destructure (x y z) (foo 1 2 3)
...)
Also, arbitrary trees could be destructured:
(destructure ((x . y) z) '((a b c d) e)
(print y))
=> (b c d)
This would help the compiler in its optimization, as well as give the
programmer a succinct syntax for a routine procedure.
-------
∂30-Oct-86 1228 @MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86 12:28:10 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 11:32:29 EST
Received: from tektronix by csnet-relay.csnet id ab14659; 29 Oct 86 15:49 EST
Received: by tektronix.TEK (5.31/6.16)
id AA02978; Wed, 29 Oct 86 12:26:44 PST
Received: by tekchips.TEK (5.31/6.16)
id AA08573; Wed, 29 Oct 86 12:28:59 PST
Date: Wed, 29 Oct 86 12:28:59 PST
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610292028.AA08573@tekchips.TEK>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
The language syntax and procedure library both favor calling with multiple
arguments over returning multiple values (no surprise considering that we
haven't have multiple return values in the language).
I seems to me easier to fix the procedure library than the syntax.
(Anyone want to adopt the "{...}n" notation that Steele mentions
in "The Ultimate Declarative"?)
Gary's survey identifies some rough edges that adding multiple values
causes. I favor:
a) changing call-with-current-continuation as described in 5a
(call/cc creates n-ary procedures that invoke the continuation with as
many arguments)
b) using RECEIVE (or the equivalent), instead of the alternatives of
either hacking up all the binding forms, or adding a bunch of
new binding forms.
c) living with it until we have more experience.
I'm for no coersions, no multiple-value-call.
-Norman
-------
∂30-Oct-86 1339 @MC.LCS.MIT.EDU:jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA Multiple Values: An Opinion
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86 13:39:33 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 16:38:01 EST
Received: from geneva.ai.mit.edu by CSNET-RELAY.ARPA id aa01525;
30 Oct 86 10:51 EST
Received: by GENEVA.AI.MIT.EDU; Thu, 30 Oct 86 10:42:41 est
Date: Thu, 30 Oct 86 10:42:41 est
From: "Guillermo J. Rozas" <jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA>
Message-Id: <8610301542.AA17018@geneva>
To: harris%hplwhh@HPLABS.HP.COM
Cc: brooks%home%ti-csl.csnet%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA,
rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA
In-Reply-To: Warren Harris's message of Tue, 28 Oct 86 11:33:30 PDT
Subject: Multiple Values: An Opinion
I'm sorry, I know I'm not supposed to be on this line, but I just had
to state my opinion of multiple values. I think this is one (!) of the
most poorly thought out (and most haphazardly integrated) concepts in
common lisp. I'd hate to see scheme suffer from the same disease.
I can understand your objections when you look at the CL book and
examine the rules for when multiple values are passed back and not.
On closer inspection, however, you will notice that the rule is
uniform (although specified in utmost detail): When dealing with a
compound expression, multiple values are passed back from the
subexpression into which the evaluation of the compound expression
reduces. In other words, tail-recursion is what determines when
multiple values are passed back. Unfortunately CL does not require
its implementations to be properly tail-recursive, so they could not
explain the semantics of multiple values in terms of tail-recursion.
We don't have this problem, so the behaviour can be described simply,
and the huge case list can be added as examples, not as the definition
of the bahaviour.
Agreed that there is no semantic need for multiple values, and that
the main consideration is efficiency, but there is no reason not to
add them to the language with inessential status, as long as we also
specify that implementations are free to make them be the obvious
procedures which work on lists, or even the suggestion below (which I
prefer).
I don't agree with you on one count however. Most of the compiler
optimizations that I see proposed very often suffer from a few bad bugs:
- The idea is simple, so it is assumed that the implementation is also
simple. This is obviously a fallacy. I'm specially wary of
optimizations that require a great deal of analysis. I'm not saying
it cannot be done, just that it is often the case that it takes a
great deal more work than anticipated.
- The optimizations break down across module boundaries. The main
problem with static analysis is that it needs a closed world model.
This is often hard to provide, and even inappropriate in an
interactive development environment.
- Static optimizations to improve performance badly hurt interpreters.
I know the MIT crowd is in the minority here, but we believe in
interpreters as our main development tool. Although we also want high
performance compilers, we don't want to sacrifice any performance in
the interpreter.
Consider the following proposal instead, which does not require much
(if any) compiler overhead:
(define (receive-values fn th)
((th) fn))
(define (values . all)
(lambda (receiver)
(apply receiver all)))
Note that a compiler which understands a little about tail arguments
can optimize the above relatively easily, given that the construction
and destructuring of the list is purely local and contained inside
VALUES. Even further, since the whole mechanism is contained in 2
procedures, they can easily be implemented as primitives, with
whatever efficiency is desired. Static compiler analysis to reduce
consing can still be used, but this time it is closure analysis of the
sort many Scheme compilers already do.
Note that the above proposal implies that intermediate forms in AND,
OR, and possibly other special forms would have to be treated
specially, since there is a difference between returning a "normal"
value, and explicitely returning 1 value.
PS: There are two other objections to your message, both minor:
- SET! is a the keyword of a special form, thus it cannot be mapped.
- I (and a fair amount of other people) do not believe in cdr-coding.
It is clearly expensive on stock hardware, and it is not clear to me
that it is not expensive on special purpose hardware, besides adding
unnecessary hair to the complete system and in particular the garbage
collector, and we all know where this leads.
∂30-Oct-86 1520 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86 15:20:03 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 30 Oct 86 15:27:28 EST
Date: Thu 30 Oct 86 12:25:22-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8610292028.AA08573@tekchips.TEK>
Message-ID: <12250998624.20.ANDY@Sushi.Stanford.EDU>
I'd like to bring up another multiple-value proposal but first I
have a question. Why is the scheme community attempting to
standardize this now? Is it really that well understood?
This proposal is a variant on the technique Carolyn Talcott used
in her thesis; Richard Weyrauch was also involved in that work.
Their idea requires one procedure; I'll call it values. Procedure
invocation spreads multiple values; (cons (values 1 2)) is completely
equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is
equivalent to (list 4 1 2 3). (It should be obvious that (values 1)
is completely equivalent to (values (values 1)).) In Talcott's
system, the last variable in a lambda expression's formal argument
list is preceded by an implicit period; I feel that the optional
explicit period of r↑3rs' syntax is superior.
Call/cc is generalized appropriately as well. If I understand
receive-values correctly, it is the same as apply.
Most of the other proposals strike me an attempt to add yet another
aggregate data type (in addition to lists and vectors) that predefined
procedures will use to return a number of values. This is not a bad
idea, different implementations can use different representations, yet
the coercion rules and additional procedures (if a form returns
multiple values, all but the first are discarded unless the programmer
has mastered subtle rules involving tokens not unlike funcall and #')
bother me.
Talcott's scheme is succinct and builds on the rest of the language.
(Look how much of this message was used to explain the idea.) Its
only disadvantage is that you can't tell how many arguments are being
passed by counting s-expressions.
-andy
-------
∂30-Oct-86 2204 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86 22:03:57 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 OCT 86 22:06:22 EST
Date: Thu, 30 Oct 86 22:08:03 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU, klotz@OZ.AI.MIT.EDU
In-reply-to: Msg of Mon 27 Oct 86 16:08:57 cst from Gary Brooks <brooks%home%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].112644.861030.JAR>
Since I'm the one who added the procedures VALUES (a.k.a. RETURN) and
RECEIVE to T, it seems appropriate that I should say a word or two about
what the heck I had in mind when I did so.
In the T implementation, the low-level protocols for call to unknown
procedure and return to unknown continuation are almost identical. The
compiler does CPS conversion and doesn't see the difference much, and
the data representation for implicit continuations is the same as that
for procedures.
The implementation symmetry suggested that maybe some surface-language
symmetry was worth experimenting with. This was corroborated by the
frequent need for some way to return more than one result value to the
caller. I had been doing the latter with
(foo arg1 arg2 ... argn (lambda (val1 val2 ... valm) body)),
and this syntax seemed pretty unweildy (it doesn't indent nicely, for
example); using lists and destructuring wasn't much better. So in T2,
anticipating future compiler support in T3, a procedure VALUES was
defined to be more or less the same as LIST (actually closer to VECTOR
-- the details are irrelevant), and a macro RECEIVE was invented to get
result values:
(receive (val1 val2 ... valm)
(foo arg1 arg2 ... argn)
body)
== (apply (lambda (val1 val2 ... valn) body)
(foo arg1 arg2 ... argn))
The beauty of VALUES and RECEIVE is that they're totally noncommittal
about implementation. The above is a correct implementation of the
abstraction, but so is the T3 implementation, where
(define (values . vals)
(c-w-c-c (lambda (k) (apply k vals))))
and
(receive (val1 val2 ... valm)
(foo arg1 arg2 ... argn)
body)
== (receive-values (lambda () (foo arg1 arg2 ... argn))
(lambda (val1 val2 ... valm) body))
[maybe I have the argument order reversed, I alwasy forget]
and RECEIVE-VALUES is a new primitive procedure. (We'd never expect a
user to invoke RECEIVE-VALUES explicitly, but it has to exist so that
RECEIVE can be a macro rather than a special form. It would be
necessary in Scheme to exactly the same extent that MAKE-DELAY is
necessary, which is somewhat.)
Thus if T programs have to ported to some other Scheme dialect, or if T
decides at some future point that multiple-value-returns are a horrible
idea and should be retracted, all our code will still work because the
abstraction is noncommittal. The nice thing is simply the notation, not
the implementation. The fact that T3 implements it well encourages its
use (and makes GC's less frequent, which, unfortunately, is a concern),
but is incidental.
A small benefit of having this facility be primitive is that you have an
opportunity for some error checking not previously available, namely you
can get wrong-number-of-return-value errors. This is good for the same
reason that wrong-number-of-argument errors are good. But note that it
is a necessary condition in order for the facility to permit varying
implementations.
(I don't see strong reasons for adding destructuring to LET or for any
other linguistic support for the multiple return values besides VALUES
and RECEIVE.)
I'm still not sure how I feel about the feature. Certainly the
abstraction is a good idea. As for the semantical foundations, I feel
pretty strongly that call and return should be symmetrical. If you can
have many arguments, you should be able to return many values. But note
that (P -> Q) does not necessarily imply Q, it might imply not P. My
opinion now is that it's probably better to achieve symmetry by flushing
multiple-argument procedures rather than by introducing multiple-value
returns, but this is incompatible with the present shape of Scheme, so I
won't recommend it for this audience.
Gary gives good reasons for introducing immutable data structures.
Algol 68 and ML have the right idea; Lisp and Scheme got it wrong. It
would certainly be worthwhile to experiment with immutable pairs,
strings, and vectors. Adding immutable objects onto Scheme (especially
one type without the others) might be a mistake, and it could be the
case that adding immutable objects as an afterthought like this,
coexisting with mutable objects, would result in a very inelegant
language. (Maybe it could result in a very elegant language... anyone
for ((immutably cons) x y)? I don't know.) But I think this is a
question independent of the multiple-value question, and Gary's proposal
is both more complicated and has more far-reaching consequences than
RECEIVE and VALUES, which are trivial.
I like the idea of adding RECEIVE and VALUES to Scheme *without
specifying what happens when some VALUES go somewhere other than to a
RECEIVE*. The mechanism can be added trivially to any Scheme, and those
that want to optimize it (or which already do) may feel free.
Minimalists can implement the mechanism with lists or closures, Gary can
implement it with immutable vectors, Schemes which are embedded in
Common Lisp or cohabit with it may use CL's multiple values, and T can
do what it does. It is minimal and noncommittal, it's a pleasant
notation, it captures a common pattern of usage, so why not.
- Jonathan
∂31-Oct-86 1840 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 18:40:33 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 OCT 86 21:39:55 EST
Date: Fri, 31 Oct 86 21:41:46 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 31 Oct 86 03:23:10 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].113058.861031.JAR>
Date: Fri, 31 Oct 86 03:23:10 EST
From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
I don't use CL multiple values in any situation where LIST will
suffice. I use it just in case I want some "by-products" to be
transparently discarded by all but a few callers. This is why
multiple values were added to the Lisp Machine in the first place,
and its still the only reason I see to use it.
...
As Alan has tactfully pointed out to me, none of the multiple-value
features that Gary Brooks and Andy Freeman and I and others have been
talking about bear much resemblance to CL multiple values, and they are
really intended to solve a different problem. The terminology is a
problem here; we really shouldn't be saying that these constructs do
"multiple value returns" because Lisp Machine Lisp and its derivatives
(CL) have been using that term for quite a while to mean something quite
different. (I might have called the LM feature "extra value returns"...)
We should no more think that we're "cleaning up something CL
did wrong" than we should think that omitting optional or keyword arguments,
or macros or packages, solves the problems that those features
were introduced to address.
I agree that the RECEIVE/VALUEs feature is of marginal usefulness. I
don't think this is the most important outstanding issue we have to talk
about; macros, modules, opaque types, tables, and even bitwise logical
operators all loom larger. Of course, the more agreement we can get on
any feature at all, the better.
A suggestion on how to proceed: we needn't think of every discussion as
aiming towards something to be included in R↑4RS. If just 2
implementations agree on a way to do something, we have still gained
something. We should consider creating an auxiliary document, much more
informal and open-ended than a R↑nRS, describing possibilities for
standard libraries and utilities, possibly with multiple different ways
to do things if no agreement can be reached. Unanimity may be too
stringent a requirement if this group is to make much progress....
Jonathan
∂31-Oct-86 1916 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Journal of Lisp and Symbolic Computation -- call for papers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 19:15:57 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 OCT 86 22:09:15 EST
Date: Fri, 31 Oct 86 22:11:09 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Journal of Lisp and Symbolic Computation -- call for papers
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].113067.861031.JAR>
Date: Fri, 31 Oct 86 12:34:05 PST
From: edsel!sunvalleymall!jlz at navajo.stanford.edu (Jan Zubkoff)
To: navajo!Common-lisp%sail at navajo.stanford.edu
cc: sunvalleymall!jlz at navajo.stanford.edu
Re: Call for Papers
Message-Id: <8610312034.AA09846@sunvalleymall.edsel.uucp>
LISP AND SYMBOLIC COMPUTATION:
An International Journal
10/27/86
CALL FOR PAPERS
LISP AND SYMBOLIC COMPUTATION: An International Journal (LASC) is
a new journal published by Kluwer Academic Publishers. Richard
P. Gabriel, Lucid, Inc. and Guy L. Steele Jr., Thinking Machines,
Inc. are Editors-in-Chief.
The aim of this new journal is to present a forum for current and
evolving symbolic computing, focusing on LISP and
object-oriented programming. The scope includes:
* Programming language notations for symbolic computing
(e.g., data abstraction, parallelism, lazy evaluation,
infinite data objects, self-reference, message-passing,
generic functions, inheritance, encapsulation,
protection, metaobjects).
* Implementations and techniques (e.g., specialized
architectures, compiler design, combinatory models,
garbage collection, storage management, performance
analysis, smalltalks, flavors, common loops, etc.).
* Programming logics (e.g., semantics and reasoning about
programs, types and type inference).
* Programming environments and tools (e.g.,
Knowledge-based programming tools, program
transformations, specifications, debugging tools).
* Applications and experience with symbolic computing
(e.g., real-time programming, artificial intelligence
tools, experience with LISP, object-oriented
programming, window systems, user interfaces, operating
systems, parallel/distributed computing.
!
REQUIREMENTS FOR SUBMISSION
Timetable. Authors must submit five (5) complete copies of their papers.
Notice of acceptance or rejection will be sent to the first author.
Appearance. Each copy of the paper should be clearly legible.
Papers should be printed on 8-1/2 by 11" paper, double spaced
with at least 1 inch margins with no smaller than 12 pt. type.
Title Page. Each copy of the paper must have a title page (separate from
the body of the paper) containing the title of the paper, the names and
addresses of all the authors. The affiliation appearing under the author's
name should be the name of the organization for which the work was carried
out. When this is no longer the author's current affiliation, the latter
is given in the address footnote on the first page. The title page must
specify one topic from the scopes listed on the reverse side of this page.
Abstract. The abstract should be 150 to 200 words and should be short and
direct. It should be informative enough to serve as a substitute for
reading the paper itself. Work planned but not done should not be
described in the abstract. Do not display formulas and do not use citation
reference numbers.
Review Criteria. Each paper will be reviewed by experts in the area
specified from the scope as the topic of the paper. Acceptance will be
based on overall merit and significance of the reported research, as well
as the quality of the presentation.
Please send papers to:
Jan Zubkoff
Associate Editor, LASC
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@su-navajo
(415) 329-8400
Suggestions and inquiries to:
Dick Gabriel Guy L. Steele Jr.
Editor-in-Chief Editor-in-Chief
Lucid, Inc. Thinking Machines, Inc.
707 Laurel Street 245 First Street
Menlo Park, CA 94025 Cambridge, MA 02142
rpg@sail gls@think.COM
(415) 329-8400 (617) 876-1111
∂03-Nov-86 0855 @MC.LCS.MIT.EDU:gls@Think.COM Marvel?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 08:54:35 PST
Received: from Godot.Think.COM (TCP 30001264307) by MC.LCS.MIT.EDU 3 Nov 86 11:33:56 EST
Received: from polycarp by Godot.Think.COM via CHAOS; Mon, 3 Nov 86 11:22:41 est
Date: Mon, 3 Nov 86 11:24 EST
From: Guy Steele <gls@Think.COM>
Subject: Marvel?
To: ANDY@Sushi.Stanford.EDU, gjs@MC.LCS.MIT.EDU, rrrs-authors@mc.lcs.mit.edu
Cc: rpg@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <12251488191.9.ANDY@Sushi.Stanford.EDU>
Message-Id: <861103112403.4.GLS@POLYCARP.THINK.COM>
Date: Sat 1 Nov 86 09:14:39-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Apparently you wrote a language that had a multiple values
scheme much like the one I attributed to Talcott and Weyrauch.
Can you comment on it to rrrs-authors? (T&W like it and have
stayed with it; you abandoned it. I'm sure both had their
reasons.)
Yes. For a while I worked on a dialect of Scheme called MARVEL
(Multiple-Return-Value--Expression Lisp; if you ask "where does
the `A' come from?" I say "A is for Acronym").
It did pretty much all the obvious things: every function call was
implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and most
side-effecting forms such as SETQ, PRINT, and COMMENT were made to
return zero values. I believe I also arranged for variables to
be able to hold multiple values.
My experience with the language was that it was perfectly clean
and elegant, but programs that made non-trivial use of multiple
values were very hard to read, precisely because of the loss
of the one-form/one-value correspondence. Having the extra power
everywhere in the language was not worth the loss of clarity.
I therefore abandoned the experiment without writing it up.
(Maybe I should have, but there were other, more promising variations
of Scheme to explore.)
I am cc'ing this message to Dick Gabriel, who worked with Weyrauch on
the implementation of SEUS, a language with this geneal flavor. I
recall him having reported to me the same results with their language,
but he should have the chance to speak for himself.
I believe that experience with the POP languages (especially POP-2)
may be relevant to ths discussion, but I am not an expert there.
--Guy
∂03-Nov-86 1221 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU gls@AQUINAS/cc
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 12:19:28 PST
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Nov 86 15:16:56 EST
Date: 03 Nov 86 1214 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: gls@AQUINAS/cc
To: ANDY@SUSHI.STANFORD.EDU, gjs@MC.LCS.MIT.EDU,
rrrs-authors@MC.LCS.MIT.EDU
Multiple Values
I wrote the SEUS compiler for the HP300 (?) version of SEUS. SEUS had
what-I-guess-are-now-called CARTs, which are coalescing multiple values.
Whenever 2 CARTs came near each other, they joined into one larger
one. This resulted in this code
(defun foo (x) (values x x x))
(defun bar (x)(values x x x x))
(list (foo 1)(bar 2)(foo 3))
doing this
=> (1 1 1 2 2 2 2 3 3 3)
The code, as Steele mentions, was elegant in a certain sense, but very
hard to read most of the time, because you had to take into account that
some other values than the primary value (the first one) would be passed
to some program. The places where SEUS code was easy to read were when you
were writing something that, in Common Lisp, would be
(multiple-value-call #'foo (baz)(bar))
The places where it was hard to read were when you were writing something
that, in Common Lisp, would be
(foo (baz) (bar))
That is, there was no easy way to check that the right values from the
right places got passed. I think that the latter is the more commonly
used case, so SEUS was optimized the wrong way.
It was hard to do this:
(defun foo (x)(values x (+ x 1) (+ x 2)))
(defun baz (x y) ...)
such that calling BAZ on (FOO 1) and (FOO 2) passed 1 and 2 to BAZ.
I recall that SEUS had no way to do this until I was half-way through
writing the compiler. I also recall that variables could be bound to
CARTs, somehow, as part of the solution to the problem - that is,
you could get X to be bound to the CART, [1 2 3], and Y to [2 3 4].
When the Common Lisp multiple value scheme was being devised, I thought
that we (the designers) should look at SEUS for its experience. I'm now
glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a
result of that experience.
-rpg-
∂05-Nov-86 0305 @MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA [Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 03:04:56 PST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU 5 Nov 86 06:00:47 EST
Date: Wed 5 Nov 86 02:48:18-PST
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: [Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]
To: JAR@AI.AI.MIT.EDU, SCHEME@MC.LCS.MIT.EDU
Message-ID: <12252466434.15.GOERZ@SUMEX-AIM.ARPA>
Mail-From: GOERZ created at 24-Oct-86 03:24:44
Date: Fri 24 Oct 86 03:24:44-PDT
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: CScheme for 68K
To: scheme%mit-mc.csnet@RELAY.CS.NET
cc: Goerz@SUMEX-AIM.ARPA
Message-ID: <12249316417.13.GOERZ@SUMEX-AIM.ARPA>
Patrick Greussay of the Univ of Paris 8 and LITP has implemented (at least
one version of) SCHEME in C which is running on a variety of machines,
including 68000 systems.
--Guenther
-------
-------
∂07-Nov-86 0351 @MC.LCS.MIT.EDU:enea!tut!jh@seismo.CSS.GOV eval and orbit
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86 03:51:47 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 7 Nov 86 06:46:47 EST
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA25326; Fri, 7 Nov 86 06:45:33 EST
Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.8)
id AA01199; Fri, 7 Nov 86 12:26:05 +0100 (MET)
Date: Fri, 7 Nov 86 13:20:28 -0200
From: enea!tut!jh@seismo.CSS.GOV (Juha Hein{nen)
Return-Path: <jh@tut>
Message-Id: <8611071120.AA033441@tut.uucp>
To: scheme@MC.LCS.MIT.EDU
Subject: eval and orbit
I asked to be put on this list a couple of weeks ago and haven't
received any postings. Here comes mine as a test.
1. What is the rational in omitting eval from Scheme?
My program is supposed to read values of enumerated types (i.e.
symbols) and then convert the symbols to their values. In regular
Lisp I would write (eval (read)) to get the value but how am I
supposed to do that in Scheme? Use a mapping function from names to
values or is there a simpler way?
2. Where can I get the Orbit Scheme compiler for my Sun-3
workstation?
Juha Heinanen
Tampere Univ. of Technology
Finland
∂07-Nov-86 1716 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Automatic removal from list...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86 17:16:39 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86 20:11:13 EST
Date: Fri, 7 Nov 86 20:13:16 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Automatic removal from list...
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115915.861107.JAR>
Scheme@MC is a big mailing list. On average, one or two members become
unreachable each week, due to changes in routing, gateways being down,
etc. Be warned that I will ruthlessly remove from the list any
recipients to whom mail is undeliverable. If you change your address,
be sure to send a note to Scheme-Request@MC. If your machine has been
down or off the net for a while (usually the various mail systems retry
for three to seven days), and mail bounces as a result, you will likely
be removed. This is the only way I'll be able to keep things under
control and prevent people who send messages to Scheme from being
deluged with enormous quantities of bounced mail. Just send me a
message when you're back on, or if you think one of your gateways could
have been down and you haven't seen a message for a couple of weeks.
I sure hope that one of these days electronic mail will be able to reach
people as reliably as physical mail does. The current state of the art
of e-mail is quite inferior in the respect, probably at about the same
point of development that physical mail was in about the 15th century.
Jonathan
∂07-Nov-86 1817 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU MIT AIM 848a
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86 18:17:33 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86 20:49:51 EST
Date: Fri, 7 Nov 86 20:51:52 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: MIT AIM 848a
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115926.861107.JAR>
I'll mail copies to y'all (unless I don't have your address or you tell
me not to or you already have one).
Jonathan
∂07-Nov-86 1839 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Hot off the press...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86 18:39:15 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86 20:46:45 EST
Date: Fri, 7 Nov 86 20:48:46 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Hot off the press...
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115925.861107.JAR>
The new report is ready! Get them while they last!
It's available in a handsome red binding from the MIT AI Lab
publications office; the address is:
Elizabeth Heepe
Publications, Room NE43-818
MIT Artifical Intelligence Laboratory
545 Technology Square
Cambridge MA 02139
Ask for MIT Artificial Intelligence Memo 848a, the "Revised↑3 Report on
the Algorithmic Language Scheme". Enclose a check for $6.00 per copy
(U.S. funds) payable to the MIT Artificial Intelligence Laboratory.
Prepayment is required.
This version (dated September 1986) supersedes last summer's report,
which was AI memo 848 (this one is 848a). It also supersedes (but is
very similar to) the draft which was passed out at the Lisp and FP
Conference in August.
It is identical (same original) to the version that will be printed in
SIGPLAN this December, except that in the MIT AI memo version it
additionally includes a previously unpublished article by Abelson and
Sussman entitled "Computation: An Introduction to Engineering Design".
If you want to cite it, probably better to cite the SIGPLAN version
since that will be available to a wider audience:
Jonathan Rees and William Clinger, editors.
"Revised↑3 Report on the Algorthmic Language Scheme."
SIGPLAN Notices 21(12), September 1986.
The report will also appear as an Indiana University CSD Technical
Report.
Here is a brief summary of the more important differences between the
1985 and 1986 versions of the language:
- Added: delay, force, boolean?, procedure?
- Removed: #!null, rec, named-lambda, append!, object-hash,
object-unhash, 1+, -1+, some of the string operators,
"curried define"
- Redundant names removed: sequence, =?, <?, <=?, >?, >=?
- Renamed: #!true -> #t, #!false -> #f
- Changed: (define (foo ...) ...) now means
(define foo (lambda (...) ...)), not
(define foo (named-lambda (foo ...) ...))
Other, lesser, changes are enumerated in a special section on page 36.
- Jonathan Rees
∂08-Nov-86 1121 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86 11:21:13 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 NOV 86 14:21:03 EST
Date: Sat, 8 Nov 86 14:23:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].116160.861108.JAR>
I didn't mean for my message to squelch debate. Surely someone
disagrees with me. Speak up.
Jonathan
∂08-Nov-86 1303 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:REMARCK@UCLASSCF.BITNET This account is scheduled to be deleted soon...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86 13:03:50 PST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 8 Nov 86 15:57:21 EST
Received: from UCLASSCF(MAILER) by MITVMA (Mailer X1.23) id 8286;
Sat, 08 Nov 86 15:51:19 EST
Received: by UCLASSCF (Mailer X1.23) id 3781; Sat, 08 Nov 86 12:41:14 PST
Date: Sat, 08 Nov 86 12:39:12 PST
From: REMARCK@UCLASSCF (Marc Kriguer)
To: scheme@MC.LCS.MIT.EDU
Subject: This account is scheduled to be deleted soon...
And to avoid the last-minute rush, I have to start dropping myself from
all the mailing lists I am on. Please remove my name from the
scheme mailing list.
Thank you very much!
Marc Kriguer
∂09-Nov-86 0851 @MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU eval and orbit
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 86 08:50:51 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 NOV 86 11:47:16 EST
Date: 9 Nov 1986 11:45 EST (Sun)
Message-ID: <JINX.12253580092.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: enea!tut!jh@SEISMO.CSS.GOV (Juha Hein{nen)
Cc: scheme@MC.LCS.MIT.EDU
Subject: eval and orbit
In-reply-to: Msg of Fri 7 Nov 86 13:20:28 -0200 from enea!tut!jh at seismo.CSS.GOV (Juha Hein{nen)
My program is supposed to read values of enumerated types (i.e.
symbols) and then convert the symbols to their values. In regular
Lisp I would write (eval (read)) to get the value but how am I
supposed to do that in Scheme? Use a mapping function from names to
values or is there a simpler way?
Besides the fact that EVAL is not really necessary for most
programming, the problem is that we could not agree on what eval would
mean or do (we didn't try very hard because of the other reason):
Some implementations have a single global environment where
expressions could be evaluated. In these implementations (eval <x>)
would make sense.
Other implementations have multiple environments where code can be
evaluated. In these implementations (eval <x>) does not make much
sense. Eval needs to take a second argument specifying what
environment to evaluate in, and it is not clear that a reasonable
default can be provided so that 1 argument EVAL could work.
You should use a mapping function or something like it if you want
your code to be portable. Most implementations have an EVAL procedure
(with different behavior) which you can use if you don't care about
that.
∂10-Nov-86 1301 @MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@RELAY.CS.NET Re: multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 86 13:01:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Nov 86 16:02:09 EST
Received: from tektronix by csnet-relay.csnet id al11458; 10 Nov 86 15:24 EST
Received: by tektronix.TEK (5.31/6.16)
id AA09527; Mon, 10 Nov 86 10:53:31 PST
Received: by tekchips.TEK (5.31/6.16)
id AA04254; Mon, 10 Nov 86 10:53:46 PST
Message-Id: <8611101853.AA04254@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: multiple values
In-Reply-To: Your message of Fri, 31 Oct 86 21:41:46 EST.
<[AI.AI.MIT.EDU].113058.861031.JAR>
Date: 10 Nov 86 10:53:41 PST (Mon)
From: willc%tekchips.tek.csnet@RELAY.CS.NET
I didn't mean for my message to squelch debate. Surely someone
disagrees with me. Speak up.
Ok, Jonathan. I won't say much because I'm very busy right now. The
message in question:
As Alan has tactfully pointed out to me, none of the multiple-value
features that Gary Brooks and Andy Freeman and I and others have been
talking about bear much resemblance to CL multiple values, and they are
really intended to solve a different problem. The terminology is a
problem here; we really shouldn't be saying that these constructs do
"multiple value returns" because Lisp Machine Lisp and its derivatives
(CL) have been using that term for quite a while to mean something quite
different. (I might have called the LM feature "extra value returns"...)
We should no more think that we're "cleaning up something CL did wrong"
than we should think that omitting optional or keyword arguments,
or macros or packages, solves the problems that those features
were introduced to address.
I see more of a resemblance than Jonathan does. I happen to think that
CL came close to getting multiple values right, failing only in the choice
of primitives, the complexity of the specification (which, as someone has
observed, was due to the fact that CL doesn't do tail recursion right), and
in the over-reliance upon special forms (which is consistent with the rest
of CL).
The main difference between the RECEIVE/VALUES proposals I've seen and
the way CL does it is that people in the Scheme community seem to assume
that most continuations will require exactly one result, while in CL all
continuations accept any number of results (up to 20, anyway). It seems
to me, however, that if you're going to have an efficient implementation
mechanism that supports continuations that accept an arbitrary number of
results, then it shouldn't be too hard to make all continuations accept
an arbitrary number of results. Whether we do this or not should be
determined by whether we think CL got this part of it right.
I like the idea of adding RECEIVE and VALUES to Scheme *without
specifying what happens when some VALUES go somewhere other than to a
RECEIVE*.
Me too. For one thing, it makes it legal for a Scheme to implement
CL-style semantics for multiple values.
Peace, Will
∂10-Nov-86 1904 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU silly multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 86 19:03:46 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 10 Nov 86 22:04:23 EST
Date: Mon 10 Nov 86 19:00:15-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: silly multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].116160.861108.JAR>
Message-ID: <12253954092.9.ANDY@Sushi.Stanford.EDU>
I once saw a proposal for passing arguments with the name used by the
callee. The idea was that the caller could pass them in any order and
the names provide some documentation. (I think this came up in a
keyword discussion on CommonLisp; KMP, do you remember more? BTW - I
don't think it is a good idea.) For example:
(cons car 'a cdr 'd) = (cons cdr 'd car 'a)
The major problem with using this idea for returning values is
figuring out the inheritance of named values. One possible definition
is the following.
The names of returned values have dynamic scope. The special form
"receive" creates a context for receiving named values. Its first
argument is a list of the names of the values to be received, its
second argument produces them, and following arguments use them.
The special form "establish" has one or more arguments. The first is
a list of name-value pairs. The name is the name of a value to
return, the value is its value. Subsequent arguments are an implicit
begin whose value is the value of the establish form. Establish
should only appear in tail-recursive positions.
Receive and establish can be implemented by the following T syntax
definitions.
(define-syntax (receive names produce . body)
`(apply (lambda , names ,@ body)
(bind , (map (lambda (name) `(, name (undefined)))
names)
, produce
(list ,@ names))))
(define-syntax (establish name-value-pairs . body)
`(begin ,@ (map (lambda (pair) `(set! ,@ pair))
name-value-pairs)
(undefined)
,@ body))
I don't think this is a good proposal but there may be a good way to
use the basic idea. It does allow forms to ignore "extra" values and
(this variation) can be implemented simply.
-andy
-------
∂11-Nov-86 0853 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme errors?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86 08:53:00 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 NOV 86 11:53:08 EST
Date: Tue, 11 Nov 86 11:55:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scheme errors?
To: RDZ@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 11 Nov 86 01:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].117255.861111.JAR>
Date: Tue, 11 Nov 86 01:22 EST
From: Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Have I missed something in my reading of the Scheme report, or is there
in fact no defined way for a program to signal an error?
You didn't miss anything. However, no such mechanism is needed, because
as long as you avoid defining the variable "error", it should simply
work to say (error ...). The effect will be a reference to an unbound
variable, and if the debugging system is halfway decent you'll be able
to see the arguments.
Seriously though, I think most implementations have an "error" procedure
(or special form) which is compatible with S&ICP (and not with CL). But
it might be nice if we in fact standardized on this. Ideally of course
it would be part of a real error (condition) system, though, and it's
possible that that would in turn depend on having fluid variables... I
wouldn't hold my breath...
Jonathan
∂13-Nov-86 0752 @MC.LCS.MIT.EDU:sieber-john@YALE.ARPA Add me to the list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 86 07:52:10 PST
Received: from yale-celray.YALE.ARPA (TCP 20011000031) by MC.LCS.MIT.EDU 13 Nov 86 10:48:14 EST
Received: by yale-celray.YALE.ARPA; Thu, 13 Nov 86 10:04:58 est
Date: Thu, 13 Nov 86 10:04:58 est
From: sieber-john@YALE.ARPA
Message-Id: <8611131504.AA00353@yale-celray.YALE.ARPA>
Subject: Add me to the list
To: scheme@mc.lcs.mit.edu
Would you please add me to the Scheme discussion? I was an undergraduate
at Oberlin College where I was infected with the Scheme bug (flavored
heavily by Indiana U. and the Dan Friedman school).
Thanks,
Jack Sieber
sieber@yale.arpa
-------
-------
∂15-Nov-86 1839 @MC.LCS.MIT.EDU:reddy@a.cs.uiuc.edu make-environment
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86 18:39:12 PST
Received: from a.cs.uiuc.edu (TCP 1200600045) by MC.LCS.MIT.EDU 15 Nov 86 21:33:07 EST
Received: by a.cs.uiuc.edu (UIUC-5.44/9.7),
id AA10732; Sat, 15 Nov 86 20:33:52 CST
Date: Sat, 15 Nov 86 20:33:52 CST
From: reddy@a.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8611160233.AA10732@a.cs.uiuc.edu>
To: scheme@mit-mc.arpa
Subject: make-environment
I don't know if this is the right forum to raise this issue. But, I wonder
why make-environment works the way it does. If I define
(define (complex x y)
(make-environment
(define re x)
(define im y)))
(define a (complex 1 2))
not only does a have re and im bound in it, but it also has x and y
bound in it. So,
(access x a)
yields 1. From the description of make-environment in Abelson and Sussman,
it appears that only re and im should be bound in a. Is this a bug, or a
feature, or am I missing something? If this is the way make-environment
is supposed to work, is there some other primitive that binds re and im
and forgets about x and y?
Uday Reddy
∂15-Nov-86 1913 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET question: S&ICP teacher's manual and query language
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86 19:13:14 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Nov 86 22:04:10 EST
Received: from ubc by csnet-relay.csnet id aa00818; 15 Nov 86 14:27 EST
Date: Sat, 15 Nov 86 10:36:41 pst
Received: by ubc.csnet id AA24378; Sat, 15 Nov 86 10:36:41 pst
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <153:shneider@cui.unige.chunet>
Subject: question: S&ICP teacher's manual and query language
1) We set up group here, disscussing the "structure and interpretation" book
and we'd like to use it for teaching eventually.
Where could I get the teacher's manual ?
(Sorry, if this question has been asked before already)
2) I'd also like to obtain the updated version of the query langauge.
I heard that I might get it from GJS, but I don't know his name
and net address. Anybody does ?
BIG thanks for any help !
∂15-Nov-86 1951 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET question: S&ICP teacher's manual and query language
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86 19:45:29 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Nov 86 22:04:55 EST
Received: from ubc by csnet-relay.csnet id ab00818; 15 Nov 86 14:29 EST
Date: Sat, 15 Nov 86 10:37:10 pst
Received: by ubc.csnet id AA24381; Sat, 15 Nov 86 10:37:10 pst
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <156:shneider@cui.unige.chunet>
Subject: question: S&ICP teacher's manual and query language
1) We set up group here, disscussing the "structure and interpretation" book
and we'd like to use it for teaching eventually.
Where could I get the teacher's manual ?
(Sorry, if this question has been asked before already)
2) I'd also like to obtain the updated version of the query langauge.
I heard that I might get it from GJS, but I don't know his name
and net address. Anybody does ?
BIG thanks for any help !
-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) (22) 20 93 33 ext. 2357
to VMS/BITNET: to UNIX/EAN (preferable):
BITNET: SCHNEIDER@CGEUGE51 shneider%cui.unige.chunet@CERNVAX
ARPA: SCHNEIDER%CGEUGE51.BITNET@WISCVM shneider%cui.unige.chunet@ubc.CSNET
uucp: mcvax!cernvax!cui!shneider
X.400/ean: shneider@cui.unige.chunet
∂16-Nov-86 1021 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU make-environment (long)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 86 10:21:21 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 16 Nov 86 13:16:43 EST
Received: by GENEVA.AI.MIT.EDU; Sun, 16 Nov 86 13:13:36 est
Date: Sun, 16 Nov 86 13:13:36 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8611161813.AA03965@geneva>
To: reddy@a.cs.uiuc.edu
Cc: scheme@mit-mc.arpa
In-Reply-To: Uday S. Reddy's message of Sat, 15 Nov 86 20:33:52 CST
Subject: make-environment (long)
I don't know if this is the right forum to raise this issue. But, I wonder
why make-environment works the way it does. If I define
(define (complex x y)
(make-environment
(define re x)
(define im y)))
(define a (complex 1 2))
not only does a have re and im bound in it, but it also has x and y
bound in it. So,
(access x a)
yields 1. From the description of make-environment in Abelson and Sussman,
it appears that only re and im should be bound in a. Is this a bug, or a
feature, or am I missing something? If this is the way make-environment
is supposed to work, is there some other primitive that binds re and im
and forgets about x and y?
You have misunderstood section 4.3.1 of S&ICP. If you read it
carefully, you will notice
"For use in conjunction with EVAL, Scheme provides an operation called
MAKE-ENVIRONMENT that constructs an environment, evaluates a
designated sequence of expressions within this environment, and
returns the environment as the value of the MAKE-ENVIRONMENT
expression. The enclosing environment of the new environment is the
environment in which the MAKE-ENVIRONMENT expression was evaluated."
The last sentence in the above quote makes it quite clear that this
environment is built on top of the one in which the MAKE-ENVIRONMENT
expression was evaluated, and therefore all these names are visible to
EVAL.
You ask about ACCESS, which is not in S&ICP, so I assume you are
talking about MIT Scheme instead of the restricted subset used in
S&ICP.
There are two possibilities for ACCESS:
Make it compatible with EVAL, and therefore make all the names (like X
and Y in your example) visible. This is the current implementation.
Make ACCESS look only at the "topmost" frame of the environment. This
means that all the names that can be exported from a package must be
defined in that package itself, and there is no "export" inheritance
between packages built on top of packages.
We tried the latter approach for a while and it was a total mess. We
quickly changed it to its alternative.
∂18-Nov-86 0915 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme reports information request
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 09:15:37 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86 12:12:03 EST
Date: Tue, 18 Nov 86 12:14:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scheme reports information request
To: prlb2!vauclair@SEISMO.CSS.GOV
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 18 Nov 86 10:50:34 N (Tue) from Marc Vauclair <prlb2!vauclair at seismo.CSS.GOV>
Message-ID: <[AI.AI.MIT.EDU].119770.861118.JAR>
Date: 18 Nov 86 10:50:34 N (Tue)
From: Marc Vauclair <prlb2!vauclair at seismo.CSS.GOV>
In the "Revised Revised Report on Scheme", I found the following
two little sentences:
on page 5:
"Formal definitions of the lexical and context-free syntaxes of Scheme
will be included in a separate report."
on page 7:
"A formal definition of the semantics of Scheme will be included in a
separate report."
Does those reports exist? Maybe using the same procedure as for the
Revised↑3 Report ?
The "separate report" alluded to actually IS section 7 of the Revised↑3
Report. So the answers are yes and yes, identically.
Jonathan
∂22-Nov-86 1845 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU truncate
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 18:45:14 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 NOV 86 21:43:38 EST
Date: Sat, 22 Nov 86 21:43:12 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: truncate
To: philbin-jim@YALE.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <122229.861122.JAR@AI.AI.MIT.EDU>
Date: 22 Nov 86 11:23:34 EST (Sat)
From: James F Philbin <philbin-jim at YALE.ARPA>
To: Rees at YALE.ARPA
Re: truncate
The definition of TRUNCATE in R3RS, p 20., seems ambiguous.
TRUNCATE returns the integer of maximal absolute
value not larger than the absolute value of x.
In the case of -1.1, for example, both 1 and -1 are of maximal
absolute value not larger than the absolute value of -1.1.
I suggest adding the phrase,
... with the same sign as x.
Right.
∂25-Nov-86 1315 @MC.LCS.MIT.EDU:camp%home%ti-csl.csnet@RELAY.CS.NET PC Scheme Utilities
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:12:00 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Nov 86 16:04:51 EST
Received: from ti-csl by csnet-relay.csnet id ae04601; 25 Nov 86 15:43 EST
Received: from (home.ARPA) by tilde id AA24272; Tue, 25 Nov 86 14:05:13 cst
Received: by id AA13329; Tue, 25 Nov 86 14:04:35 cst
Date: Tue, 25 Nov 86 14:04:35 cst
From: Clyde Camp <camp%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8611252004.AA13329@>
To: SCHEME@MC.LCS.MIT.EDU
Subject: PC Scheme Utilities
For those of you interested in PCS, a set of free utilities with
documentation is available from:
Clyde R. Camp
Texas Instruments, Inc.
P.O.Box 226015, MS 238
Dallas, TX 75266
Send two blank, FORMATTED disks and a self-addressed, stamped envelope.
Although written primarily for the TIPC, everything except the
graphics should work on and of the IBM clones. The directories are:
UTILITY - Various text windowing, file printing and keyboard handlers
which simplify writing application programs (includes a file
pretty-printer and a new top-level read-eval-print loop which uses an
emacs-like line-editor with the capability to scroll back through
previous entries)
SWI - A convenient mechanism for invoking 8086 ASSY routines via the
rather undocumented SWI-INT.
HELP - A user-extendable on-line help facility which includes all of
the PCS functions and syntax as well as other info
GRAF - A object-style graphics package
PLOT - A general prupose function plotter
GAME1 - Self explanatory - non-graphics
GAME2 - for TIPC graphics
ERR←STAT - more utilities for messing with the status window
MENUSHEL - two menu driven command shells
This should also be available in ARC'd format on COMPUSERVE in the
near future.
- Clyde
∂03-Dec-86 1055 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme redistribution for BITNET
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 86 10:55:01 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Dec 86 13:12:32 EST
Date: Wed, 3 Dec 86 13:12:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scheme redistribution for BITNET
To: scheme@MC.LCS.MIT.EDU
Message-ID: <125886.861203.JAR@AI.AI.MIT.EDU>
I'm looking for someone on BITNET to volunteer to maintain a BITNET
redistribution list for the Scheme@MC mailing list. This is necessary
because the machine that's acting as the Internet/BITNET gateway,
WISCVM.WISC.EDU, is swamped with mailing list mail. List administrators
(like me) are being asked to set up redistribution lists to help lighten
the load. If we can set one up for Scheme then WISCVM will only have to
relay each message to one host instead of the current 11 or 12 (more in
future).
If you're willing and able to take this on, please let me know.
Thanks...
- Jonathan
∂08-Dec-86 0049 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Ambiguity in number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86 00:49:07 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Dec 86 03:49:17 EST
Date: Mon, 8 Dec 86 03:47:50 EST
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: Ambiguity in number syntax
To: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU
cc: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-ID: <127818.861208.CPH@AI.AI.MIT.EDU>
I was trying to implement a parser for the full number syntax in R3RS
and noticed that
#x1234e57
is ambiguous. Does it mean
(* #x1234 (expt 10 57))
or
19091031
Some solutions:
1. Flush scientific notation for hexadecimal numbers. Does anybody
really want to write real numbers (as opposed to integers or
rationals) in hexadecimal?
2. Require an explicit sign character in the exponent for such
numbers. Thus we would say
#x1234e+57
which is unambiguous.
I favor solution (2) since it leaves the syntax as general as
possible.
∂08-Dec-86 0835 @MC.LCS.MIT.EDU:muller@BU-CS.BU.EDU IBM PC Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86 08:35:11 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Dec 86 11:30:53 EST
Received: from bu-cs.bu.edu by RELAY.CS.NET id aa00472; 8 Dec 86 11:03 EST
Return-Path: <muller>
Received: by bu-cs.bu.edu (5.31/4.7)
id AA14034; Sun, 7 Dec 86 08:41:05 EST
Date: Sun, 7 Dec 86 08:41:05 EST
From: Robert Muller <muller@BU-CS.BU.EDU>
Message-Id: <8612071341.AA14034@bu-cs.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: IBM PC Scheme
Does anyone know where I can pickup a version of Scheme that runs
on the IBM PC (XT w only 256k)?
thanks,
- Bob Muller
∂08-Dec-86 0934 @MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU IBM PC Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:34:10 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 DEC 86 12:06:32 EST
Date: Mon, 8 Dec 1986 12:06 EST
Message-ID: <HAL.12261186063.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: Robert Muller <muller@BU-CS.BU.EDU>
Cc: scheme@MC.LCS.MIT.EDU
Subject: IBM PC Scheme
In-reply-to: Msg of 7 Dec 1986 08:41-EST from Robert Muller <muller at BU-CS.BU.EDU>
Texas instrument's PC scheme runs (barely) in 256K, but you can't
use the editor.
∂08-Dec-86 1016 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Ambiguity in number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86 10:16:39 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 8 Dec 86 13:03:21 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 8 Dec 86 12:51:20 est
Date: Mon, 8 Dec 86 12:51:20 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8612081751.AA02460@geneva>
To: CPH@AI.AI.MIT.EDU
Cc: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU
In-Reply-To: Chris Hanson's message of Mon, 8 Dec 86 03:47:50 EST
Subject: Ambiguity in number syntax
There is yet another possibility, which is the one I like best:
#x1234e57
means
(* #x1234 (expt #x10 #x57))
∂09-Dec-86 0812 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define foo)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 86 08:12:11 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 86 11:11:32 EST
Date: Tue, 9 Dec 86 11:10:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (define foo)
To: andy@ADS.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 7 Dec 86 22:56:01 PST from andy at hobbes.ads.ARPA (Andy Cromarty)
Message-ID: <128392.861209.JAR@AI.AI.MIT.EDU>
Date: Sun, 7 Dec 86 22:56:01 PST
From: andy at hobbes.ads.ARPA (Andy Cromarty)
A lot of MIT code (among other software) seems to contain the cliche'
(define foo) ; Create an unbound instance of FOO
(let ((some-lexical-var 'x)) ; Create a closure....
(set! foo (lambda () ; Define outer FOO to reference
: ; vars visible only in this lexenv.
:
)))
This does not seem to be permitted, even optionally, by the existing R3RS,
as far as I've noticed. Did I miss something, or is it intentional that
(DEFINE FOO) is not permitted, or was it an oversight? I don't recall
having seen discussion of this topic.
If you missed something then I did too. I have no recollection of this
being discussed.
In trying to write portable Scheme code (it's difficult) I find myself
saying things like (define foo 'undefined) pretty often. I don't find
this to be a major inconvenience, but it is an inconvenience. I don't
see any serious problem with the (define foo) construct. It would
presumably mean the same thing as (define foo <undefined>) where
<undefined> is that mysterious expression described in the discussion of
LETREC in section 7.3. A correct immplementation of <undefined> would
of course be 'undefined (or just about anything else), the only
disadvantage of which is that it allow certain error situations to go
undetected.
For symmetry you'd want the syntax to be allowed for both internal
define's and top-level define's. For this to work you'd have to apply the
(define foo) => (define foo <undefined>) rewrite before applying the
define => letrec rewrite.
This feature is implicitly permitted "optionally", because it is a
compatible extension.
Jonathan
∂17-Dec-86 0712 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET What is comma-dot?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 07:12:43 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Dec 86 10:11:42 EST
Received: from ti-csl by csnet-relay.csnet id ah05539; 17 Dec 86 9:36 EST
Received: from (home.ARPA) by tilde id AA06413; Tue, 16 Dec 86 13:40:14 cst
Received: by id AA01741; Tue, 16 Dec 86 13:39:29 cst
Date: Tue, 16 Dec 86 13:39:29 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8612161939.AA01741@>
To: RRRS-Authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: What is comma-dot?
Can those of us that permit the destructive splicing operation `,.'
inside quasiquote agree on the symbol it corresponds to? That is, if
,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
Perhaps a future R↑nRS should mention this as an extension.
∂31-Dec-86 1100 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86 11:00:00 PST
Received: from WISCVM.WISC.EDU (TCP 20032201015) by MC.LCS.MIT.EDU 31 Dec 86 13:37:15 EST
Received: from (NETWORK)FRSAC11.BITNET by WISCVM.WISC.EDU on 12/30/86
at 14:48:44 CST
Date: Tue, 30 Dec 86 19:30:47 ZONE
To: SCHEME@MC.LCS.MIT.EDU
From: NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU
Subject: SCOOPS
NETWORK at FRSAC11
To: SCHEME at MC.LCS.M
I just got PC-SCOOPS, (by FTP, courtesy of TI), but I do not run PC-Scheme
but CScheme.... Anybody can help ? (In CScheme there is the rrrs compatibility
package... never tried it, but should be good.)
Sincerly,
+--------------------------------------------------+
| Jean-Pierre H. Dumas |
| Cisi-Telematique |
| CEN Saclay, BP 24 |
| 91190 Gif sur Yvette |
| France |
| |
| Phone: +33 (1) 69 08 46 87 |
| |
| network@frsac11 (bitnet) |
| network%frsac11.bitnet@wiscvm.wisc.edu (arpanet) |
| ..!ihnp4!frsac11.bitnet!network (usenet ?) |
| dumas@sumex-aim.stanford.edu (arpanet) |
+--------------------------------------------------+
∂31-Dec-86 1319 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU What is comma-dot?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86 13:19:46 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:23 EST
Date: Wed, 31 Dec 86 16:01:03 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: What is comma-dot?
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 16 Dec 86 13:39:29 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <135327.861231.JAR@AI.AI.MIT.EDU>
Date: Tue, 16 Dec 86 13:39:29 cst
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
To: RRRS-Authors at MC.LCS.MIT.EDU
cc: Bartley%home%ti-csl.csnet at RELAY.CS.NET
Re: What is comma-dot?
Message-Id: <8612161939.AA01741@>
Can those of us that permit the destructive splicing operation `,.'
inside quasiquote agree on the symbol it corresponds to? That is, if
,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
Perhaps a future R↑nRS should mention this as an extension.
I think this feature is a kludge; I presume you have Common Lisp in
mind. How about "UNQUOTE-SPLICING!" ?
Jonathan
∂31-Dec-86 1333 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [COMSAT: Msg of Monday, 22 December 1986 16:31-EST]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86 13:33:28 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:42 EST
Date: Wed, 31 Dec 86 16:01:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [COMSAT: Msg of Monday, 22 December 1986 16:31-EST]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <135329.861231.JAR@AI.AI.MIT.EDU>
Date: Thu, 25 Dec 86 21:08:55 EST
From: Communications Satellite <COMSAT at AI.AI.MIT.EDU>
To: JAR at AI.AI.MIT.EDU
Re: Msg of Monday, 22 December 1986 16:31-EST
Message-ID: <134306.861225@AI.AI.MIT.EDU>
FAILED: rrrs-authors at MC.LCS.MIT.EDU; Host appears to be permanently down or not accepting mail.
Failed message follows:
-------
Date: Mon, 22 Dec 86 16:31:02 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: New, improved quasiquote
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 17 Dec 86 16:40:28 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <133673.861222.JAR@AI.AI.MIT.EDU>
Date: Wed, 17 Dec 86 16:40:28 cst
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
You mailed out a copy of your expand-quasiquote procedure at my
request 13 months ago. Do you have an updated version you could be
persuaded to make public? We never switched over to your algorithm,
but the recent changes to the specification mean we have to rewrite
our quasiquote handler anyway, so it would be nice to continue our
grand tradition of "borrowing" from university sources!
I have several versions. Here is one from which I have removed several
different optimizations. I did this in an attempt to make the code as
simple as possible, without sacrificing too much efficiency. Simpler
versions are possible, as are more optimal ones. E.g. this one won't
generate (vector ...) or (list ...), but it does do maximal sharing of
constant substructure.
You can do (define (system x) x) to get this to work, although in the
Scheme implementation from which this was taken I actually make this
return a funny expression which is an absolute reference to x, so that
things like (let ((cons +)) `(,a b)) works.
- Jonathan
;;; Quasiquote
(define-rewriter 'quasiquote
(lambda (x)
(expand-quasiquote x 0)))
(define (expand-quasiquote x level)
(descend-quasiquote x level finalize-quasiquote))
(define (finalize-quasiquote mode arg)
(cond ((eq? mode 'quote) `',arg)
((eq? mode 'unquote) arg)
((eq? mode 'unquote-splicing)
(error ",@ in illegal context" arg))
(else `(,mode ,@arg))))
(define (descend-quasiquote x level return)
(cond ((vector? x)
(descend-quasiquote-vector x level return))
((not (pair? x))
(return 'quote x))
((interesting-to-quasiquote? x 'quasiquote)
(descend-quasiquote-pair x (1+ level) return))
((interesting-to-quasiquote? x 'unquote)
(cond ((= level 0)
(return 'unquote (cadr x)))
(else
(descend-quasiquote-pair x (- level 1) return))))
((interesting-to-quasiquote? x 'unquote-splicing)
(cond ((= level 0)
(return 'unquote-splicing (cadr x)))
(else
(descend-quasiquote-pair x (- level 1) return))))
(else
(descend-quasiquote-pair x level return))))
(define (descend-quasiquote-pair x level return)
(descend-quasiquote (car x) level
(lambda (car-mode car-arg)
(descend-quasiquote (cdr x) level
(lambda (cdr-mode cdr-arg)
(cond ((and (eq? car-mode 'quote) (eq? cdr-mode 'quote))
(return 'quote x))
((eq? car-mode 'unquote-splicing)
;; (,@mumble ...)
(cond ((and (eq? cdr-mode 'quote) (null? cdr-arg))
(return 'unquote
car-arg))
(else
(return (system 'append)
(list car-arg (finalize-quasiquote cdr-mode cdr-arg))))))
(else
(return (system 'cons)
(list (finalize-quasiquote car-mode car-arg)
(finalize-quasiquote cdr-mode cdr-arg))))))))))
(define (descend-quasiquote-vector x level return)
(descend-quasiquote (vector->list x) level
(lambda (mode arg)
(case mode
((quote) (return 'quote x))
(else (return (system 'list->vector)
(list (finalize-quasiquote mode arg))))))))
(define (interesting-to-quasiquote? x marker)
(and (pair? x) (eq? (car x) marker)))
∂05-Jan-87 0803 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU SYMBOLIC COMPUTATION.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 08:03:49 PST
Received: from WISCVM.WISC.EDU (TCP 20032201015) by MC.LCS.MIT.EDU 5 Jan 87 10:57:12 EST
Received: from (NETWORK)FRSAC11.BITNET by WISCVM.WISC.EDU on 01/05/87
at 09:57:19 CST
Date: Wed, 31 Dec 86 16:27:48 ZONE
To: SCHEME@MC.LCS.MIT.EDU
From: NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU
Subject: SYMBOLIC COMPUTATION.
NETWORK at FRSAC11
To: SCHEME at MC.LCS.M
Does anybody know about a Scheme package to do symbolic computation ??
(a la Reduce, Macsyma...)
P.S. I run CScheme on UTS/V.
Happy new year.
+--------------------------------------------------+
| Jean-Pierre H. Dumas |
| Cisi-Telematique |
| CEN Saclay, BP 24 |
| 91190 Gif sur Yvette |
| France |
| |
| Phone: +33 (1) 69 08 46 87 |
| |
| network@frsac11 (bitnet) |
| network%frsac11.bitnet@wiscvm.wisc.edu (arpanet) |
| ..!ihnp4!frsac11.bitnet!network (usenet ?) ∀
| dumas@sumex-aim.stanford.edu (arpanet) |
+--------------------------------------------------+
∂05-Jan-87 2047 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: What is comma-dot?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 20:46:48 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Jan 87 23:44:13 EST
Received: from tektronix.tek.com by csnet-relay.csnet id aa06713;
5 Jan 87 18:44 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA10436; Mon, 5 Jan 87 12:57:18 PST
Received: by tekchips.TEK (5.31/6.16)
id AA06076; Mon, 5 Jan 87 12:58:16 PST
Message-Id: <8701052058.AA06076@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU, bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: adams%tekchips.tek.com@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: What is comma-dot?
In-Reply-To: Your message of Wed, 31 Dec 86 16:01:03 EST.
<135327.861231.JAR@AI.AI.MIT.EDU>
Date: 05 Jan 87 12:58:13 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET
Just as standardization can be a destructive force, by encouraging the use
of standardized but doubtful features, so can lack of standardization be a
creative force, by discouraging use of non-standardized doubtful features.
I consider comma-dot an excellent candidate for non-standardization.
Will
∂06-Jan-87 0824 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET What is comma-dot?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 08:24:41 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Jan 87 11:21:14 EST
Received: from ti-csl by csnet-relay.csnet id ab01368; 6 Jan 87 10:22 EST
Received: from (home.ARPA) by tilde id AA09833; Tue, 6 Jan 87 08:46:02 cst
Received: by id AA20269; Tue, 6 Jan 87 08:46:09 cst
Date: Tue, 6 Jan 87 08:46:09 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8701061446.AA20269@>
To: RRRS-Authors@MC.LCS.MIT.EDU
Subject: What is comma-dot?
> From: David Bartley <bartley@home>
>
> Can those of us that permit the destructive splicing operation `,.'
> inside quasiquote agree on the symbol it corresponds to? That is, if
> ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
> Perhaps a future R↑nRS should mention this as an extension.
> From: willc@tekchips.tek.com
>
>Just as standardization can be a destructive force, by encouraging the use
>of standardized but doubtful features, so can lack of standardization be a
>creative force, by discouraging use of non-standardized doubtful features.
>I consider comma-dot an excellent candidate for non-standardization.
Will seems to have stated the consensus, if the other replies to my
original message are representative. I will adopt JAR's suggested
name, UNQUOTE-SPLICING!, but agree that this is a "doubtful" feature
and that standardization isn't called for.
∂10-Jan-87 1130 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 2nd test
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jan 87 11:30:03 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jan 87 14:12:22 EST
Date: Sat, 10 Jan 87 14:15:10 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: 2nd test
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <138728.870110.JAR@AI.AI.MIT.EDU>
This is a second test message for today, which everyone should feel at
liberty to ignore.
∂16-Jan-87 0850 @MC.LCS.MIT.EDU:dfried%iuvax.cs.indiana.edu@RELAY.CS.NET multiple values and T
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:50:06 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jan 87 11:45:30 EST
Received: from indiana by csnet-relay.csnet id ac26709; 16 Jan 87 11:32 EST
Date: Fri, 16 Jan 87 09:56:21 est
From: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>
To: rrrs-authors%mit-mc.CSNET@RELAY.CS.NET
Subject: multiple values and T
Here is the material taken from "T Version 3.0 Release Notes" concerning
multiple return values. Following this material will be a short example
which demonstrates how this could be made more general.
Version 3.0 of T supports multiple return values. This makes procedure
call and return uniform, in te sense that a procedure can be invoked with
zero or more values and can return zero or more values.
(return {value}*) ==> {value}* procedure
return returns its arguments as the values(s) of the current expression.
In order to access the value(s) of a return expression the value(s) must be
bound to identifiers using either receive or receive-values.
For example,
((lambda () (return 1 2 3))) ==> 1 2 3
where "==> 1 2 3" denotes evaluates to the three values 1, 2, and 3.
return when invoked with no arguments returns to the calling procedure with
no value. Thus (return) will return to its caller with no value. It is an
error to return no value to a value requiring poisition. For example,
(list 'a (return)) ==> error
The idiom (return) is useful for procedures that return an undefined value and
many of the system procedures whose value(s) is(are) undefined now return no
value. However, the procedure undefined-value may provide a more informative
error message.
(receive-values receiver sender) procedure
==> value(s) of receiver
receive-values returns the value of applying receiver, a procedure of n
arguments, to the values returned by sender. sender is a thunk, a procedure
of no arguments, which returns n values.
For example,
(receive-values (lambda (x y) (list x y))
(lambda () (return 1 2))) ==> (1 2)
(receive ({ident}*) expression {body}*) syntax
==> value of body
In a receive form the expression is evaluated in the current environment
and the values returned by the expression are bound to the corresponding
identifiers. body, which should be a lambda body, i.e. a sequence of one
or more expressions, is evaluated in the extended environment and the
value(s) of the last expression in body is returned.
The expression
(receive (a b c) (return 1 2 3)
(list a b c))
==> (1 2 3)
is equivalent to
(receive-values (lambda (a b c) (list a b c))
(lambda () (return 1 2 3)))
==> (1 2 3)
Other froms have been extended in T3.0 to allow multiple return values.
(catch identifier {body}*) ==> value of body syntax
The identifier is bound to the continuation of the catch form, which is now
an n-ary procedure. This means that catch forms can return multiple values.
The continuation can be invoked only during the dynamic extent of the catch
form. In T2 the continuation was a procedure of one argument. For example,
(catch x (list 1 (x 2 3) 4)) ==> 2 3
(ret {value}*) ==> {value}* procedure
returns zero or more values as the value of the current read-eval-print loop.
Note: Multiple values are implemented efficiently. It may be more efficient
to use multiple values than to pass continuations.
End of disccusion from the Relases Notes.
What disturbs me is the way that it does not seem to be as general as it
could be. What I would like to propose is the ability to splice in return
values. Here is an example:
((lambda (a b c q x y) ...)
(return 1 2 3) 4 (return 5 6)).
It is possible that this capability is exactly what T Version 3.0 does.
However, there were no examples of this type so I believe this has been
overlooked.
I know that when we met in Cambridge Jonathan offered to work on multiple
values. This is something for all of us to consider.
Dan
∂16-Jan-87 1400 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: multiple values and T
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 13:59:53 PST
Received: from yale-eli.YALE.ARPA (TCP 20011000001) by MC.LCS.MIT.EDU 16 Jan 87 16:59:39 EST
Received: by yale-eli.YALE.ARPA; Fri, 16 Jan 87 16:22:37 est
Date: Fri, 16 Jan 87 16:22:37 est
From: Paul Hudak <hudak-paul@YALE.ARPA>
Message-Id: <8701162122.AA06172@yale-eli.YALE.ARPA>
Received: by yale-ring (node-add2.ring.cs.yale.edu/ADD2)
via WIMP-MAIL (Version 1.2/1.4) ; Fri Jan 16 16:19:37
Subject: Re: multiple values and T
To: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>, Fri, 16 Jan 87 09:56:21 est
...
End of disccusion from the Relases Notes.
What disturbs me is the way that it does not seem to be as general as it
could be. What I would like to propose is the ability to splice in return
values. Here is an example:
((lambda (a b c q x y) ...)
(return 1 2 3) 4 (return 5 6)).
It is possible that this capability is exactly what T Version 3.0 does.
However, there were no examples of this type so I believe this has been
overlooked.
No, T does not do this (by design). The problem is that it's not always
obvious what the bindings are. For example, replace the above two
occurrences of RETURN with calls to unknown procedures:
((lambda (a b c q x y) ...)
(f) 4 (g))
The problem with this is that one cannot tell, looking at this code alone,
which bound variable 4 is bound to. Indeed, different invocations of this
may induce different bindings, depending on the bindings of f and g! This
seems to us to violate one's notion of referential transparency.
Paul Hudak
David Kranz
Richard Kelsey
-------
∂16-Jan-87 1645 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 16:45:24 PST
Received: from ZERMATT.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JAN 87 19:45:15 EST
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 24803; Fri 16-Jan-87 19:45:02 EST
Date: Fri, 16 Jan 87 19:45 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <870116194506.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Maybe some of you missed or have forgotten the relevant discussion last
October and November, so here's a digest. If you remember this stuff,
you needn't examine this message any further, and I apologize for
cluttering your mailboxes.
The mechanism in T3 is essentially the same as that presented in my
message of Thu, 30 Oct 86 22:08:03 EST. That message also includes some
motivation, which I won't repeat here, and Dan has already sent out the
technical content. The rather important detail ommitted from the T3
release notes is that it's an error whenever the number of values
expected doesn't match the number delivered, and argument and predicate
positions expect exactly one value. Thus (list (return 1 2)) is an
error in T3 and in my proposal.
The mechanism that Dan Friedman proposes was suggested on this list by
Andy Freeman:
Date: Thu 30 Oct 86 12:25:22-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
This proposal is a variant on the technique Carolyn Talcott used
in her thesis; Richard Weyrauch was also involved in that work.
Their idea requires one procedure; I'll call it values. Procedure
invocation spreads multiple values; (cons (values 1 2)) is completely
equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is
equivalent to (list 4 1 2 3). ...
It was dismissed by the only people on the list (besides maybe Sussman)
who had actual experience using it, namely Steele and Gabriel:
Date: Mon, 3 Nov 86 11:24 EST
From: Guy Steele <gls@Think.COM>
It [MARVEL] did pretty much all the obvious things: every function
call was implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and
most side-effecting forms such as SETQ, PRINT, and COMMENT were made
to return zero values. I believe I also arranged for variables to
be able to hold multiple values.
My experience with the language was that it was perfectly clean
and elegant, but programs that made non-trivial use of multiple
values were very hard to read, precisely because of the loss
of the one-form/one-value correspondence. Having the extra power
everywhere in the language was not worth the loss of clarity.
I therefore abandoned the experiment without writing it up.
(Maybe I should have, but there were other, more promising variations
of Scheme to explore.)
...
I believe that experience with the POP languages (especially POP-2)
may be relevant to this discussion, but I am not an expert there.
Date: 03 Nov 86 1214 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
...
The code, as Steele mentions, was elegant in a certain sense, but
very hard to read most of the time, because you had to take into
account that some other values than the primary value (the first
one) would be passed to some program. The places where SEUS code
was easy to read were when you were writing something that, in
Common Lisp, would be
(multiple-value-call #'foo (baz) (bar))
The places where it was hard to read were when you were writing something
that, in Common Lisp, would be
(foo (baz) (bar))
That is, there was no easy way to check that the right values from the
right places got passed. I think that the latter is the more commonly
used case, so SEUS was optimized the wrong way.
...
When the Common Lisp multiple value scheme was being devised, I thought
that we (the designers) should look at SEUS for its experience. I'm now
glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a
result of that experience.
I tend to agree that it's a bad idea, not only from the point of view of
someone using it, but also for implementation reasons: unlike the T
proposal, which is trivially implementable (VALUES = LIST) in any scheme
implementation, it's grossly incompatible with current implementations;
and it has a performance cost that you have to always pay for, even when
you're not using the feature, because all calls to unknown procedures
must be prepared to splice in an arbitrary amount of crud.
Jonathan
∂16-Jan-87 1656 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 16:56:12 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 87 19:48:29 EST
Date: Fri, 16 Jan 87 19:51:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <141187.870116.JAR@AI.AI.MIT.EDU>
Apologies to those of you who are on both SCHEME and COMMON-LISP.
Date: Friday, 16 Jan 1987 06:42:06-PST
From: vanroggen%bizet.DEC at decwrl.DEC.COM
To: common-lisp at sail.stanford.edu,
vanroggen%bizet.DEC at decwrl.DEC.COM
Re: LISP POINTERS newsletter announcement
Message-Id: <8701161443.AA21565@decwrl.dec.com>
*** ANNOUNCEMENT ***
LISP POINTERS
We're putting together a newsletter and we'd like you to come along.
Every other month, starting in March of 1987, Lisp Pointers will
be bringing you articles, implementation summaries, opinion columns,
and information on the lastest action on the standardization front.
And we need you -- to contribute to our departments, to read the
results of our efforts, and to suggest ways we can provide more of the
kinds of information you want to see.
Lisp Pointers is being funded by companies who care about the future
of Lisp. The editorial content of the newsletter will not be
influenced by these companies nor will the companies be responsible
for the material contained within Lisp Pointers. Until such time as
we affiliate with a more formal organization, subscriptions to Lisp
Pointers will be free. Please spread the word among your friends,
both real and electronic.
Our newsletter will be available through the mails. To join our
mailing list, send your name and address to:
Mary S. Van Deusen, Editor
IBM Research
PO Box 704
Yorktown Heights, New York 10598
914-789-7845
617-384-2526
MAIDA@IBM.COM
Contributions should be sent directly to the appropriate department:
***LETTERS TO THE EDITOR, NEWS ITEMS***
Mary S. Van Deusen (see above)
***IMPLEMENTATIONS***
Walter van Roggen
DEC
77 Reed Road
HL02-3/E9
Hudson, Massachusetts 01749
617-568-5617
VANROGGEN%BACH.DEC@DECWRL.DEC.COM
***BOOK REVIEWS, BIBLIOGRAPHIES***
Daniel Weinreb
Symbolics, Inc.
11 Cambridge Center
Cambridge, Massachusetts 02142
617-577-7500
DLW@MC.LCS.MIT.EDU
***X3J3 LISP STANDARDIZATION***
Robert F. Mathis
9712 Ceralene Drive
Fairfax, Virginia 22032
703-425-5923
mathis@b.isi.edu
***USERS***
Susan Ennis
Amoco Production Co.
PO Box 3385
Tulsa, Oklahoma 74102
918-660-3588
***TECHNICAL ARTICLES***
Jonl White
Lucid, Inc.
707 Laurel Street
Menlo Park, California 94025
415-329-8400
edsel!bhopal!jonl@navajo.stanford.edu
***ENVIRONMENTS***
John Foderaro
Franz Inc.
1141 Harbor Bay Parkway
Suite 270
Alameda, California 94501
415-769-5656
jkf%franz.uucp@berkeley.edu
***SCHEME***
Will Clinger M/S 50-662
Tektronics Inc.
PO Box 500
Beaverton, Oregon 97077
willc%tekchips@tek.csnet
503-627-4675
***LISP QUESTIONS***
Patrick Dussud
Texas Instruments
12501 Research Boulevard
MS 2201
Austin, Texas 78759
dussud%jenner%ti-csl.csnet@csnet-relay
***INTERNATIONAL ISSUES***
Christian Quiennec
LITP
4 Place Jussieu
F-75252, Paris Cedex 05
FRANCE
tel: +33 (1) 43 36 25 25 x 5251
UUCP: ..!mcvax!inria!queinnec
ARPA: mcvax!inria!queinnec@seismo.css.GOV
∂18-Jan-87 2027 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Scheme time
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87 20:27:48 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jan 87 23:26:54 EST
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA10400; Sun, 18 Jan 87 23:25:14 est
Date: Sun, 18 Jan 87 23:25:14 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Sun, 18 Jan 87 23:25:14 est
Message-Id: <8701190425.AA10400@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Scheme time
I noticed there is no standard time function for scheme.
Let me propose the following:
(days-after-J2000.0) => current time in units of days
as a floating point number. The time origin is noon,
January 1, 2000. This date is called J2000.0 by astronomers,
and represents a good time origin for those who are interested
in computing the position of the sun and other stars. For
example, a formula that gives the approximate location of the
sun in these units is in "The Astronomical Almanac for the Year
1984", US Naval Observatory and Royal Greenwich Observatory,
US Government Printing Office, Washington DC, 1984.
John
∂25-Jan-87 1837 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [vanroggen%bach.DEC: Looking for Lisps...]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jan 87 18:36:48 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Jan 87 21:34:00 EST
Date: Sun, 25 Jan 87 21:32:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [vanroggen%bach.DEC: Looking for Lisps...]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <144637.870125.JAR@AI.AI.MIT.EDU>
Apologies to those of you who have seen this message already.
I have nothing to do with this newsletter; I'm just forwarding this
message because I thought people on the scheme list might be interested.
- Jonathan
Date: Tuesday, 20 Jan 1987 14:48:29-PST
From: vanroggen%bach.DEC at decwrl.DEC.COM
To: common-lisp at sail.stanford.edu,
vanroggen%bach.DEC at decwrl.DEC.COM
Re: Looking for Lisps...
Message-Id: <8701202249.AA09113@decwrl.dec.com>
As part of a feature of the LISP POINTERS newsletter, we'd like to collect
descriptions of all currently available Lisp implementations.
Any kind of Lisp is acceptable; it doesn't have to be Common Lisp or Scheme or
Interlisp or MacLisp. It doesn't have to be a commercially supported product
either; it can be free with no warranties whatsoever.
If you're working on an implementation, and you're willing to describe it
for everyone's benefit, send us at least the following information:
Implementation Name
Implemented to which standard (if any)
Features (if no standard; see the suggested list of issues below)
Additional Features (if implemented according to a standard)
Missing Features (if implemented according to a standard)
Current version/availability/prices
Support (if supported, by whom; sources available?)
Machine(s)
Operating System(s)
Source or Contact
Any other comments
Submitter's name, address, and net-address
Some features you might want to comment on include:
Predefined data types
Name spaces and scopes and extents
Control structures (e.g., special forms, non-local goto's, multiple
values, multiple stacks, tasking, multi-processor support)
Typing and declarations
Garbage collection
I/O functions
Compiler
Object-oriented support
Graphics and windowing support
Programming tools (e.g., graphics packages, editor interaction,
system maintenance)
Interaction with other languages
AI-oriented tools (e.g., pattern matching, rules, database support,
natural language interface)
Any other interesting features
Send this information to:
Walter van Roggen
Net address: VANROGGEN%BACH.DEC@DECWRL.DEC.COM
Mail address: HLO2-3/E9, 77 Reed Rd, Hudson MA, 01749, USA
∂02-Feb-87 1040 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Time Scales
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87 10:37:56 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 2 Feb 87 13:34:57 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA04621; Mon, 2 Feb 87 13:30:28 est
Date: Mon, 2 Feb 87 13:30:28 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 2 Feb 87 13:30:28 est
Message-Id: <8702021830.AA04621@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Time Scales
Astromomers often measure time using the Julian Date and the
Modified Julian Date. The Julian date is the number of days
since the "begining of time" as estimated by some one from the
god squad of the Middle Ages. The day begins at noon GMT, and
today's date at 1PM EST is JD2446829.3. The Julian date is
useful because there is no need to worry about things like
leap years and changes in the calendar when measuring time
differences. Another useful unit of measurement is the
Modified Julian Date. It is the number of years after
0, January 1, noon GMT. The number looks like the year we
are used to. Today's date is J1987.2. Useful conversions:
J2000.0 = 2000 January 1, noon GMT = JD2451545.0.
J2000.0 is the origin of many formulas that give the position of
the sun and the moon, and these formulas often measure time in
units of days. Hence, my suggestion for (days-after-J2000.0).
John
∂03-Feb-87 0433 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA X windows
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Feb 87 04:32:36 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 87 07:33:34 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA10580; Tue, 3 Feb 87 07:30:51 est
Date: Tue, 3 Feb 87 07:30:51 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 3 Feb 87 07:30:51 est
Message-Id: <8702031230.AA10580@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: X windows
I seems that many are standardizing on X windows.
Maybe we should add some X window calls as non-essential
Scheme?
John
∂04-Feb-87 0744 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA Re: X windows
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 07:42:00 PST
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 4 Feb 87 10:41:35 EST
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA12106; Tue, 3 Feb 87 09:16:18 PST
Date: Tue, 3 Feb 87 09:16:18 PST
From: andy@hobbes.ads.ARPA (Andy Cromarty)
Message-Id: <8702031716.AA12106@hobbes.ads.arpa>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: X windows
Cc: ramsdell%faron@mitre-bedford.ARPA
Reply-To: andy@ads.arpa
Standardization on a window system seems premature. Use of
X (or any other system) is a local phenomenon; in different locales
many competing window systems are in use. If we were to support
window system primitives, it seems to make more sense to support
a metastandard like NeWS, which will incorporate X, Postscript, possibly
Andrew, and other windowing and graphical display approaches -- although
this too seems premature at the present.
If we are going to support graphics and other "foreign" capabilities,
I believe our time would be more fruitfully spent in defining a
general mechanism for embedding foreign (non-Scheme) functions
into the Scheme environment. This is far from a cleanly solved
problem in current LISPs, and a good solution would subsume, and
hence obviate the need for, definition of a case-by-case approach
to embedding specific window, graphics, numerical, and other foreign
packages into Scheme.
asc
∂05-Feb-87 0742 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Windows
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 07:42:37 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 5 Feb 87 10:33:30 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by linus.MENET (1.1/4.7)
id AA00820; Thu, 5 Feb 87 07:51:00 EST
Date: Thu, 5 Feb 87 07:51:00 EST
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Thu, 5 Feb 87 07:51:00 EST
Message-Id: <8702051251.AA00820@linus.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Windows
Even though I'm a Sun user, it looks to me that NeWS is
a loser, and X window will be supported by many more
venders. However, on reflection, I strongly agree we
should spend our time on other matters rather than windows.
Speaking of packages (ugh! -- too many Common Lisp connotations)
what do people think of Gelernter, Jagannathan and London's
paper "Environments as First Class Objects" in Jan 1987
ACM Symp. Princ. Prog. Lang?
John
∂20-Feb-87 0746 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [hay%ubc.csnet: no mail]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87 07:46:24 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Feb 87 10:39:48 EST
Date: Fri, 20 Feb 87 10:39:27 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [hay%ubc.csnet: no mail]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <157166.870220.JAR@AI.AI.MIT.EDU>
I don't have an answer to the following. Can anyone help? (This is a
half-facetious question. My conjecture: people who like Scheme for its
minimality like to have their mailing lists be that way too.)
-Jonathan
Date: 19 Feb 87 10:53 -0800
From: Marilyn Hay <hay%ubc.csnet at RELAY.CS.NET>
To: Scheme Co-ordinator <scheme-request at MC.LCS.MIT.EDU>
Re: no mail
I have noticed that there has not been any traffic on this list for
some time. Is there any particular reason or has there just not been
any submissions to the list? Thanks for any indication as to what has
happened. Take care,
Marilyn Hay
University of British Columbia
hay@ean.ubc.cdn
hay@ubc.csnet
hay%ubc.csnet@csnet-relay.arpa
∂24-Feb-87 0834 @MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM help -- set command
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Feb 87 08:34:04 PST
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 24 Feb 87 11:31:44 EST
Received: from Riesling.ms by ArpaGateway.ms ; 24 FEB 87 08:28:57 PST
Sender: "Larry_Brooks.EdServices"@Xerox.COM
Date: 24 Feb 87 08:28:17 PST (Tuesday)
Subject: help -- set command
From: "Larry_Brooks.EdServices"@Xerox.COM
To: scheme@MC.LCS.MIT.EDU
cc: "Larry_Brooks.EdServices"@Xerox.COM
Message-ID: <870224-082857-9076@Xerox>
I recently purchased TI's PCScheme for the IBM PC. I have a question
that I hope someone out there can answer for me. I would like to use a
command that acts like "set" (i.e., evaluates both its arguments) in
Interlisp. More specifically, I would like to do the following:
(SETQ ALIST '(A B C)) {equivalent to set! or define}
(SET (CAR ALIST) 'Z) {equivalent to ????}
(EVAL (CAR ALIST)) {Should return Z}
Neither define or set! evaluate their first arguments. Does anyone know
of a function that will act like set in Interlisp or of an easy way
around this problem? (I can think of awkward ways to get around it for
specific applications, but I am looking for a nice generic fix.)
Sorry if this question seems basic to the people on this DL, but I'm a
beginner in both Lisp (a few months of experience) and Scheme (a week of
experience).
Thanks for any help,
Larry
∂26-Feb-87 0457 @MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM Re: help -- set command
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Feb 87 04:57:12 PST
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 26 Feb 87 07:56:20 EST
Received: from Riesling.ms by ArpaGateway.ms ; 26 FEB 87 04:53:08 PST
Sender: "Larry_Brooks.EdServices"@Xerox.COM
Date: 26 Feb 87 04:43:20 PST (Thursday)
Subject: Re: help -- set command
From: "Larry_Brooks.EdServices"@Xerox.COM
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: "Larry_Brooks.EdServices"@Xerox.COM, scheme@MC.LCS.MIT.EDU
In-Reply-to: "willc%tekchips.tek.com%RELAY.CS.NET":GV:Xerox's message of
25 Feb 87 16:26
Message-ID: <870226-045308-2404@Xerox>
Thanks for the information. It looks like going from Interlisp to
Scheme is not quite as easy as I expected. I think part of my problem
is learning to "think lexically". Your advice is much appreciated. By
the way, TI's PCScheme does support dynamic variables and there are a
couple of environment commands (I still need to learn what they do)
avaliable also.
Take care,
Larry
∂04-Mar-87 0925 @MC.LCS.MIT.EDU:bc@MEDIA-LAB.MEDIA.MIT.EDU OOPSs for Scheme, MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 09:25:28 PST
Received: from MEDIA-LAB.MIT.EDU (TCP 2225200002) by MC.LCS.MIT.EDU 4 Mar 87 12:01:39 EST
Received: by MEDIA-LAB.MIT.EDU (5.54/4.8) id AA28819; Wed, 4 Mar 87 11:19:50 EST
Date: Wed, 4 Mar 87 11:19:50 EST
From: bill coderre <bc@MEDIA-LAB.MEDIA.MIT.EDU>
Message-Id: <8703041619.AA28819@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: OOPSs for Scheme, MacScheme
Two Questions.
ONE:
What are the significant differences between the Revised2 and Revised3
Reports on Scheme?
TWO:
I now have MacSheme, which looks pretty good. Recently I have been
programming in a forthcoming Common Lisp which includes Gary
Drescher's Object Lisp system.
Is there a similar system around that wouldn't be hard to port to
MacScheme? I don't think I'm a good enough hacker to implement one, or
to do a major rewrite kind of port. (I don't need multiple
inheritance, but I do need single inheritance, which isn't very
obvious to me how to do.)
Thank you for the help......................................bc
∂04-Mar-87 1200 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU r↑2 vs. r↑3
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 11:59:49 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Mar 87 14:23:08 EST
Date: Wed, 4 Mar 87 14:23:07 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: r↑2 vs. r↑3
To: bc@MEDIA-LAB.MEDIA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 4 Mar 87 11:19:50 EST from bill coderre <bc at MEDIA-LAB.MEDIA.MIT.EDU>
Message-ID: <163107.870304.JAR@AI.AI.MIT.EDU>
Date: Wed, 4 Mar 87 11:19:50 EST
From: bill coderre <bc at MEDIA-LAB.MEDIA.MIT.EDU>
ONE:
What are the significant differences between the Revised2 and Revised3
Reports on Scheme?
The changes in the language are mostly trivial. I'd say the most
visible changes are (1) the boolean constants are written #T and #F
instead of #!TRUE and #!FALSE and (2) a number of peripheral and/or
redundant features have been removed or simplified.
As for the report itself, the R↑3 report has some additional
description, e.g. formal semantics & syntax, and its organization is
somewhat different in places.
For completeness, I'll list all the changes of which I'm aware, not just
the significant ones. This list appears in the "notes" section of the
r↑3 report. What constitutes a "clarification" as opposed to an
"incompatible change" is subjective; this is my own classification, not
that of the (other) authors.
New features:
- DELAY and FORCE (as in Abelson & Sussman's book)
- New predicates BOOLEAN? and PROCEDURE?
- ATAN now admits either one or two arguments.
- ↑ is now extended alphabetic.
Features removed:
- NAMED-LAMBDA and REC are both gone.
- "Curried define", e.g. (define (((f x) y z) w) ...), has been removed.
- A number of things had more than one name in the R↑2 report; now everything
has only one name. Thus SEQUENCE, <?, <=?, =?, >=?, and > are gone.
- A number of marginal procedures have been flushed, namely:
APPEND!, STRING-NULL?, SUBSTRING-FILL!, SUBSTRING-MOVE-LEFT!
SUBSTRING-MOVE-RIGHT!, OBJECT-HASH, OBJECT-UNHASH, 1+, and -1+.
- The #!NULL syntax for the empty list is gone (use () instead).
Incompatible changes:
- The boolean constants are now written #t and #f instead of #!true and
#!false.
- (define (foo ...) ...) now means (define foo (lambda (...) ...))
instead of (define foo (letrec ((foo (lambda (...) ...))) foo)).
Technical clarifications: [In many of these cases, the r↑2 report was at
variance with what the way various implementations behaved, and it seemed
better to change the report than to change the implementations.]
- The objects returned by literal expressions (e.g. '(a b)) are permitted
to be immutable.
- The list to which a rest-argument becomes bound must be newly allocated.
- DO variables are updated by rebinding rather than by assignment.
- Backquote allows vectors and nesting, and there's an official read/print
syntax for backquoted forms (so you can know what you get if you say
'`(a ,b) ).
- EQ? on equal numbers is unspecified.
- Implementations are permitted to do things like
(EQ? (LAMBDA (X) X) (LAMBDA (Y) Y)) => #T.
- EQV? distinguishes exact numbers from inexact ones, even if they
are equal according to =.
- List, string, and vector indexes must be exact integers.
Someone else will have to answer your question number two.
- Jonathan
∂04-Mar-87 1808 @MC.LCS.MIT.EDU:cpd@CS.UCLA.EDU Re: r↑2 vs. r↑3
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 18:08:06 PST
Received: from hera.CS.UCLA.EDU (TCP 20030201024) by MC.LCS.MIT.EDU 4 Mar 87 21:02:52 EST
Received: by hera.CS.UCLA.EDU (Sendmail 5.54/5.14)
id AA17690; Wed, 4 Mar 87 17:14:39 PST
Date: Wed, 4 Mar 87 17:14:39 PST
From: cpd@CS.UCLA.EDU (Charles Dolan)
Message-Id: <8703050114.AA17690@hera.CS.UCLA.EDU>
To: JAR@ai.ai.mit.edu, bc@media-lab.media.mit.edu
Subject: Re: r↑2 vs. r↑3
Cc: scheme@mc.lcs.mit.edu
Here is a small objected oriented system which I wrote one day
to see how small I could make it. It does single inheritence.
Objects and classes are procedures. New instances are
created by send a class object the message NEW. SUPER
is a smalltalk style pseudo instance which calls the method
dispatcher for the class one higher in the heirarchy. The
DEFINE-METHOD macro walks the code for the message and replaces
varaible references and sets with VECTOR-REFs and VECTOR-SET!s
for a vector of instance variables. This code was written
using a library of utility functions I use. I have attempted
to remove all those references.
Sorry for the lack of comments, this is almost a pedagogical example.
(define *metamethod-offset* 0)
(define *method-offset* 1)
(define *parent-offset* 2)
(define *ivs-offset* 3)
(macro define-class
(lambda (dummy class parent ivs cvs)
(set! ivs (combine-var-lists
(if parent (property parent 'ivs) nil) ivs))
(set! cvs (combine-var-lists
(if parent (property parent 'cvs) nil)
(append '(metamethods methods parent ivs) cvs)))
`(set! ,class
(begin
(set-property! ',class 'ivs ',ivs)
(set-property! ',class 'cvs ',cvs)
(make-class-object ,parent ',ivs ',cvs)))
(define (combine-var-lists l1 l2)
(letrec
((combine
(lambda (l1 l2)
(if (null? l2)
(reverse l1)
(if (memq (car l2) l1)
(combine l1 (cdr l2))
(combine (cons (car l2) l1) (cdr l2)))))))
(combine (reverse l1) l2)))
(macro define-metamethod
(lambd (dummy class spec . body)
(let ((message (car spec))
(arg-spec (cdr spec)))
`(add-metamethod-to-class-object ,class ',message
(lambda (self class %%method-object %%var-vector ,@arg-spec)
,@(walk-code-and-replace-variables
body (property class 'cvs))))))
(define (make-class-object parent ivs cvs)
(let ((cv-vector (make-vector (length cvs)))
(class-object nil))
(vector-set! cv-vector *metamethods-offset* (list 'metamethods))
(vector-set! cv-vector *methods-offset* (list 'methods))
(vector-set! cv-vector *parent-offset* parent)
(vector-set! cv-vector *ivs-offset* ivs)
(set! class-object
(lambda (message . args)
(cond ((eq? message 'cv-vector) cv-vector)
((eq? message 'class-object?) t)
(T (dispatch-metamethod
class-object class-object message args
cv-vector)))))))
(define (add-metamethod-to-class-object class-object message func)
(let* ((a-list (vector-ref (class-object 'cv-vector)
*metamethod-offset*))
(pair (assq message (cdr a-list))))
(if pair
(set-cdr! pair func)
(set-cdr! a-list (cons (cons message func) (cdr a-list))))))
(define (dispatch-metamethod class-object method-object message args
cv-vector)
(let* ((method-vector (if (null? method-object)
(cerror "No metamethod" message args)
(method-object 'cv-vector)))
(pair (assq message (cdr (vector-ref method-vector
*metamethod-offset*)))))
(if pair
(apply (cdr pair)
(cons class-object
(cons ()
(cons method-object
(cons cv-vector args)))))
(dispatch-metamethod class-object
(vector-ref method-vector *parent-offset*)
message args cv-vector))))
(define (walk-code-and-replace-variables expr vars)
(cond ((symbol? expr)
(if (memq expr vars)
`(vector-ref %%var-vector ,(nth-inv vars expr))
expr))
((atom? expr) expr)
((pair? expr)
(cond ((eq? (car expr) 'quote)
expr)
((eq? (car expr) 'set!)
(if (memq (cadr expr) vars)
`(vector-set! %%var-vector
,(nth-inv vars (cadr expr))
,(walk-code-and-replace-variables
(caddr expr) vars))
expr))
(T (cons
(walk-code-and-replace-variables (car expr) vars)
(walk-code-and-replace-variables (cdr expr) vars)))))))
(macro define-method
(lambda (dummy class spec . body)
(let ((message (car spec))
(arg-spec (cdr spec)))
`(add-method-to-class-object ,class ',message
(lambda (self class %%method-object %%var-vector ,@arg-spec)
,@(walk-code-and-replace-variables
body (property class 'ivs))))))
(define (add-method-to-class-object class-object message func)
(let* ((a-list (vector-ref (class-object 'cv-vector) 1))
(pair (assq message (cdr a-list))))
(if pair
(set-cdr! pair func)
(set-cdr! a-list (cons (cons message func) (cdr a-list))))))
(define (make-instance-object class-object)
(let ((iv-vector (make-vector
(length (vector-ref (class-object 'cv-vector)
*iv-offset*))))
(instance-object nil))
(set! instance-object
(lambda (message . args)
(cond ((eq? message 'iv-vector) iv-vector)
((eq? message 'class-object?) nil)
(T (dispatch-method class-object class-object
message args
instance-object iv-vector)))))
instance-object))
(define (dispatch-method class-object method-object message args
instance-object iv-vector)
(let* ((cv-vector (if (null? method-object)
(cerror "No method" message args)
(method-object 'cv-vector)))
(pair (assq message
(cdr (vector-ref cv-vector *methods-offset*)))))
(if pair
(apply (cdr pair)
(cons instance-object
(cons class-object
(cons method-object
(cons iv-vector args)))))
(dispatch-method class-object
(vector-ref cv-vector *parent-offset*)
message args
instance-object iv-vector))))
(macro super
(lambda (dummy message . args)
`(dispatch-super class %%method-object
,message (list ,@args)
self %%var-vector))
(define (dispatch-super class-object method-object message args
instance-object iv-vector)
(let ((parent (vector-ref (method-object 'cv-vector) *parent-offset*)))
(if (null? parent)
(cerror "No super-method or super-metamethod" message args)
(if (null? (instance-object 'class-object?))
(dispatch-method class-object parent message args
instance-object iv-vector)
(dispatch-metamethod instance-object parent message args
iv-vector)))))
; A little documentation
;
; (DEFINE-CLASS class-name parent instance-variables class-variables)
; (DEFINE-METHOD class-name (method-name . args) . body)
; (DEFINE-METAMETHOD class-name (method-name . args) . body)
;
; Here is a small example
;
; (DEFINE-CLASS NEW-CLASS () (NAME) (INSTANCE-COUNT))
;
; (DEFINE-METAMETHOD NEW-CLASS (NEW)
; (LET ((NEW-OBJECT (SUPER 'NEW)))
; (SET! INSTANCE-COUNT (1+ INSTANCE-COUNT))
; OBJECT))
;
; (DEFINE-METAMETHOD NEW-CLASS (GET-INSTANCE-COUNT)
; INSTANCE-COUNT)
;
; (DEFINE-METHOD NEW-CLASS (SET-NAME NEW-NAME)
; (SET! NAME NEW-NAME))
;
; (DEFINE-CLASS ANOTHER-NEW-CLASS (NEW-CLASS () ())
;
; (DEFINE-METHOD ANOTHER-NEW-CLASS (SET-NAME NEW-NAME)
; (SUPER 'SET-NAME NEW-NAME)
; (DISPLAY NEW-NAME)
; (NEWLINE))
Enjoy, comments welcome, flame to yourself.
-Charlie Dolan
∂05-Mar-87 1253 @MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET Re: OOPSs for Scheme, MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Mar 87 12:52:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Mar 87 15:12:38 EST
Received: from relay2.cs.net by RELAY.CS.NET id ai07823; 5 Mar 87 11:26 EST
Received: from waterloo by csnet-relay.csnet id aq01858; 5 Mar 87 11:22 EST
Received: from cantuar.uucp by watmath; Wed, 4 Mar 87 23:42:05 est
Date: Thu, 5 Mar 87 11:21:57+1200
From: "W. Kreutzer" <wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU, bc@MEDIA-LAB.MEDIA.MIT.EDU
Subject: Re: OOPSs for Scheme, MacScheme
If you get an answer to that question I would be interested in it. We have
a locally developed class and flavour package for ChezScheme, if that is
any help. So far I have not got around to port it to MacScheme.
--- wolfgang kreutzer, computer science, University of Canterbury,
New Zealand ---
∂05-Mar-87 1955 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Tiny Object System
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Mar 87 19:55:18 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Mar 87 15:22:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae08210; 5 Mar 87 12:28 EST
Received: from northeastern.edu by RELAY.CS.NET id ah02163; 5 Mar 87 12:23 EST
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Thu, 5 Mar 87 09:51 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA00230; Thu, 5 Mar 87 09:23:39 EST
Date: Thu, 5 Mar 87 09:23:39 EST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: scheme@MC.LCS.MIT.EDU
Subject: Tiny Object System
OK, here is my entry in the "smallest pedagogical OOPS". It is not quite as
refined as I would like, but it's close. Note that flavors and operations
(methods) are first-class citizens, more or less: in particular, messages are
NOT quoted symbols.
-- Mitch Wand (wand@corwin.ccs.northeastern.edu)
;;; A Toy Flavors System in Scheme, based on Generic Functions
;;; or, Object-Oriented Programming without Objects
;;; In this version, we introduce a functional model of operations.
;;; Definitions of data structures:
;;; flavor = ([parent|nil] . instance-names)
; cons-cell is hash code for unique flavor (test equality of flavors
; with eq?)
; instance-names are all required fields, beginning with ancestors and
; concluding with local names)
;;; instance = (flavor . instance-values)
;;; method = (cell operation) ; the cell is probably superfluous.
;;; operation = instance->flavor->operation->fcn
;;; An operation takes 3 arguments: the INSTANCE, the FLAVOR of which
;;; it is supposed to be an instance, and another OPERATION (to be
;;; invoked upon inheritance), and produces a FCN to be applied to the
;;; instance.
;;; fcn = lambda (self af1 ... af_k lf_1 ... lf_n . extra-fields) .
;;; lambda (param_1 ... param_p) . M
;;; The point is that the fcn might be applied to an instance of a
;;; DESCENDENT of this flavor, so it will be a record consisting of
;;; the fields of this flavor (af_1 .. lf_n), plus some additional
;;; fields.
;;; Data Structures
(define make-cell (lambda (v) (cons v nil)))
(define deref-cell car)
(define set-cell! set-car!)
(define fl->parent cadr)
(define fl->instance-names cddr)
(define mk-fl (lambda (parent names) (cons '&flavor (cons parent names))))
(make-unprintable '&flavor '<FLAVOR>)
(define inst->flavor car)
(define inst->values cdr)
(define mk-inst cons)
;;; Functional Core
(define make-flavor
(lambda (parent new-names)
(mk-fl parent (append (fl->instance-names parent) new-names))))
;;; here is the empty method. It tries to invoke inheritance if it
;;; can. The third argument is the method to be used if inheritance
;;; is to be followed. Note the implicit Y operator in the last line.
(define empty-method
(lambda (instance flavor whole-method)
(let ((parent (fl->parent flavor)))
(if (null? parent)
(error "Couldn't apply method" whole-method instance)
(whole-method parent instance whole-method)))))
(define make-method
(lambda ()
(make-cell empty-method)))
;;; here is how we add a new "unit method" to an existing method.
;;; This is just the familiar notion of functional extension EXCEPT
;;; for the whole-method argument. This is passed along as we search
;;; for an applicable method, and is eventually used by empty-method
;;; to invoke inheritance.
(define cons-composite-method
(lambda (new-flavor new-fcn old-method)
(lambda (instance flavor whole-method)
(if (eq? flavor new-flavor)
(apply new-fcn
(cons instance (inst->values instance)))
(old-method flavor instance whole-method)))))
(define add-method!
(lambda (method flavor fcn)
(set-cell! method
(cons-composite-method flavor fcn (deref-cell method)))))
;;; Next we write some user-interfaces
; the null flavor has no parent and no fields
(define null-flavor '(nil))
; define new flavors with define-flavor
(extend-syntax (define-flavor)
[(define-flavor name parent instance-name ...)
(define name (make-flavor (if (null? parent) null-flavor parent)
'(instance-name ...)))])
; make new instances with make-instance. Put parent values first,
; then local values. This could use call-by-keyword, with a SMOP.
(extend-syntax (make-instance)
[(make-instance flavor values ...)
(list flavor values ...)])
; make new methods with define-method
(extend-syntax (define-method)
[(define-method name)
(define name (make-method))])
; add options to methods with add-method
(define expand-add-method
(lambda (exp)
(record-case exp
[add-method (method flavor params body)
(let ([bvl (cons 'self (append (fl->instance-names
(execute (compile flavor)))
'extras))])
`(begin
(add-method! ,method ,flavor
(lambda ,bvl (lambda ,params ,body)))
',method))])))
(macro add-method expand-add-method)
;;; apply-method is the user-level invocation of methods. It
;;; evaluates and dereferences its method and object arguments exactly
;;; once. Notice how real-method is passed as the third argument to
;;; itself in order to initiate the inheritance search loop.
(extend-syntax (apply-method)
[(apply-method method object arg ...)
(let ((real-method (deref-cell method))
(real-object object))
((real-method (inst->flavor real-object) real-object real-method)
arg ...))])
;;; Just for laughs, here is a general setter:
(define-method :set)
(add-method :set null-flavor (name val)
(iterate loop
([names (fl->instance-names (inst->flavor self))]
[vals (inst->values self)])
(cond
[(null? names) (error "cannot set " name)]
[(eqv? (car names) name) (set-car! vals val) val]
[else (loop (cdr names) (cdr vals))])))
(define-method :run-super)
(add-method :run-super null-flavor (method)
(let ((parent (fl->parent (inst->flavor self))))
(if (null? parent)
(error "no super")
(apply-method method (mk-inst parent (inst->values
self))))))
;;; and here is a test file:
(define-flavor terminal () val)
(define-flavor Ident terminal)
(define-flavor Number terminal)
(define-flavor Compound () Operator argument1 argument2)
(define-flavor MulSym ())
(define-flavor AddSym ())
(define-method :eval)
(add-method :eval Number () val)
(add-method :eval Compound ()
(apply-method :operator-result Operator
(apply-method :eval argument1)
(apply-method :eval argument2)))
(define-method :operator-result)
(add-method :operator-result MulSym (v1 v2) (* v1 v2))
(add-method :operator-result AddSym (v1 v2) (+ v1 v2))
(define test1
(lambda ()
(let* ([mulsym (make-instance MulSym)]
[addsym (make-instance AddSym)]
[obj1 (make-instance Compound addsym
(make-instance Number 5)
(make-instance Number 7))])
(writeln (apply-method :eval obj1) " = " 12)
(apply-method :set obj1 'Operator mulsym)
(writeln (apply-method :eval obj1) " = " 35))))
∂07-Mar-87 0351 @MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV distribution list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 03:51:46 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 6 Mar 87 09:32:00 EST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA03842; Thu, 5 Mar 87 22:41:38 EST
Message-Id: <8703060341.AA03842@seismo.CSS.GOV>
Received: from cidam (via goanna) by munnari with SunIII (5.5)
id AA29000; Fri, 6 Mar 87 14:28:07 EST
Received: by cidam.rmit.oz (4.3+RMIT/4.7)
id AA18877; Fri, 6 Mar 87 10:24:09 EST
Date: Fri, 6 Mar 87 10:24:09 EST
From: munnari!cidam.rmit.oz!mg@seismo.CSS.GOV (Mike A. Gigante)
To: SCHEME@mc.lcs.mit.edu
Subject: distribution list
There is now a distribution list here in Australia. For anyone else receiving
the list direct, send your details to scheme-request@cidam.oz (Australia only)
Mike Gigante, munnari!cidam.oz!mg@seismo.css.gov
∂09-Mar-87 0055 @MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET Re: distribution list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87 00:55:03 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Mar 87 03:43:54 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08194; 9 Mar 87 3:39 EST
Received: from waterloo by csnet-relay.csnet id aa08421; 9 Mar 87 3:32 EST
Received: from cantuar.uucp by watmath; Mon, 9 Mar 87 02:27:15 est
Date: Mon, 9 Mar 87 10:25:37+1200
From: "W. Kreutzer" <wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET>
To: SCHEME@MC.LCS.MIT.EDU,
mg <@RELAY.CS.NET,@cidam.rmit.oz,@munnari.csnet:mg@SEISMO.CSS.GOV>
Subject: Re: distribution list
yes, we are on the MIT scheme news list. If there is a cheaper way to get
the stuff from you, we are interested. Thanks
--- w. kreutzer, computer science, university of canterbury
christchurch, new zealand ---
∂10-Mar-87 1930 @MC.LCS.MIT.EDU:jar@ZURICH.AI.MIT.EDU test suite candidate
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 19:30:06 PST
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 10 Mar 87 22:32:51 EST
Received: by ZURICH.AI.MIT.EDU; Tue, 10 Mar 87 22:08:22 est
Date: Tue, 10 Mar 87 22:08:22 est
From: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8703110308.AA07187@zurich>
To: rrrs-authors@mc.lcs.mit.edu
Subject: test suite candidate
Reply-To: JAR@AI.AI.MIT.EDU
Has anyone worked on a test suite? Here's a suggestion for inclusion,
which, fortunately, works in the three implementation in which I tried
it. I leave the significance of this test as an exercise.
- Jonathan
(define (tst)
(define k1 #f)
(define k2 #f)
(define cwcc call-with-current-continuation)
(define step 0)
(define (detect-lossage)
(set! step (+ step 1))
(case step
((1) (cwcc (lambda (k) (set! k1 k) 'a)))
((2) (cwcc (lambda (k) (set! k2 k) 'b)))
((4) 'd)))
(let ((answer (list (detect-lossage) (detect-lossage))))
(set! step (+ step 1))
(case step
((3) (k1 'c)) ;answer = (a b) or (b a)
((5) (k2 'e)) ;answer = (c d) or (d c)
((6)
(cond ((or (equal? answer '(a e))
(equal? answer '(e a)))
'wins)
((or (equal? answer '(c e))
(equal? answer '(e c)))
'loses)
(else (list 'really-loses answer)))))))
∂10-Mar-87 2309 @MC.LCS.MIT.EDU:cth%iucs.cs.indiana.edu@RELAY.CS.NET
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 23:08:34 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Mar 87 18:31:25 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac24159; 10 Mar 87 17:36 EST
Received: from indiana by RELAY.CS.NET id af19280; 10 Mar 87 17:32 EST
Date: Tue, 10 Mar 87 16:01:55 est
From: Chris Haynes <cth%iucs.cs.indiana.edu@RELAY.CS.NET>
To: vanroggen%bach.dec@DECWRL.DEC.COM, scheme@MC.LCS.MIT.EDU
Scheme 84 compiles source to an intermediate s-expression code, which
is then interpreted by a Virtual Scheme Machine (VSM) written in
compiled Franz Lisp. This note outlines the relative merits of
Scheme 84.
ADVANTAGES:
-- COST: It is FREE, available via anonymous ftp on arpanet as
directory pub/scheme84 on iucs.cs.indiana.edu (since we are new
to arpanet, you may have to use 192.12.206.205), or send a tape to
Nancy Garrett
Lindley Hall
Bloomington, IN 47405.
It will be returned with Scheme 84 in Unix tar format, with an
Indiana University Computer Science Department Technical Report
that documents the language. Scheme 84 was developed under
Berkley Unix, but also runs under VMS if you have Franz Lisp.
-- PORTABILITY: It is very easy to port Scheme 84 to any machine
that runs Franz Lisp. Without much difficulty it could also be
ported to run under other Lisp systems, such as Common Lisp or
PSL. Only a small set of Lisp features are used.
-- MALEABILITY: It is easy to modify. Many interesting features can
be added to Scheme 84 with only a few hours (or even minutes) of
work. The entire Scheme 84 implementation can be digested easily
in a few days. We have found this to be of great value in our
research. For example, engines, an abstraction of timed preemption
[Haynes and Friedman 84], was first implemented in Scheme 84.
It is particularly easy to import Franz Lisp features into Scheme.
This has been used, for example, to implement a Semantic
Prototyping System [Wand 84] with hooks to Lex and Yacc.
DISADVANTAGES:
-- SPEED: It is much slower than Scheme implementations
based on native code compilation, such as Chez Scheme or T.
However, the intermediate code and VSM were carefully designed to
get the most out of the Franz compiler so that Scheme 84 is
comparable in speed to other interpreted Scheme implementations.
-- FRANZ FOIBLES: A few unfortunate features of Franz Lisp show through.
For example, some run time errors are caught by Franz, not Scheme,
and result in inappropriate error messages (though Scheme 84 always
recovers control).
-- STANDARDIZATION: Scheme 84 is fairly close to the Scheme standard
[Rees and Clinger 86], but has not been brought completely up to
date. (Any volunteers?)
[Rees and Clinger 86] Rees, J., and Clinger, W., Revised Report on
the Algorithmic Language Scheme, SIGPLAN Notices 21:12, pp. 37-79
(1986).
[Haynes and Friedman 84] Haynes, C.T., and Friedman, D.P., Engines
build process abstractions, Conf. Rec. of the 1984 ACM Symposium
on Lisp and Functional Programming, pp. 18-24.
[Wand 84] Wand, M., A semantic prototyping system, Proc. ACM SIGPLAN '84
Compiler Construction Conference, pp. 213-221.
∂11-Mar-87 2251 @MC.LCS.MIT.EDU:cth@IUCS.CS.INDIANA.EDU Scheme 84
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87 22:51:07 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Mar 87 13:56:25 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa02343; 11 Mar 87 13:34 EST
Received: from indiana by RELAY.CS.NET id ad25226; 11 Mar 87 13:28 EST
Date: Wed, 11 Mar 87 12:30:00 est
From: Chris Haynes <cth@IUCS.CS.INDIANA.EDU>
To: scheme@MC.LCS.MIT.EDU
Subject: Scheme 84
Scheme 84 compiles source to an intermediate s-expression code, which
is then interpreted by a Virtual Scheme Machine (VSM) written in
compiled Franz Lisp. This note outlines the relative merits of
Scheme 84.
ADVANTAGES:
-- COST: It is FREE, available via anonymous ftp on arpanet as
directory pub/scheme84 on iucs.cs.indiana.edu (since we are new
to arpanet, you may have to use 192.12.206.205), or send a tape to
Nancy Garrett
Lindley Hall
Bloomington, IN 47405.
It will be returned with Scheme 84 in Unix tar format, with an
Indiana University Computer Science Department Technical Report
that documents the language. Scheme 84 was developed under
Berkley Unix, but also runs under VMS if you have Franz Lisp.
-- PORTABILITY: It is very easy to port Scheme 84 to any machine
that runs Franz Lisp. Without much difficulty it could also be
ported to run under other Lisp systems, such as Common Lisp or
PSL. Only a small set of Lisp features are used.
-- MALEABILITY: It is easy to modify. Many interesting features can
be added to Scheme 84 with only a few hours (or even minutes) of
work. The entire Scheme 84 implementation can be digested easily
in a few days. We have found this to be of great value in our
research. For example, engines, an abstraction of timed preemption
[Haynes and Friedman 84], was first implemented in Scheme 84.
It is particularly easy to import Franz Lisp features into Scheme.
This has been used, for example, to implement a Semantic
Prototyping System [Wand 84] with hooks to Lex and Yacc.
DISADVANTAGES:
-- SPEED: It is much slower than Scheme implementations
based on native code compilation, such as Chez Scheme or T.
However, the intermediate code and VSM were carefully designed to
get the most out of the Franz compiler so that Scheme 84 is
comparable in speed to other interpreted Scheme implementations.
-- FRANZ FOIBLES: A few unfortunate features of Franz Lisp show through.
For example, some run time errors are caught by Franz, not Scheme,
and result in inappropriate error messages (though Scheme 84 always
recovers control).
-- STANDARDIZATION: Scheme 84 is fairly close to the Scheme standard
[Rees and Clinger 86], but has not been brought completely up to
date. (Any volunteers?)
[Rees and Clinger 86] Rees, J., and Clinger, W., Revised Report on
the Algorithmic Language Scheme, SIGPLAN Notices 21:12, pp. 37-79
(1986).
[Haynes and Friedman 84] Haynes, C.T., and Friedman, D.P., Engines
build process abstractions, Conf. Rec. of the 1984 ACM Symposium
on Lisp and Functional Programming, pp. 18-24.
[Wand 84] Wand, M., A semantic prototyping system, Proc. ACM SIGPLAN '84
Compiler Construction Conference, pp. 213-221.
∂12-Mar-87 0356 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Question: are theres ANY VIDEO TAPES available for Scheme ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87 03:56:36 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Mar 87 06:56:01 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08863; 12 Mar 87 6:52 EST
Received: from switzerland by RELAY.CS.NET id aa00256; 12 Mar 87 6:45 EST
Received: from ean by SWITZERLAND.CSNET id a017020; 12 Mar 87 12:37 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <203:shneider@cui.unige.chunet>
Subject: Question: are theres ANY VIDEO TAPES available for Scheme ?
We heard that there were some video tapes around which teach programming
in Scheme (maybe some MIT "6.001" lessons).
If #T, (1) where could I get them ?
(2) for what price (incl. handling, mail to Switzerland) ?
Thanks for any help !
--
Daniel K.Schneider
ISSCO, University of Geneva, 54 route des Acacias, 1227 Carouge (Switzerland)
Tel. (..41) (22) 20 93 33 ext. 2114
to VMS/BITNET: to UNIX/EAN (preferable):
BITNET: SCHNEIDE@CGEUGE51 shneider%cui.unige.chunet@CERNVAX
ARPA: SCHNEIDE%CGEUGE51.BITNET@WISCVM shneider@cui.unige.CHUNET
or: shneider%cui.unige.chunet@ubc.csnet
uucp: mcvax!cernvax!cui!shneider
∂12-Mar-87 0608 @MC.LCS.MIT.EDU:dyb@IUVAX.CS.INDIANA.EDU Re: test suite candidate
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87 06:08:27 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Mar 87 09:03:01 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa09740; 12 Mar 87 8:57 EST
Received: from indiana by RELAY.CS.NET id ac00825; 12 Mar 87 8:52 EST
Date: Wed, 11 Mar 87 23:58:18 est
From: "R. Kent Dybvig" <dyb@IUVAX.CS.INDIANA.EDU>
To: JAR@MC.LCS.MIT.EDU
Subject: Re: test suite candidate
Cc: rrrs-authors@MC.LCS.MIT.EDU
I believe I was the one who volunteered to work on this at last year's
Lisp conference, and I plan to do so over the summer. I'll save your
program away (it does work in Chez Scheme, incidentally). I also
welcome any other test programs people have written or wish to write.
We have a favorite continuation example here, but it is probably more
challenging to people than to Scheme systems. It is "mondo-bizarro",
whose definition is given below. Work it out on paper before trying
it out.
(define mondo-bizarro
(lambda ()
(let ([k (call/cc (lambda (c) c))])
(write 1)
(call/cc (lambda (c) (k c)))
(write 2)
(call/cc (lambda (c) (k c)))
(write 3))))
Kent
∂16-Mar-87 1056 @MC.LCS.MIT.EDU:DAN@cis.upenn.edu Revised Revised Revised Report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87 10:54:30 PST
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 16 Mar 87 13:49:53 EST
Received: by linc.cis.upenn.edu
id AA04208; Mon, 16 Mar 87 13:44:04 EST
Posted-Date: Mon, 16 Mar 87 13:46 EST
Message-Id: <8703161844.AA04208@linc.cis.upenn.edu>
From: Dan Zigmond <Dan@cis.upenn.edu>
Subject: Revised Revised Revised Report on Scheme
To: scheme@mc.lcs.mit.edu
Date: Mon, 16 Mar 87 13:46 EST
How does one get a copy of this new spec? Is it FTPable from somewhere?
Dan
∂16-Mar-87 1517 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme; administrivia
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87 15:17:23 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 17:51:05 EST
Date: Mon, 16 Mar 87 17:49:49 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Revised↑3 Report on Scheme; administrivia
To: Dan@CIS.UPENN.EDU, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 16 Mar 87 13:46 EST from Dan Zigmond <Dan at cis.upenn.edu>
Message-ID: <169287.870316.JAR@AI.AI.MIT.EDU>
Date: Mon, 16 Mar 87 13:46 EST
From: Dan Zigmond <Dan at cis.upenn.edu>
To: scheme at mc.lcs.mit.edu
Re: Revised Revised Revised Report on Scheme
How does one get a copy of this new spec? Is it FTPable from somewhere?
It's in ACM SIGPLAN Notices, December 1986. You can also get it from
the MIT AI Lab Publications Office, 545 Technology Square, Cambridge MA
02139, for $6.00, prepaid; ask for AI Memo 848a. If you want the
LaTeX sources, you can get them from MIT-PREP:/scheme/r3rs.tar (that's a
Unix "tar" file), but I think you're better off dealing with the
hardcopy, unless you want to modify it.
Attention new arrivals to the list: rather than bother everyone on the
list with requests like this for basic information which has a high
probability of having already been posted, please send your easy
questions to Scheme-Request@MIT-MC. In particular, I can send you a
compendium of implementation announcements, consisting of messages which
have been sent to this list. Don't get upset if a week or two goes by
without an answer from me, since I tend to deal with scheme-request
messages in batches; be patient.
Implementors & others: if you want to add or change things in this
standard information packet I send out, please let me know.
One last thing: I would like for people to get in the habit of sending
mail pertaining to the Scheme mailing list to Scheme-Request, not to me
personally. This is both to make my own record-keeping easier
(messages sent to Scheme-Request are archived) and to be prepared
in case someone else ever takes over management of the list
either temporarily or permanently.
Thanks
Jonathan
∂16-Mar-87 2003 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Request for public domain Scheme programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87 20:03:25 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 22:59:43 EST
Date: Mon, 16 Mar 87 22:59:01 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Request for public domain Scheme programs
To: scheme@MC.LCS.MIT.EDU
Message-ID: <169444.870316.JAR@AI.AI.MIT.EDU>
Date: Mon 16 Mar 87 18:57:21-MST
From: Raul Machuca <RMACHUCA at SIMTEL20.ARPA>
To: scheme-request at MC.LCS.MIT.EDU
Are there any public domain scheme pgrams that can be ftp'd, in
particular for TI PC Scheme?
∂17-Mar-87 0847 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Revised↑3 Report on Scheme; administrivia
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87 08:47:16 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Mar 87 11:39:27 EST
Date: Tue, 17 Mar 87 11:38:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Revised↑3 Report on Scheme; administrivia
To: zs01#@ANDREW.CMU.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 16 Mar 87 23:05:57 est from zs01# at andrew.cmu.edu (Zalman Stern)
Message-ID: <169681.870317.JAR@AI.AI.MIT.EDU>
Date: Mon, 16 Mar 87 23:05:57 est
From: zs01# at andrew.cmu.edu (Zalman Stern)
To: scheme-request at mit-mc
Could you please send me the "standard information packet" as advertised in
the above message.
I omitted to say that people on Internet can FTP this from host MIT-MC.
It's in file "LSPMAI; SCHEME IMPLS". Back message are in "LSPMAI;
SCHEME MAIL" on MIT-MC and even older messages are in "LSPMAI; SCHEME
MAIL1" on MIT-AI.
If you don't have FTP access to the Internet, I'm willing to send the
list of implementations. I won't mail the archives, they're too big.
∂17-Mar-87 1405 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU eqv?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87 14:05:24 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 17 Mar 87 16:19:07 EST
Received: by KLEPH.AI.MIT.EDU; Tue, 17 Mar 87 16:08:11 est
Date: Tue, 17 Mar 87 16:08:11 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8703172108.AA02948@kleph>
To: jar@ai
Cc: rrrs-authors@mc
Subject: eqv?
I believe that the paragraph starting "There is only one empty
list..." on page 13, section 6.2 of R3RS should be modified. In MIT
Scheme, the statement that
(eqv? "" "") ==> #t
is actually false, because there is a user operation,
`set-string-length!', which distinguishes between two empty strings.
I think that the same might be true of #() in an implementation with
`vector-grow!'.
The statement should be modified to indicate that it is true given the
operations described in the report, and may not be true in a given
implementation with extended operations.
∂17-Mar-87 1526 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Re: Question: are theres ANY VIDEO TAPES available for Scheme ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87 15:26:44 PST
Received: from G.BBN.COM (TCP 30000201103) by MC.LCS.MIT.EDU 17 Mar 87 17:10:12 EST
Date: 17 Mar 1987 16:40-EST
Sender: SUSSMAN@G.BBN.COM
Subject: Re: Question: are theres ANY VIDEO TAPES available for Scheme ?
From: SUSSMAN@G.BBN.COM
To: shneider%cui.unige.chunet@RELAY.CS.NET
Cc: scheme@MC.LCS.MIT.EDU
Message-ID: <[G.BBN.COM]17-Mar-87 16:40:17.SUSSMAN>
In-Reply-To: <203:shneider@cui.unige.chunet>
There is a videotaped version of 6.001. You should contact CAES
(The Center for Advanced Engineering Study) about availability and price.
There may be better prices for universities than for industry --
I don't know anything about pricing. I think that Hewlett Packard
is supplying the tapes to U.S. universities, but I don't know about
foreign universities. CAES might know more about this too.
Julie Sussman
∂22-Mar-87 1714 @MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV dump-world problem on 4.2BSD vax (version 4 C-scheme)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Mar 87 17:14:02 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 22 Mar 87 20:14:02 EST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA15239; Sun, 22 Mar 87 20:09:11 EST
Message-Id: <8703230109.AA15239@seismo.CSS.GOV>
Received: from cidam (via goanna) by munnari with SunIII (5.5)
id AA23604; Mon, 23 Mar 87 10:15:26 EST
Received: by cidam.rmit.oz (4.3+RMIT/4.7)
id AA24441; Sun, 22 Mar 87 14:27:04 EST
Date: Sun, 22 Mar 87 14:27:04 EST
From: munnari!cidam.rmit.oz!mg@seismo.CSS.GOV (Mike A. Gigante)
To: scheme@mc.lcs.mit.edu
Subject: dump-world problem on 4.2BSD vax (version 4 C-scheme)
I get the following error when using dump-world. (vax 750, 4.2BSD)
% scheme
Scheme Microcode Version 8.2
MIT Scheme, UNIX version
↑AH (CTRL-A, then H) shows help on interrupt keys.
FASLoading file /usr/mg/lib/scheme/scheme.bin
Scheme saved on Saturday March 21, 1987 at 9:55:37 AM
Release 4.1.1
Microcode 8.2
Runtime 11.4
Features 1.2
Cross 11.1
Unix Interface 1.2
1 ]=> (dump-world "myScheme")
Failure operating on scheme
Anomalous error -- get a wizard 23
There is no environment available;
using the current read-eval-print environment.
The error also occurs when usinmg a full pathname in place of "myScheme".
Any ideas would be appreciated.
Mike Gigante mg%cidam.oz@seismo.css.gov munnari!cidam.oz!mg@seismo.css.gov
Royal Melbourne Institute of Technology, Australia
∂23-Mar-87 0752 @MC.LCS.MIT.EDU:muller@bu-cs.bu.edu Scheme mode in GNU Emacs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 07:51:51 PST
Received: from bu-cs.bu.edu (TCP 30003134401) by MC.LCS.MIT.EDU 23 Mar 87 10:51:43 EST
Received: from bucse.bu.edu by bu-cs.bu.edu (3.2/4.7)
id AA20861; Mon, 23 Mar 87 10:45:26 EST
Return-Path: <muller@bu-cs.bu.edu>
Received: by bucse.bu.edu (5.31/4.7)
id AA03759; Mon, 23 Mar 87 10:47:11 EST
Date: Mon, 23 Mar 87 10:47:11 EST
From: muller@bu-cs.bu.edu
Message-Id: <8703231547.AA03759@bucse.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: Scheme mode in GNU Emacs
Has anyone out there taken the time to rewrite the Scheme support for
GNU Emacs so that it understands R↑3 Scheme syntax? In particular I'd like
to use the Scheme84 "[" and "]" for parentheses and have the indentation
and balancing come out right. Inferior scheme mode also seems to be
intolerant of vt200 series terminals. Has anyone repaired this?
Thanks
bob
∂23-Mar-87 0850 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Scheme mode in GNU Emacs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 08:50:25 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 23 Mar 87 11:49:51 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 23 Mar 87 11:46:14 est
Date: Mon, 23 Mar 87 11:46:14 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703231646.AA09139@geneva>
To: muller@bu-cs.bu.edu
Cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: muller@bu-cs.bu.edu's message of Mon, 23 Mar 87 10:47:11 EST <8703231547.AA03759@bucse.bu.edu>
Subject: Scheme mode in GNU Emacs
Has anyone out there taken the time to rewrite the Scheme support for
GNU Emacs so that it understands R↑3 Scheme syntax? In particular I'd like
to use the Scheme84 "[" and "]" for parentheses and have the indentation
and balancing come out right. Inferior scheme mode also seems to be
intolerant of vt200 series terminals. Has anyone repaired this?
R↑3RS does not define the syntax of [ and ]. That is Scheme84 and
ChezScheme specific (as far as I know). You can probably do that
by copying the syntax table entries from ( and ) to [ and ],
respectively.
The currently released version of the GNU Emacs scheme support matches
MIT CScheme release 4, which is not 100% compatible with R↑3RS. As
soon as we make our 5th release, 100% compatible with R↑3RS (in a
couple of weeks, if all goes well), a new version of the interface
will be released. It will not support [ and ], since that is not a
"feature" of MIT Scheme (some of us think it is a really bad idea).
The released version of inferior Scheme mode does nothing which is
terminal dependent, so there must be a bug in GNU Emacs which is
manifesting itself in this mode. Are you using MIT Scheme as the
inferior scheme?
∂23-Mar-87 2309 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Looking for comments on an introductory article about Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 23:08:57 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Mar 87 02:09:48 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa19225; 24 Mar 87 1:56 EST
Received: from switzerland by RELAY.CS.NET id aa15408; 24 Mar 87 1:52 EST
Received: from ean by SWITZERLAND.CSNET id a013971; 24 Mar 87 7:44 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <211:shneider@cui.unige.chunet>
Subject: Looking for comments on an introductory article about Scheme
I just finished an introductory article about Scheme which is due by the
end of this week (sorry) and which will appear in the SGAICO/SI Newsletter.
SGAICO (Swiss Group for AI and CO) is a special interest group of SI (Swiss
ACM Chapter)
TOPIC: 1. Philosophy and History of Scheme
(lots of quotes from the R↑3 appendix and S&ICP)
2. The language
(inspired by R↑3 and the banking account of S&ICP)
3. List of implementations
4. A review of PC Scheme
I wonder, if any kind soul out there could have a look at it and make
some comments and/or corrections. The article is certainly *not* worth
looking at, but for somebody it might be important that the Swiss get the
good things right. :)
The whole thing is written by an amateur, who does not want to clutter up
this mailing list. If anybody has some spare time, please reply. I can send
you either a Scribe file or a semi-formatted thing. If REPLY does not work,
try one of the addresses below.
Thanks - Daniel
-------------------------------------------------------------------------------
Daniel K.Schneider
ISSCO, University of Geneva, 54 route des Acacias, 1227 Carouge (Switzerland)
Tel. (..41) (22) 20 93 33 ext. 2114
to VMS/BITNET: to UNIX/EAN (preferable):
BITNET: SCHNEIDER@CGEUGE51 shneider%cui.unige.chunet@CERNVAX
ARPA: SCHNEIDER%CGEUGE51.BITNET@WISCVM shneider@cui.unige.CHUNET
or: shneider%cui.unige.chunet@ubc.csnet
uucp: mcvax!cernvax!cui!shneider
∂24-Mar-87 1029 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Scheme mode in GNU Emacs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Mar 87 10:29:06 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Mar 87 12:58:00 EST
Received: from relay2.cs.net by RELAY.CS.NET id af22835; 24 Mar 87 12:37 EST
Received: from northeastern.edu by RELAY.CS.NET id ak18416; 24 Mar 87 12:33 EST
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Tue, 24 Mar 87 11:06 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA13177; Tue, 24 Mar 87 11:00:39 EST
Date: Tue, 24 Mar 87 11:00:39 EST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: muller@BU-CS.BU.EDU
Cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: muller@bu-cs.bu.edu's message of Mon, 23 Mar 87 10:47:11 EST
Subject: Scheme mode in GNU Emacs
Yes, I have a modified version of scheme.el (and shell.el) to do the right
thing with [] and also to run scheme as an inferior process reasonably.
I will mail it if anyone is interested.
Mitch Wand
∂25-Mar-87 0925 @MC.LCS.MIT.EDU:mcvax!crcge1!adams@seismo.CSS.GOV scheme mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 09:25:04 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 25 Mar 87 12:25:21 EST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA05803; Wed, 25 Mar 87 12:20:10 EST
Received: by mcvax.cwi.nl; Wed, 25 Mar 87 18:19:22 +0100 (MET)
Received: by inria.inria.fr; Wed, 25 Mar 87 17:42:51 +0100 (MET)
Received: by crcge1.DIN; Wed, 25 Mar 87 13:25:34 -0100
Date: Wed, 25 Mar 87 13:25:34 -0100
From: mcvax!crcge1!adams@seismo.CSS.GOV (Drew Adams)
Message-Id: <8703251225.AA16715@crcge1.DIN>
To: scheme@mc.lcs.mit.edu
Subject: scheme mailing list
Please place me on your mailing list. Thanks.
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, seismo!mcvax!inria!crcge1!adams
∂26-Mar-87 0235 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Private message to Cynthia Mason. (mail problem)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 02:34:51 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Mar 87 05:35:09 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08512; 26 Mar 87 5:30 EST
Received: from switzerland by RELAY.CS.NET id aa00706; 26 Mar 87 5:23 EST
Received: from ean by SWITZERLAND.CSNET id a020472; 26 Mar 87 11:15 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
Sender: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <222:shneider@cui.unige.chunet>
Subject: Private message to Cynthia Mason. (mail problem)
Sorry, I can't get back to you, something in your adress got chewed up,
(probably by your mailer). I tried Arpa, but it did not work.
I get this: Cynthia Mason 423-9404 <clm@lll-zaphod.a>
Send me your message again with your address included *in* the message text.
preferably one of: ARPA/EDU, uucp, cs-net, BITNET
∂26-Mar-87 0356 @MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET Correction mistake: Looking for comments on an introductory article ..
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 03:55:50 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Mar 87 06:43:59 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08831; 26 Mar 87 6:37 EST
Received: from switzerland by RELAY.CS.NET id aa00959; 26 Mar 87 6:31 EST
Received: from ean by SWITZERLAND.CSNET id a020686; 26 Mar 87 12:20 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <223:shneider@cui.unige.chunet>
Subject: Correction mistake: Looking for comments on an introductory article ..
> I just finished an introductory article about Scheme which is due by the
>end of this week (sorry) and which will appear in the SGAICO/SI Newsletter.
SORRY, I goofed ↑↑↑ , this article (cf. my posting march 24th)
is due in three weeks only.
(for those who wanted to look at it actually, but couldn't this week !)
- d.s.
PS: I am amazed, I already got 5 replies (BIG thanks to the scheme community)
∂27-Mar-87 1850 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 18:49:52 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Mar 87 21:55:00 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac29893; 27 Mar 87 21:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ah11897; 27 Mar 87 21:42 EST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA14104; Fri, 27 Mar 87 15:48:41 PST
Received: by tekchips.TEK.COM (5.31/6.19)
id AA03757; Fri, 27 Mar 87 15:47:10 PST
Message-Id: <8703272347.AA03757@tekchips.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: multiple return values
Date: 27 Mar 87 15:47:06 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Our previous round of discussions on multiple return values reached
no consensus. I want to try again with the very simple, specific
proposal that follows. The proposal consists of additions and changes
to the formal semantics that appears in R3RS, an informal description,
and a rationale.
FORMAL SEMANTICS
[Notation: The "\" character should be read as a Greek lambda,
and the "!" character should be read as a down-arrow.]
Add a procedure RECEIVE-VALUES whose semantics is given by
receive_values: E* --> K --> C
receive_values
= twoarg (\ e1 e2 k . applicate e1 <> (\ e* . applicate e2 e* k))
Add a procedure RETURN-VALUES whose semantics is given by
return_values: E* --> K --> C
return_values = \ e* k . k e*
Either leave the equation of the auxiliary function "single" as is
(equation 1 below), or change it as indicated in equation 2 or as
indicated in equation 3.
single: (E --> C) --> K
1. single = \ f e* . # e* = 1 --> f (e* ! 1), wrong "..."
2. single = \ f e* . # e* >= 1 --> f (e* ! 1), wrong "..."
3. single = \ f e* . # e* >= 1 --> f (e* ! 1), f unspecified
INFORMAL DESCRIPTION
(RECEIVE-VALUES thunk proc) procedure
The first argument is a procedure of no arguments, the second is any
procedure. Calls the first argument, obtaining 0 or more return
values, and then calls the second argument on the value(s) returned
by the first argument. See RETURN-VALUES.
(receive-values (lambda () (return-values 3 7))
(lambda (a b) (* a b))) --> 21
(RETURN-VALUES x ...) procedure
Takes any number of arguments, and returns them as multiple return
values. [See the rationale for a discussion of how many return values
a continuation expects, and the error conditions that may result when
the expectations are not met.] See RECEIVE-VALUES.
(receive-values (lambda () (return-values 'a 'b 'c))
vector) --> #(a b c)
(letrec ((f (lambda (x) (if (zero? x) (g x) (g x))))
(g (lambda (x) (return-values x (- x))))
(h (lambda (x)
(receive-values (lambda () (f x)) list))))
(h 3))
--> (3 -3)
(letrec ((f (lambda (x) (+ (g x) 13)))
(g (lambda (x) (return-values x (- x))))
(h (lambda (x)
(receive-values (lambda () (f x)) list))))
(h 3))
--> error [equation 1]
--> (16) [equation 2 or 3]
(receive-values (lambda () (return-values)) vector) --> #()
(receive-values (lambda () (return-values 1))
(lambda (x . y) y))
--> ()
(receive-values (lambda () (return-values))
(lambda (x . y) y))
--> error
(list (return-values 'a 'b 'c 'd)) --> (a)
(car (list (return-values))) --> error [equation 1 or 2]
--> unspecified [equation 3]
RATIONALE
This proposal is along the lines of multiple return values as in
Common Lisp, but is somewhat simpler and more rational. The simplicity
of the proposal, as compared to the exposition in CLtL, is attributable
to a better choice of primitives and to Scheme's tail-recursive semantics.
RECEIVE-VALUES and RETURN-VALUES correspond to T3's RECEIVE-VALUES
and RETURN. The name "RETURN" was rejected because it would confuse
people who are accustomed to the use of RETURN in Common Lisp and
similar Lisps. Note that these are procedures, not syntax, and that
neither would be essential Scheme.
The arguments to RECEIVE-VALUES are reversed from the way they are in T3.
Feel free to argue the argument order.
Argue also about which equation we should choose for "single". It
determines what happens in the case where RETURN-VALUES returns to a
continuation that was not created by RECEIVE-VALUES. Equation 1 says
that in such a case there must be exactly one return value. Equation 2
says that in such a case there must be at least one value; the extra
values are ignored. Equation 3 allows zero return values, in which case
the value received by the continuation is unspecified. No matter which
equation is chosen, there is no difference between returning a single
value in the usual way and returning a single "multiple value" using
RETURN-VALUES.
I didn't give equations for the extreme positions. The fascist position
would say that it is always an error for RETURN-VALUES to return to a
continuation that was not created by RECEIVE-VALUES. The commonlisp
position would say that when zero values are returned to a continuation
that is expecting one value, then the symbol NIL is passed to the
continuation. If there is sufficient demand, I will post equations for
these.
If we interpret the use of "wrong" in the semantic equations to mean
"is an error" instead of "signals an error", then all of the equations
allow implementations in which Scheme multiple return values are
compatible with the semantics of Common Lisp's multiple return values.
This should make it easier to support a Scheme subset in Common Lisp or
vice versa.
I see no way to implement the proposed procedures in R3RS Scheme, but
most implementations should find it easy to add them.
William Clinger
∂27-Mar-87 1858 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 18:58:21 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Mar 87 21:58:11 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab29893; 27 Mar 87 21:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ag11897; 27 Mar 87 21:42 EST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA12620; Fri, 27 Mar 87 15:14:08 PST
Received: by tekchips.TEK.COM (5.31/6.19)
id AA03301; Fri, 27 Mar 87 15:12:35 PST
Message-Id: <8703272312.AA03301@tekchips.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Let's get together again
Date: 27 Mar 87 15:12:31 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
It's been the better part of a year since many of us got to see each
other at the 1986 Lisp conference, and two and a half years since we
got together at Brandeis. The next X3J13 (Common Lisp) meeting will
be in Boston or Cambridge 30 June and 1 July (a Tuesday and Wednesday),
so David Bartley and I would like to suggest that we meet in Cambridge
to discuss Scheme standardization issues on Thursday, 2 July, possibly
spilling over into Friday morning, 3 July. We need volunteers to
arrange for a room, prepare an agenda, and chair the meeting.
Some issues that Bartley and I would like to see resolved are:
multiple return values
customizable reader
number syntax and exactness
macros
optional arguments
structures and opaque objects
environments
modules
These are in rough order of our priorities, where we give priority to
things that can be standardized easily as well as to things that are
important. We'll be posting some proposals to this mailing list in
hopes of generating some thought, interest, or at least discussion
before we next get together.
Another thing we should talk about is what we want to come after Scheme.
Peace,
Will Clinger
Tektronix, Inc.
∂27-Mar-87 2120 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 21:20:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 00:06:45 EST
Date: Sat, 28 Mar 87 00:03:12 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple return values
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 27 Mar 87 15:47:06 PST (Fri) from willc%tekchips.tek.com at RELAY.CS.NET
Message-ID: <174983.870328.JAR@AI.AI.MIT.EDU>
Date: 27 Mar 87 15:47:06 PST (Fri)
From: willc%tekchips.tek.com at RELAY.CS.NET
single: (E --> C) --> K
1. single = \ f e* . # e* = 1 --> f (e* ! 1), wrong "..."
2. single = \ f e* . # e* >= 1 --> f (e* ! 1), wrong "..."
3. single = \ f e* . # e* >= 1 --> f (e* ! 1), f unspecified
I have already put in my vote for 1.
I see no way to implement the proposed procedures in R3RS Scheme, but
most implementations should find it easy to add them.
If "wrong" doesn't imply "signals an error" then the following is a
correct implementation of alternative 1. This is pretty much how the
feature was implemented in T2.
(define values-marker (list 'values-marker))
(define receive-values
(lambda (thunk proc)
(let ((vals (thunk)))
(if (and (pair? vals) (eq? (car vals) values-marker))
(apply proc (cdr vals))
(proc vals)))))
(define return-values
(lambda vals
(cons values-marker vals)))
I think that the fact that this is so easy is a significant reason to
favor alternative 1.
----
I find the feature to be pretty unuseable unless there is some
syntactically sugared way to use RECEIVE-VALUES (viz. T's RECEIVE
and CL's MULTIPLE-VALUE-BIND), but maybe this issue can be argued
separately.
Jonathan
∂28-Mar-87 1146 @MC.LCS.MIT.EDU:KMP@YUKON.SCRC.Symbolics.COM Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87 11:46:31 PST
Received: from YUKON.SCRC.Symbolics.COM (TCP 30002424403) by MC.LCS.MIT.EDU 28 Mar 87 14:51:46 EST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185960; Sat 28-Mar-87 14:36:06 EST
Date: Sat, 28 Mar 87 14:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Let's get together again
To: willc%tekchips.tek.com@csnet-relay
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: <8703272312.AA03301@tekchips.TEK.COM>
Message-ID: <870328143552.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm all for getting together, but because my (paid) job is Lisp and not
Scheme, I'd be happier if it were over a weekend so I wouldn't have to
take time away from work. Also, many of the X3J13 participants will be
arriving for Monday subcommittee meetings and if they came Saturday,
they could get cheaper fares. Note, too, that Thursday/Friday is 4th
of July weekend and not everyone will necessarily want to spend that time
in Boston -- though certainly I plan to be there so this last point is
not a problem for me, just another possible reason why the weekend before
(27-28 June) might be better for meeting.
∂28-Mar-87 1400 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87 14:00:04 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 28 Mar 87 16:14:05 EST
Received: by GENEVA.AI.MIT.EDU; Sat, 28 Mar 87 16:11:21 est
Date: Sat, 28 Mar 87 16:11:21 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703282111.AA05557@geneva>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: willc%tekchips.tek.com@csnet-relay, RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: Kent M Pitman's message of Sat, 28 Mar 87 14:35 EST <870328143552.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Let's get together again
I agree with KMP. I think the weekend before, if at all possible,
would be better.
I also think that a new meeting would be a good idea.
∂28-Mar-87 2023 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU a modest macro proposal
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87 20:22:59 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 23:28:18 EST
Date: Sat, 28 Mar 87 23:24:42 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: a modest macro proposal
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <175356.870328.JAR@AI.AI.MIT.EDU>
Macros for Scheme
Jonathan Rees
28 March 1987
Primary objectives:
- Macros are scoped, so users won't step on each others' toes.
- The client of a macro need not know anything about the macro's
implementation. In particular, capture problems must be avoidable
both for syntactic keywords and variables.
Secondary objectives:
- Consistent with the "expansion passing style" described
in [1].
- Consistent with the spirit of the macro facilities provided by
MIT Scheme and T.
This is a rough draft, and contains more questions than answers, but I
want to get feedback, and answers to the questions, so here it is.
Overview:
1. Fundamental mechanism
Describes the basic ideas of syntax tables and preprocessed
expressions.
2. Defining macros
Describes two new expression types that introduce scoped macro
definitions.
3. Avoiding free variable capture
Describes ways to circumvent capture problems.
4. Convenience features
Discusses higher-level layers that could make macro writing
easier.
5. Notes and questions
Appendix. An implementation
1. Fundamental mechanism
Two abstractions are introduced, "syntax table" and "preprocessed
expression". A "syntax table" describes a particular mapping from
concrete syntax (expressions) to abstract syntax (preprocessed
expressions). When a user defines a macro, he implicitly defines a
variant on the language and therefore a new mapping from expressions
to preprocessed expressions.
1.1. Reference guide
(For the purposes of this discussion, the term "expression" means
"s-expression", or more precisely:
- Symbols, numbers, booleans, characters, strings, and empty lists
are expressions.
- If E1 and E2 are expressions then the pair (E1 . E2) is an
expression. (In particular, lists of expressions are
expressions.)
- If E0, ... En are expressions, then the vector #(E1 ... En) is
an expression.
- A preprocessed expression is an expression.
- There are no other expressions.)
(PREPROCESS expression syntax-table)
PREPROCESS preprocesses expression according to syntax-table,
and returns a preprocessed expression. The manner in which
the preprocessed expression is determined depends entirely on the
syntax table argument (see the various ways to create syntax tables,
below), with the following exception: (PREPROCESS p syntax-table)
always returns p if p is already a preprocessed expression.
It is an error if expression is not syntactically valid according
to syntax-table.
SCHEME-SYNTAX-TABLE
The value of SCHEME-SYNTAX-TABLE is a syntax table that corresponds
to a language conforming to the Revised↑3 Report. In gory detail,
this means: let E be an expression, and let P be the preprocessed
expression that results from calling
(PREPROCESS E SCHEME-SYNTAX-TABLE).
- If E is a number, boolean, string, or character, then P denotes
an appropriate literal expression.
- If E is a symbol, and E is not a Scheme syntactic keyword (QUOTE,
LAMBDA, etc.), then P denotes a variable reference.
- If E is a pair whose car is a syntactic keyword, then P denotes
an appriopriate expression (unless it contins a syntax error).
- If E is a nonempty list whose car is an expression, then P denotes a
combination (unless some subexpression contains a syntax error).
- If E is already a preprocessed expression, E is equal to P.
- Otherwise E is not syntactically valid.
(ADD-KEYWORD syntax-table symbol expansion-proc)
Expansion-proc must be a procedure of two arguments, an expression
and a syntax table. Expansion-proc must return a preprocessed
expression.
ADD-KEYWORD returns a new syntax table according to which
expressions of the form (symbol ...) are preprocessed by
expansion-proc. That is, PREPROCESS will call expansion-proc and
return what it returns. The arguments passed to expansion-proc will
be the expression and syntax-table that were passed to PREPROCESS.
Any other expression E is preprocessed the same way it would have
been preprocessed according to syntax-table. If this means that it
is to be preprocessed according to SCHEME-SYNTAX-TABLE, then any
subexpressions of the expression will be preprocessed according to
the syntax table that was originally passed to PREPROCESS, not
according to SCHEME-SYNTAX-TABLE.
(REMOVE-KEYWORD syntax-table symbol)
This returns a syntax table in which an expression of the form
(symbol ...) denotes a combination. If symbol had an associated
expansion procedure in syntax-table, that expansion procedure will
be ignored in the new syntax table.
1.2. Discussion
The following may be a helpful analogy:
(EVAL (PREPROCESS
lambda-expression expression
environment) syntax-table)
=> closure => preprocessed-expression
EVAL (or the ENCLOSE of the Revised Report) takes a lambda-expression,
which is context-dependent or "open" because it contains free
variables, and turns it into something that's context-independent or
"closed", namely a closure. PREPROCESS takes an expression, which is
context-dependent because the meanings of subexpressions depend on
what macros are in effect, and returns something that is
context-independent and therefore immune to the vagaries of the macro
context into which it may be placed.
Preprocessed expressions may legitimately appear as subexpressions of
expressions to be passed to PREPROCESS. For example, if M1 and M2 are
preprocessed-expressions, then `(AND ,M1 ,M2) is a valid expression
that can be passed again to PREPROCESS (assuming AND has its usual
meaning). The effect of this is the same as if the expression had
been an AND-expression whose subexpressions were expressions that
would have been preprocessed as M1 and M2 in whatever syntax-table was
the second argument to the call to PREPROCESS.
The nature of "preprocessed-expression" objects is not specified here;
they may or may not be lists, vectors, procedures, etc., or objects of
some new data type. This proposal does not provide any explicit
operations on preprocessed expressions, but it doesn't preclude such
operations, either. Presumably LOAD, EVAL, and compilers know how to
manipulate preprocessed-expressions. Similarly, there may be
operations on syntax tables other than the ones given here; in
particular the clever tricks in [1] could easily work in this
framework.
Note that the syntax table passed to an expansion procedure is not
necessarily the same as the syntax table returned by the call to
ADD-KEYWORD that defined its keyword. The syntax table is the
appropriate one to use in processing subexpressions. The syntax table
argument serves the same purpose as the expansion procedure passed to
expanders in [1].
Detail: definitions, as well as expressions, may be passed to
PREPROCESS.
1.3. Examples
Example 1: The following evaluates to a syntax table that is the
same as that for R↑3R Scheme except that FOO is a syntactic keyword and
(FOO x) means the same as (QUOTE x).
(add-keyword scheme-syntax-table 'foo
(lambda (e st)
(preprocess `(quote ,(cadr e)) scheme-syntax-table)))
This illustrates the general principle that a more complicated
syntax-table can be defined in terms of a simpler one. An expression E
written in a more complicated language L (not even known at macro
definition time) is transformed into a new expression (the expansion),
and then the preprocessed version of the new expression is determined
according to a syntax-table that is known by the expansion procedure to
support the QUOTE keyword in the expected way.
Example 2: The following procedure will augment a given syntax table
with a definition of a simple LET macro.
(define (add-let st)
(add-keyword st 'let
(lambda (exp st)
(let ((bindings (cadr exp))
(body (cddr exp)))
(preprocess `((lambda ,(map car bindings)
,@(map (lambda (exp)
(preprocess exp st))
body))
,@(map (lambda (binding)
(preprocess (cadr binding) st))
bindings))
scheme-syntax-table)))))
The fact that preprocessed-expressions act like normal forms permits the
use of ordinary list constructors (like backquote) in constructing
partially preprocessed expressions.
Note that PREPROCESS is used within expansion procedures for two
distinct purposes:
(a) To compute a preprocessed expression, in the current syntax table,
for each sub-expressions of the expression being expanded.
(b) To preprocess, according to some known syntax table, an expression
that has been determined to be equivalent to the original expression.
Why are syntax tables immutable? This aids (but doesn't guarantee)
consistency between compiled and interpreted code.
2. Defining macros
2.1. LET-SYNTAX
(LET-SYNTAX (((keyword exp-var st-var) . expansion) ...) . body)
LET-SYNTAX is used to define a macro that is local to a single
expression (in practice it is often wrapped around most of a file).
(T and MIT Scheme both have constructs like this.)
For example,
(let-syntax (((foo exp st)
(preprocess `(quote ,(cadr exp)) scheme-syntax-table)))
(foo (a b c)))
=> (a b c)
LET-SYNTAX need not be primitive, assuming there exists an EVAL
procedure and some environment EXPANDER-ENV in which to close
expansion procedures. The following adds a LET-SYNTAX expression
type to any syntax table S:
(add-keyword S 'let-syntax
(lambda (exp st)
(do ((specs (cadr exp) (cdr specs))
(st st
(let ((spec (car specs)))
(add-keyword st (caar spec)
(eval `(lambda ,(cdar spec)
,@(cdr spec))
expander-env)))))
((null? specs)
(preprocess `(begin ,@(map (lambda (exp)
(preprocess exp st))
(cddr exp)))
scheme-syntax-table)))))
In order to reduce the possibility that a macro could accidentally
or intentionally depend on some run-time binding, it is
strongly advised to make the environment in which expanders
are closed be disjoint from the environment in which the expanded
code will be run. Otherwise one could find oneself in the embarrasssing
situation of having code that "works" in an incrementally compiled
implementation but not in a block- or cross-compiled implementation.
2.2. USING-SYNTAX
(USING-SYNTAX syntax-table-exp . body)
USING-SYNTAX lets one make use of some specific macro environment.
(using-syntax scheme-syntax-table (quote yow)) => yow
(add-keyword syntax-table 'using-syntax
(lambda (exp syntax-table)
;; ignore syntax-table
(let ((syntax-table (eval (cadr exp) expander-env)))
(preprocess `(begin ,@(map (lambda (exp)
(preprocess exp syntax-table))
(cddr exp)))
scheme-syntax-table))))
Subtle point:
For these two forms, it might make just as much sense, and perhaps more,
to say
(eval (preprocess foo syntax-table) expander-env)
as
(eval foo expander-env) --
i.e. macros can be written using the macros in effect where the text of
the macro definition occurs, even if they can't make use of the lexical
environment.
3. Avoiding free variable capture
3.1. Free variables introduced into expansions
We want to be able to do things like
(let ((cons +))
`(a ,(cons 1 2) b))
and not lose when QUASIQUOTE expanding into a call to CONS. It
doesn't work to write (as Dan Friedman and others have suggested)
`(',car ,z)
in the definition of QUASIQUOTE because this presents horrible questions
about the meaning of cross-compilation that no one is prepared to
answer right now.
Kohlbecker's solution amounts to performing alpha-conversion and macro
expansion at the same time. This is a lot of mechanism and breaks
down in a few places. Here is a much simpler, low-tech solution.
The solution is for the expander to introduce special expressions into
the expansion that represent "absolute" or "global" references.
Such references are not sensitive to the lexical environment.
(ABSOLUTE node1 node2 ...) [syntax]
Finds a value in an implementation-dependent, tree-structured
namespace. Each node_i should be an identifier; this is to be
considered analogous to a Multics-style pathname >node1>node2>....
In order to make it as easy as possible, Scheme implementors are
urged to cooperate in apportioning sections of this namespace so that
there no conflicts can arise. This is an aministrative problem
analgous to domain naming on the Internet, and perhaps solvable by
similar means.
Only one portion of the namespace is defined here, namely that the
top-level SCHEME-ENV node has as subnodes all the names in the
initial R↑3R Scheme environment. E.g.
(let ((+ -))
((absolute scheme-env +) 1 2)) => 3
(Note that ABSOLUTE must be a new kind of expression -- a procedure
can't so the trick, since that would beg the question of how to name
THAT procedure.)
3.2. Bound variables introduced into the expansion
The flip side of this problem is that macros often want to introduce
new bound variables into expansions, and we don't want these names to
accidentally conflict with names already used in the client's code.
Common Lisp (Maclisp, etc.) programmers don't consider this to be a
problem, since GENSYM and GENTEMP exist. T has GENERATE-SYMBOL (?) and
MIT Scheme has GENERATE-UNINTERNED-SYMBOL. I think something like
this would do the trick. However, I would very much like to
preserve the invariant
(EQ? SYM (STRING->SYMBOL (SYMBOL->STRING SYM))).
which is violated by GENSYM (and GENERATE-UNINTERNED-SYMBOL).
One solution, with a well-defined semantics, would be to have a
procedure that returns a symbol not ocurring in a given expression
(or expressions):
(SYMBOL-NOT-OCCURRING-IN exp) => symbol
This has a nice functional flavor to it, but it could be implemented
nondeterministically, in such a way that only the symbol table need be
examined, not exp itself. (I think T3 does this.)
Another possibility would be to apportion some subset of the set of
all symbols for use as "unique identifiers", e.g. all symbols starting
with some "obscure" prefix, not necessarily even readable (although
read/print symmetry is also a nice feature...).
I don't want to make a concrete proposal at this time.
4. Convenience features
Writing correct macros using ADD-KEYWORD is possible, but cumbersome
and error prone. One must remember to call PREPROCESS on
sub-expressions and on the final output, passing the correct syntax
table to each.
There are several possible ways to address this problem. One is to
say that we should not be in the business of making it easy to write
macros, but instead should do what we can to discourage users from
writing macros, or at least make them recognize the pitfalls. In this
view, the complexity of the process is good.
A second solution is Kohlbecker's "hygienic expansion", which makes it
easy to write correct macros. I suspect this mechanism could be
implemented in terms of the low-level primitives given above, but I
think it has some drawbacks; there are many useful kinds of macros that
can't be written.
I am working on a third solution that, loosely speaking, makes use of
a syntactic description (BNF-like) of the expression type in order to
preprocess subexpressions before handing them to the expansion procedure.
The result is more verbose than hygienic macros and only a little more
verbose than Common Lisp's macros.
5. Notes and open questions
5.1. Compatibility notes
T and MIT Scheme already have syntax tables, but they're mutable.
Expansion procedures are called "syntax descriptors" in T. T has a
MACRO-EXPANDER macro that creates expansion procedures. MIT Scheme has
a MACRO macro for the same purpose.
In MIT Scheme, the syntax table is passed implicitly as a fluid-bound
variable. In T, it is possible to get at the syntax table, as an extra
argument to an expander, but it's painful. In Common Lisp, the
syntax-table corresponds roughly to the &environment argument to macros
(except that in CL you are forbidden to redefine a special
form -- this proposal permits that).
PREPROCESS is similar to the SYNTAX procedure in MIT Scheme, and
vaguely similar to STANDARD-COMPILER in T.
ABSOLUTE is similar to MIT Scheme's ACCESS. In ACCESS, the last
subform is evaluated, which isn't quite what we want, since that makes
it context-sensitive again (although this greatly reduces
opportunities for lossage). [Also, I find the argument order to
ACCESS confusing; it's backwards from the way filenames are usually
written (on Multics and Unix at least) and also backwards from things
like VECTOR-REF, where the aggregate or superior object comes first.]
5.2. Syntax table used by LOAD and/or command loop
1. Which syntax table is used to process forms read by LOAD?
2. Which syntax table is used to process forms typed at a
read-eval-print loop?
3. How can one perform definitions in the environment that will
be seen by USING-SYNTAX?
Here is one conservative proposal, although there are many
possibilities and variations:
The top level syntax-table for any file is initially
SCHEME-SYNTAX-TABLE. Changes must be made explicitly via USING-SYNTAX
or LET-SYNTAX, which should be wrapped around the enire file if
necessary.
The syntax table used at the read-eval-print loop is changed in some
implementation-dependent manner (there's nothing that even says there
IS a read-eval-print loop). E.g. there could be a procedure
(SET-CURRENT-SYNTAX-TABLE! syntax-table).
5.3. Keywords and variables
Several people have complained that
(let ((if list))
(if 1 2 3))
ought, according to the rules of lexical scope, to evaluate to (1 2 3).
It is possible in this framework to make syntax-tables in which variable
bindings shadow syntax bindings, but it requires cooperation from
every macro that binds variables (LET, LETREC, LAMBDA, etc.):
(add-syntax foo 'lambda
(lambda (exp st)
... (do ((vars vars (cdr vars))
(st st (remove-syntax (car vars) st)))
...) ...))
I'd rather not raise this question here since it's really orthogonal to
the rest of this proposal.
5.4. Macros that expand into multiple definitions
The syntax of <program> should be extended to include sequence
expressions:
<program> --> <top>*
<top> --> <definition>
| <expression>
| (begin <top>+)
This is so that macros at top level can expand into multiple
definitions: (begin (define foo ...) (define bar ...)).
There is an ambiguity here in that (begin <expression>+) can be parsed
in either of two ways, but the meaning is the same in either case, so
this isn't a grave problem.
Should the syntax of a <body> be similarly extended to allow
expansions like
(lambda (...) (begin (define ...) (define ...)) ...)?
What about
(lambda (...) (begin (define ...) (compute ...)) ...)?
What about
(lambda (...) (begin (compute ...) (define ...)) ...)?
5.5. Delayed expansion
Some implementations may want to delay macro expansion (preprocessing)
so that the expression tree is processed breadth-first instead of
depth-first. This could be handy for any number of purposes, e.g. in
preventing propagation of syntax errors, in performing
alpha-conversion in parallel with macro expansion, or to speed up file
loading. This should be explicitly permitted by the proposal. The
only way it would make a difference is if a macro expander could
observe or perform a side-effect.
5.6. Analysis of subexpressions
I think it's a bad idea for macros to go snooping into their
subexpressions. This should be unnecessary for "optimization" (the
main reason people did this in Maclisp); it's hard to come
up with valid reasons to want to do it.
On the other hand, it would be nice if someone writing a compiler
could portably use PREPROCESS as a front end. This would mandate having
operations for decomposing preprocessed expressions. One possibility
would be to define a set of accessors and predicates, as MIT Scheme
does. Another way to do it would be to have one or more coercion
functions to do the inverse of PREPROCESS, e.g. (UNPREPROCESS p-e)
would return an expression e such that
(PREPROCESS e SCHEME-SYNTAX-TABLE)
would return something equivalent to p-e; then one could use CAR and
CDR to take the result apart.
Either way you have to answer sticky questions, however, such as
whether derived expressions like LETREC should be expanded out or
preserved.
5.7. Other ways to manipulate the keyword/expander association
Maybe we also want MOVE-KEYWORD or RENAME-KEYWORD?
References.
[1] Dybvig, Friedman, and Haynes. Expansion-passing style: Beyond
conventional macros. 1986 ACM Lisp & FP Conference.
[2] Kohlbecker's thesis.
[3] T manual.
[4] Common Lisp.
[5] Revised↑3 Scheme Report.
---------------------
Appendix: a rudimentary implementation.
;;; Preprocessed expressions
(define (preprocessed? obj)
(and (vector? obj)
(= (vector-length obj) 2)
(eq? (vector-ref obj 0) 'preprocessed)))
(define (make-preprocessed core-exp)
(if (preprocessed? core-exp)
core-exp
(vector 'preprocessed core-exp)))
;;; ->CORE translates a preprocessed expression into the core language.
(define (->core exp)
(if (preprocessed? exp)
(vector-ref exp 1)
(error "not a preprocessed expression" exp)))
;;; A syntax table is a procedure, and PREPROCESS is FUNCALL.
(define (preprocess exp st)
(st exp st))
(define (add-keyword st0 keyword proc)
(lambda (exp st)
(if (and (pair? exp) (eq? (car exp) keyword))
(proc exp st)
(st0 exp st))))
;;; An empty syntax table; defines no special expression types.
(define empty-syntax-table
(lambda (exp st)
(cond ((symbol? exp)
(make-preprocessed exp))
((or (boolean? exp) (number? exp) (char? exp) (string? exp))
(make-preprocessed exp))
((preprocessed? exp)
exp) ;Idempotent!
((not (pair? exp))
(error "not a syntactically valid expression" exp))
(else
;; Combination
;; (There is a small bug here if REMOVE-KEYWORD exists)
(make-preprocessed (map (lambda (arg)
(->core (preprocess arg st)))
exp))))))
;;; Core syntax table. Understands the primitive expression types, but
;;; not the derived ones.
(define core-syntax-table
(do ((st empty-syntax-table
(add-keyword st (caar z) (cadar z)))
(z `((quote
,(lambda (exp st)
(make-preprocessed exp)))
(lambda
,(lambda (exp st)
(make-preprocessed
`(lambda ,(cadr exp)
,(->core (preprocess (caddr exp) st))))))
(set!
,(lambda (exp st)
(make-preprocessed
`(set! ,(cadr exp)
,(->core (preprocess (caddr exp) st))))))
(define
,(lambda (exp st)
(make-preprocessed
`(define ,(cadr exp)
,(->core (preprocess (caddr exp) st))))))
(if
,(lambda (exp st)
(make-preprocessed
`(if ,(->core (preprocess (cadr exp) st))
,(->core (preprocess (caddr exp) st))
,(->core (preprocess (cadddr exp) st))))))
(begin
,(lambda (exp st)
(make-preprocessed
`(begin ,@(map (lambda (exp)
(->core (preprocess exp st)))
(cdr exp))))))
(absolute
,(lambda (exp st)
(make-preprocessed exp))))
(cdr z)))
((null? z) st)))
;;; The scheme syntax table defines the derived expression types.
(define scheme-syntax-table
(do ((st core-syntax-table
(add-keyword st (caar z) (cadar z)))
(z `((and
,(lambda (exp st)
(let ((forms (cdr exp))
(j (lambda (exp) (preprocess exp st))))
(cond ((null? forms) `#t)
((null? (cdr forms)) (j (car forms)))
(else
(preprocess
`((lambda (p th)
(if p (th) p))
,(car forms)
(lambda () (and ,@(map j (cdr forms)))))
scheme-syntax-table))))))
;; ...
(lambda
,(lambda (exp st)
(preprocess
`(lambda ,(cadr exp)
,(preprocess-body (cddr exp) st))
core-syntax-table)))
;; (letrec ,...)
;; ...
;; (quasiquote ,... (absolute scheme-env cons) ...)
)
(cdr z)))
((null? z) st)))
;;; Implements implicit begin and internal defines for lambda bodies.
(define (preprocess-body body st)
(let ((definition? (lambda (exp)
(and (pair? exp) (eq? (car exp) 'define))))
(definition-lhs cadr)
(definition-rhs caddr))
(let loop ((l (map (lambda (exp)
(preprocess exp st))
body))
(d '()))
(if (null? l)
(error "no non-definitions in body" body)
(let ((exp (->core (car l)))) ;Analyze
(if (not (definition? exp))
(preprocess (if (null? d)
`(begin ,@l)
`(letrec ,(reverse d) ,@l))
scheme-syntax-table)
(loop (cdr l)
(cons `(,(definition-lhs exp)
,(make-preprocessed (definition-rhs exp)))
d))))))))
; Fin
∂29-Mar-87 1558 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU meeting
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 15:58:51 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAR 87 19:04:10 EST
Date: Sun 29 Mar 87 18:57:57-EST
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: meeting
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12290358923.7.GJS@OZ.AI.MIT.EDU>
I agree with Will. I think we should meet and get things under control.
-------
∂30-Mar-87 0917 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ALAN: multiple return values]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 09:17:50 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 12:23:13 EST
Date: Mon, 30 Mar 87 12:20:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [ALAN: multiple return values]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <175971.870330.JAR@AI.AI.MIT.EDU>
Date: Sun, 29 Mar 87 02:29:12 EST
From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
To: JAR at AI.AI.MIT.EDU
Re: multiple return values
I will confine myself to reminding you of what I said the last time this
subject was raised: Any implementation of multiple-values that doesn't
have the property that ordinary continuations (for example the continuation
passed to F in (+ (F) 3)) will accept and ignore extra values has missed
the point of multiple values.
Let me try putting it another way: If you decide on a semantics for
multiple values that has the property that a correct implementation can be
written in straight R↑3RS Scheme, then what have you accomplished? You
haven't given the users anything they couldn't have written for themselves.
(Yes, perhaps you can arrange to implement it more efficiently, but since
when has that been the the spirit of the language?)
∂30-Mar-87 1023 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU [ALAN: multiple return values]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 10:23:15 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 30 Mar 87 13:08:03 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 30 Mar 87 13:04:33 est
Date: Mon, 30 Mar 87 13:04:33 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703301804.AA09557@geneva>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Mon, 30 Mar 87 12:20:13 EST <175971.870330.JAR@AI.AI.MIT.EDU>
Subject: [ALAN: multiple return values]
I agree with ALAN here. I used to prefer the stricter semantics, but
after some thought I've arrived at the conclusion that it is silly.
It adds no new functionality and is hardly more convenient than
passing an explicit continuation (syntax for which can be provided).
The case I like to consider is the case of QUOTIENT (there are many
others like it). It is often very cheap (or even necessary) to
produce the remainder of an integer division when computing the
quotient. Thus it would be natural for QUOTIENT to return the
remainder as a second value. The strict semantics would force anyone
using quotient to use RECEIVE-VALUES, although a very common use, in
fact, is to ignore the remainder. In the absence of "loose" multiple
values, there are two possibilities, both distasteful:
- Provide another procedure which returns both (as in the case of MIT
Scheme's INTEGER-DIVIDE), but this tends to increase the number of
procedures that users have to know about to an unreasonable extent.
- Force users to use both QUOTIENT and REMAINDER when both results are
desired. The only way to get efficiency out of this one is to fall
into the "mighty compiler" assumption.
I think, therefore, that it would not be a good idea to agree on a
standard that allows the strict semantics (and I would vote against
it). If some people have serious objections to the "loose" semantics,
then we may be better off not standardizing at all.
∂30-Mar-87 1136 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU almost scheme in common lisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 11:36:14 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 14:05:11 EST
Date: Mon, 30 Mar 87 14:01:36 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: almost scheme in common lisp
To: common-lisp@SAIL.STANFORD.EDU, scheme@MC.LCS.MIT.EDU
Message-ID: <176048.870330.JAR@AI.AI.MIT.EDU>
I have written a macro package which implements Scheme, less general
tail-recursion and first-class continuations, in Common Lisp. It
appears to be effective at transforming any Common Lisp implementation
into an acceptable development environment for Scheme programs.
Loops written using LETREC, internal DEFINE, or "named LET" are
macroexpanded into an appropriate TAGBODY construct, but other than
that, tail recursion is only done at the whim of your particular CL
implementation.
Being a macro package and not a compiler or interpreter, continuations
also clearly can't work in general (unless, again, your CL just happens
to support them). Other incompatibilities with the "Revised↑3" Scheme
report are minor.
It's called "Pseudoscheme" and resides in
MC.LCS.MIT.EDU: "JAR;PSEUDO >"
The documentation is in
MC.LCS.MIT.EDU: "JAR;PSEUDO DOC"
I'll send it by electronic mail to those unable to FTP it. Please
send mail to INFO-CLSCHEME-REQUEST@MC.LCS.MIT.EDU if you start using it,
so you can stay up to date on improvements.
Feel free to redistribute it, but try to let me know if you do so.
The documentation file describes its peculiarities in somewhat more detail.
- Jonathan Rees
∂30-Mar-87 1455 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 14:54:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 17:33:22 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac22144; 30 Mar 87 15:43 EST
Received: from tektronix.tek.com by RELAY.CS.NET id af28003; 30 Mar 87 15:39 EST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA03473; Mon, 30 Mar 87 09:24:47 PST
Received: by tekchips.TEK.COM (5.31/6.19)
id AA02271; Mon, 30 Mar 87 09:23:19 PST
Message-Id: <8703301723.AA02271@tekchips.TEK.COM>
To: JAR@MC.LCS.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: multiple return values
In-Reply-To: Your message of Sat, 28 Mar 87 00:03:12 EST.
<174983.870328.JAR@AI.AI.MIT.EDU>
Date: 30 Mar 87 09:23:17 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET
Will:
I see no way to implement the proposed procedures in R3RS Scheme, but
most implementations should find it easy to add them.
Jonathan:
If "wrong" doesn't imply "signals an error" then the following is a
correct implementation of alternative 1. This is pretty much how the
feature was implemented in T2....
Unfortunately, Jonathan's simple implementation of receive-values and
return-values doesn't quite work: (list 1 (return-values 2) 3) is
supposed to evaluate to (1 2 3) but with Jonathan's implementation it
evaluates to (1 (values-marker 2) 3). The problem is that RETURN-VALUES
doesn't know whether it is returning to a continuation created by
RECEIVE-VALUES or to an "ordinary" continuation. The simplest correct
implementations I've been able to imagine require that one machine
instruction be added to the standard continuation invocation sequence
(i.e. returns from closed-coded non-tail-recursive calls).
Peace, Will
∂30-Mar-87 1509 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 15:08:53 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 17:38:45 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab22416; 30 Mar 87 15:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aj28003; 30 Mar 87 15:41 EST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA07158; Mon, 30 Mar 87 10:54:59 PST
Received: by tekchips.TEK.COM (5.31/6.19)
id AA03755; Mon, 30 Mar 87 10:53:26 PST
Message-Id: <8703301853.AA03755@tekchips.TEK.COM>
To: RRRS-Authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Cc: KMP@SCRC-STONY-BROOK.ARPA, jinx%geneva.ai.mit.edu@RELAY.CS.NET
Subject: Re: Let's get together again
In-Reply-To: Your message of Sat, 28 Mar 87 16:11:21 est.
<8703282111.AA05557@geneva>
Date: 30 Mar 87 10:53:22 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET
27-28 June (Saturday and Sunday) is fine with me. The person in charge
of local arrangements probably ought to be the one to decide the dates
as well. Any volunteers?
Norman Adams pointed out to me that Jonathan's implementation of
multiple return values (as in equation 1 for "single") can be patched
quite easily---he'll be posting the patch. The ease of implementing
equation 1 in existing implementations must then make it my favorite
too.
Peace, Will
∂30-Mar-87 1858 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 18:58:08 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 21:58:15 EST
Date: Mon, 30 Mar 87 21:39:51 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Let's get together again
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 30 Mar 87 10:53:22 PST (Mon) from willc%tekchips.tek.com at RELAY.CS.NET
Message-ID: <176355.870330.JAR@AI.AI.MIT.EDU>
I think it's a great idea.
If no one else from MIT wants to do local arrangements I'd be happy to.
∂30-Mar-87 2026 @MC.LCS.MIT.EDU:adams%tekchips.tek.com@RELAY.CS.NET Re: multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 20:25:52 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 23:31:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae29609; 30 Mar 87 22:44 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ac00188; 30 Mar 87 22:40 EST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA10175; Mon, 30 Mar 87 13:58:25 PST
Received: by tekchips.TEK.COM (5.31/6.19)
id AA06188; Mon, 30 Mar 87 13:56:53 PST
Date: Mon, 30 Mar 87 13:56:53 PST
From: Norman Adams <adams%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8703302156.AA06188@tekchips.TEK.COM>
Subject: Re: multiple return values
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees <JAR@mc.lcs.mit.edu>, Sat, 28 Mar 87 00:03:12 EST
If "wrong" doesn't imply "signals an error" then the following is a
correct implementation of alternative 1. This is pretty much how the
feature was implemented in T2.
(define values-marker (list 'values-marker))
(define receive-values
(lambda (thunk proc)
(let ((vals (thunk)))
(if (and (pair? vals) (eq? (car vals) values-marker))
(apply proc (cdr vals))
(proc vals)))))
(define return-values
(lambda vals
(cons values-marker vals)))
Not quite a correct implementation, I think. RETURN-VALUES should
canonicalize single return values:
(define return-values
(lambda vals
(if (and (pair? vals) (null? (cdr vals)))
(car vals)
(cons values-marker vals))))
-Norman
-------
∂30-Mar-87 2112 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 21:12:06 PST
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 31 Mar 87 00:04:46 EST
Date: 30 Mar 87 2057 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: A Couple of Fun Programs
To: scheme@MC.LCS.MIT.EDU
Jonathan sent out an interesting program the other day, and I was prompted
to send two more. These are (ugh, bletch) Common Lisp programs, but I
think it's instructive to see that CL programs don't have to look
completely silly (not using DO loops, &-constructs, &tc). It's your job
to figure them out without running them. LABELS is like LETREC, TRUNCATE
rounds towards 0, (VALUES x y z) returns three values, and
(MULTIPLE-VALUE-BIND (X Y Z) (RETURN-THREE-VALUES) . <forms>) binds the
three variables X, Y, and Z appropriately and executes <forms>.
(defun f (n)
(labels ((f (n m)
(if (= n m)
n
(let ((h (truncate (+ m n) 2)))
(* (f n h) (f (+ h 1) m))))))
(f 1 n)))
(defun f (i)
(labels ((g (n n-1 n-2 m m-1 m-2)
(let ((k (* n-1 m-1)))
(values (+ (* n m) k)
(+ (* n m-1) (* n-1 m-2))
(+ k (* n-2 m-2)))))
(h (i)
(cond ((zerop i) (values 1 0 0))
((= i 1) (values 1 1 0))
((evenp i)
(multiple-value-bind (n n-1 n-2)
(h (truncate i 2))
(g n n-1 n-2 n n-1 n-2)))
(t
(multiple-value-bind (n n-1 n-2)
(h (1- i))
(g 1 1 0 n n-1 n-2))))))
(prog1 (h i))))
They are written using non-instructive variable names.
-rpg-
∂31-Mar-87 1146 @MC.LCS.MIT.EDU:gls@Think.COM A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 11:32:07 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 31 Mar 87 12:56:36 EST
Received: from feuerbach by Think.COM via CHAOS; Tue, 31 Mar 87 12:06:05 EST
Date: Tue, 31 Mar 87 12:06 EST
From: Guy Steele <gls@Think.COM>
Subject: A Couple of Fun Programs
To: scheme@mc.lcs.mit.edu
Cc: RPG@sail.stanford.edu, gls@think.com
In-Reply-To: <8703310526.AA01555@Think.COM>
Message-Id: <870331120636.7.GLS@FEUERBACH.THINK.COM>
Those who found RPG's sample programs difficult to read because
of the "non-instructive variable names" may find the following
versions (completely equivalent, valid Common Lisp, and tested)
a bit more perspicuous:
(defun f (if)
(labels ((packagep (if cons)
(if (= if cons)
if
(let ((with-open-file (truncate (+ cons if) 2)))
(* (packagep if with-open-file) (packagep (+ with-open-file 1) cons))))))
(packagep 1 if)))
(defun f (if)
(labels ((atanh (go cond labels do* proclaim set-macro-character)
(let ((setf (* cond proclaim)))
(values (+ (* go do*) setf)
(+ (* go proclaim) (* cond set-macro-character))
(+ setf (* labels set-macro-character)))))
(read-preserving-whitespace (if)
(cond ((zerop if) (values 1 0 0))
((= if 1) (values 1 1 0))
((evenp if)
(multiple-value-bind (go cond labels)
(read-preserving-whitespace (truncate if 2))
(atanh go cond labels go cond labels)))
(t
(multiple-value-bind (go cond labels)
(read-preserving-whitespace (1- if))
(atanh 1 1 0 go cond labels))))))
(prog1 (read-preserving-whitespace if))))
--Quux
∂31-Mar-87 1703 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 17:03:33 PST
Received: from BFLY-VAX.BBN.COM (TCP 20026200235) by MC.LCS.MIT.EDU 31 Mar 87 19:01:10 EST
To: Guy Steele <gls@think.com>
cc: scheme@mc.lcs.mit.edu, RPG@sail.stanford.edu, allen@bfly-vax.bbn.com
Subject: Re: A Couple of Fun Programs
In-reply-to: Your message of Tue, 31 Mar 87 12:06 EST.
<870331120636.7.GLS@FEUERBACH.THINK.COM>
Date: 31 Mar 87 18:04:57 EST (Tue)
From: allen@bfly-vax.bbn.com
Ever thought about doing some user-interface work for Unix? It's clear that
you have the talent.
/Don
∂31-Mar-87 1743 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA Scheme Numbers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 17:43:04 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 31 Mar 87 19:03:33 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA11841; Tue, 31 Mar 87 15:36:20 est
Date: Tue, 31 Mar 87 15:36:20 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 31 Mar 87 15:36:20 est
Message-Id: <8703312036.AA11841@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Scheme Numbers
Last night I tried to find out where the R↑3RS disallows
the reordering of computation involving inexact numbers.
Numerical analysts know that floating point addition and
multiplication are not commutative, and write code that
depends on the fact that these operation are to be preformed
in the precise order given. One of the things FORTRAN does
correctly is promise not to reorder computations involving
inexact numbers. I never found that promise last night.
Let's make that promise to Scheme users in R↑4RS.
John
∂31-Mar-87 1829 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 18:29:12 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 31 Mar 87 21:14:11 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag22435; 31 Mar 87 20:42 EST
Received: from ti-csl by RELAY.CS.NET id ar06470; 31 Mar 87 20:35 EST
Received: from home (home.ARPA) by tilde id AA22798; Tue, 31 Mar 87 18:25:08 cst
Received: by home id AA08042; Tue, 31 Mar 87 18:25:03 cst
Date: Tue, 31 Mar 87 18:25:03 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704010025.AA08042@home>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: multiple return values
(1) I agree with ALAN and Jinx that it seems pretty useless to specify
a multiple value capability and not go beyond Will's alternative #1.
Since I intend to implement Common Lisp on top of Scheme, I will want
to extend the essential capability anyway. (Are ALAN and Jinx arguing
for #2 or #3?)
(2) In his rationale, Will said "The Common Lisp position would say
that when zero values are returned to a continuation that is expecting
one value, then the symbol NIL is passed to the continuation." I
think we could specify this to be "the false value" or "the empty
list" and remain compatible with Common Lisp without having to make
the symbol NIL noteworthy in Scheme.
(3) Will's proposal does not mention CALL-WITH-CURRENT-CONTINUATION.
It seems that a continuation object should accept an arbitrary number
of arguments if we take alternative #2 or #3. If so, we could define
(RETURN-VALUES A B) to be the same as (CALL/CC (LAMBDA (K) (K A B))).
(4) It seems to me that the hairiest part of the multiple value
"feature" in Common Lisp is MULTIPLE-VALUE-PROG1. Something like this
is needed, at least "behind the scenes", if we expect DYNAMIC-WIND
(etc.) to pass through multiple values. We could express
(MULTIPLE-VALUE-PROG1 A B ...) as
(receive-values A (lambda L B ... (apply return-values L))) ,
but that is pretty expensive. Is this common enough to require
standardization so implementors could work on more efficient
mechanisms?
(5) JAR finds the proposed feature "to be pretty unuseable unless
there is some syntactically sugared way to use RECEIVE-VALUES." If
this is true, I think we must agree on what sugar to add. What's the
point of standardizing on something that is too cryptic to be used by
anyone?
I like T's RECEIVE, which I understand to be defined as
(receive <formals> <m-v-expression> . <body>)
==> (receive-values (lambda () <m-v-expression>)
(lambda <formals> . body>))
The key for me is that <formals> is a complete lambda list, possibly
containing "optional" and "rest" arguments, and is not just a list of
"required" identifiers. This seems more flexible than Common Lisp's
MULTIPLE-VALUE-BIND.
If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
but I would prefer something like MULTIPLE-VALUE-LET.
(6) Let's get down to brass tacks and argue about names! I'm bothered
by the "return" in RETURN-VALUES. As Will pointed out, the name
RETURN would be confusing to refugees from other Lisps. However,
RETURN-VALUES still seems to imply an exit from the calling procedure.
A user might ask whether the procedure
(LAMBDA (A B C) (+ A (RETURN-VALUES B) C))
returns the sum of A, B, and C or just B? I think we all intend for
RETURN-VALUES to "return" to its caller (the middle of the body), not
to that procedure's caller. I suggest renaming RETURN-VALUES to be
MULTIPLE-VALUES.
Likewise, the "receive" in RECEIVE-VALUES seems strange; I would
expect the complementary routine to be SEND-VALUES. How about
CALL-WITH-MULTIPLE-VALUES (call/mv?) by analogy with CALL-WITH-
CURRENT-CONTINUATION (call/cc)? (I'm not sure if I'm joking!)
Regards,
David Bartley
∂31-Mar-87 2009 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 20:08:55 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 87 23:02:38 EST
Date: Tue, 31 Mar 87 22:13:26 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple return values
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 31 Mar 87 18:25:03 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <177055.870331.JAR@AI.AI.MIT.EDU>
I would strongly oppose the Common Lisp multiple value semantics. I
find it to be very distasteful. If this means that the language has no
multiple values primitively, and I have to implement semantics #1 myself
using lists or closures or whatever, that's fine with me.
If I have many sympathizers then I'd say it appears that we're
as deadlocked as we were last time this came up...
There's a deeper issue here: I have found that I use a number of
features which can be implemented easily enough in Scheme, but for which
particular scheme implementations have efficient, low-level, nonstandard
support. For example: multiple values, fixnum arithmetic, byte vectors,
certain string operations (like what was in the R↑2 report), hash
tables, PEEK-CHAR, and bitwise logical opertions. What I do is I have
one particular file which implements all these features portably. I can
then replace this file for particular implementations to get better
performance. In general I'll have N+1 versions of this file, one
portable version plus one version for each implementation for which it's
been tuned.
Does anyone else do things like this? Or am I the only person who really
tries to write nontrivial programs that are both portable and fast?
The fact that my programs are portable, and that this "tuning file" is
small in size, is of course due to our standardization effort. It's not
clear that implementation-dependent tuning can go away completely, but
the smaller that file is, the happier I'll be. This is the main
argument I see for adding logically redundant features (like multiple
values #1) to the standard; I assume that's why LENGTH and MEMQ are
in the report. Maybe we need a better way to organize these redundant
features; they don't really belong in the main part of the report.
Jonathan
∂31-Mar-87 2025 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 20:25:24 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 87 23:23:05 EST
Date: Tue, 31 Mar 87 22:17:54 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple return values
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 31 Mar 87 18:25:03 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <177057.870331.JAR@AI.AI.MIT.EDU>
Date: Tue, 31 Mar 87 18:25:03 cst
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Likewise, the "receive" in RECEIVE-VALUES seems strange; I would
expect the complementary routine to be SEND-VALUES. How about
CALL-WITH-MULTIPLE-VALUES (call/mv?) by analogy with CALL-WITH-
CURRENT-CONTINUATION (call/cc)? (I'm not sure if I'm joking!)
How about CALL-CURRENT-CONTINUATION ? A little long I guess... I don't
much like the Unix command names (mv, cc)...
SEND-VALUES isn't so bad.
PROVIDE-VALUES, GIVE-VALUES
ACCEPT-VALUES, USE-VALUES, TAKE-VALUES, GET-VALUES
∂31-Mar-87 2037 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU More on Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 20:37:27 PST
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 31 Mar 87 23:24:14 EST
Date: 31 Mar 87 1531 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: More on Fun Programs
To: scheme@MC.LCS.MIT.EDU
Now that you've seen the instructional version of the second puzzle
function, here's the slightly bummed (15% faster) version:
(defun f (i)
(labels ((g (i)
(cond ((zerop i) (values 1 0))
((= i 1) (values 1 1))
((evenp i)
(multiple-value-bind (n n-1)
(g (/ i 2))
(values (+ (* n n) (* n-1 n-1))
(+ (* n n-1) (* n-1 (- n n-1))))))
(t
(multiple-value-bind (n n-1)
(g (- i 1))
(values (+ n n-1) n))))))
(values (g i))))
-rpg-
∂01-Apr-87 0215 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:ETSTMOL@HDETUD1.BITNET NOTE from ETSTMOL
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 02:15:45 PST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 1 Apr 87 05:01:23 EST
Received: from HDETUD1(ETSTMOL) by MITVMA (Mailer X1.23) id 8125;
Wed, 01 Apr 87 04:47:17 EST
Date: Wed, 01 Apr 87 11:42:45 MET
To: SCHEME@MC.LCS.MIT.EDU
From: ETSTMOL@HDETUD1.BITNET
Subject: NOTE from ETSTMOL
Date: 1 April 1987, 11:41:06 MET
From: Marcel Mol ETSTMOL at HDETUD1
Delft University of Technology
Faculty of Electrical engineering
To: SCHEME at MC.LCS
At the Delft University in the Netherlands we started a Lisp
project. At this moment we want to build a package onto scheme
that implements Common Lisp. Has someone done this before, or
thought about it before? We appreciate any help.
Thanks
Marcel Mol, Frank ten Wolde
Anton Klaasen, Arno Wezenbeek
∂01-Apr-87 0546 @MC.LCS.MIT.EDU:kwh@ multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 05:46:07 PST
Received: from geneva (TCP 20015013114) by MC.LCS.MIT.EDU 1 Apr 87 08:49:46 EST
Received: by ; Wed, 1 Apr 87 08:48:04 est
Date: Wed, 1 Apr 87 08:48:04 est
From: kwh@@ (Ken Haase)
Message-Id: <8704011348.AA08026@geneva>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Tue, 31 Mar 87 22:13:26 EST <177055.870331.JAR@AI.AI.MIT.EDU>
Subject: multiple return values
I do the same thing, having a set of `PLUS' files which extend R↑*S in
implementation dependent ways to provide features I want to use. One
thing that I've found useful in transporting code between Common LISP
implementations (or Symbolics LISP releases!) has been a standard way
(the STATUS form) for determining what system or release I'm in.
Beyond this, though I find it somewhat distasteful, the presence of
the `#+' character macro for read-time conditionalizing code makes
writing transportable code a good deal easier.
Ken
∂01-Apr-87 1030 @MC.LCS.MIT.EDU:gls@Think.COM A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 10:29:49 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 1 Apr 87 12:58:45 EST
Received: from feuerbach by Think.COM via CHAOS; Wed, 1 Apr 87 12:51:57 EST
Date: Wed, 1 Apr 87 12:52 EST
From: Guy Steele <gls@Think.COM>
Subject: A Couple of Fun Programs
To: scheme@mc.lcs.mit.edu
Cc: RPG@sail.stanford.edu, gls@think.com
In-Reply-To: <870331120636.7.GLS@FEUERBACH.THINK.COM>
Message-Id: <870401125208.6.GLS@FEUERBACH.THINK.COM>
Date: 31 Mar 87 1531 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
Now that you've seen the instructional version of the second
puzzle function, here's the slightly bummed (15% faster) version:
...
And, as a further public service, here is a translation:
(defun f (*)
(labels ((> (*)
(cond ((zerop *) (values 1 0))
((= * 1) (values 1 1))
((evenp *)
(multiple-value-bind (+ /)
(> (/ * 2))
(values (+ (* + +) (* / /))
(+ (* + /) (* / (- + /))))))
(t
(multiple-value-bind (+ /)
(> (- * 1))
(values (+ + /) +))))))
(values (> *))))
--Quux
∂01-Apr-87 1142 @MC.LCS.MIT.EDU:gls@Think.COM multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 11:41:47 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 1 Apr 87 13:03:52 EST
Received: from feuerbach by Think.COM via CHAOS; Wed, 1 Apr 87 12:34:23 EST
Date: Wed, 1 Apr 87 12:34 EST
From: Guy Steele <gls@Think.COM>
Subject: multiple return values
To: bartley%home%ti-csl.csnet@relay.cs.net, rrrs-authors@mc.lcs.mit.edu
Cc: gls@think.com
In-Reply-To: <8704010025.AA08042@home>
Message-Id: <870401123434.4.GLS@FEUERBACH.THINK.COM>
Date: Tue, 31 Mar 87 18:25:03 cst
From: David Bartley <bartley%home%ti-csl.csnet@relay.cs.net>
...
(6) Let's get down to brass tacks and argue about names! I'm bothered
by the "return" in RETURN-VALUES. As Will pointed out, the name
RETURN would be confusing to refugees from other Lisps. However,
RETURN-VALUES still seems to imply an exit from the calling procedure.
A user might ask whether the procedure
(LAMBDA (A B C) (+ A (RETURN-VALUES B) C))
returns the sum of A, B, and C or just B? I think we all intend for
RETURN-VALUES to "return" to its caller (the middle of the body), not
to that procedure's caller. I suggest renaming RETURN-VALUES to be
MULTIPLE-VALUES. ...
Actually, I think this is one of the few names that Common Lisp
really got right. What's wrong with VALUES? Note that it is likely
to be used much more frequently than the matching receiving form.
--Guy
∂01-Apr-87 1158 @MC.LCS.MIT.EDU:gls@Think.COM Apologies
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 11:58:19 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 1 Apr 87 14:47:08 EST
Received: from feuerbach by Think.COM via CHAOS; Wed, 1 Apr 87 14:40:24 EST
Date: Wed, 1 Apr 87 14:40 EST
From: Guy Steele <gls@Think.COM>
Subject: Apologies
To: scheme@mc.lcs.mit.edu
In-Reply-To: <870401125208.6.GLS@FEUERBACH.THINK.COM>
Message-Id: <870401144024.7.GLS@FEUERBACH.THINK.COM>
It has been pointed out to me that me translation of
RPG's latest program does not preserve its semantics
quite properly because "+" and "*" are typically proclaimed
SPECIAL in Common Lisp implementations and therefore are
dynamically bound whether you like it or not. Here is
a correct translation that avoids this problem, and I'll not
trouble you any further.
--Quux
(defun f (])
(labels (([ (])
(cond ((zerop ]) (values 1 0))
((= ] 1) (values 1 1))
((evenp ])
(multiple-value-bind ({ })
([ (/ ] 2))
(values (+ (* { {) (* } }))
(+ (* { }) (* } (- { }))))))
(t
(multiple-value-bind (+ })
([ (- ] 1))
(values (+ { }) {))))))
(values ([ ]))))
∂01-Apr-87 1907 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 19:07:12 PST
Received: from BFLY-VAX.BBN.COM (TCP 20026200235) by MC.LCS.MIT.EDU 1 Apr 87 19:50:49 EST
To: Guy Steele <gls@think.com>
cc: scheme@mc.lcs.mit.edu, RPG@sail.stanford.edu, allen@bfly-vax.bbn.com
Subject: Re: A Couple of Fun Programs
In-reply-to: Your message of Tue, 31 Mar 87 12:06 EST.
<870331120636.7.GLS@FEUERBACH.THINK.COM>
Date: 01 Apr 87 17:54:35 EST (Wed)
From: allen@bfly-vax.bbn.com
To help you get a start in your gnu career as a Unix hacker, here's my
conjecture as to how you might have written the second function had
you worked at Bell Labs or Berkeley:
(defun yucc (++)
(labels (($1 (grep ↑[↑:]*:: /usr/etc/passwd kill %1 a.out)
(let ((*p++ (* ↑[↑:]*:: %1)))
(values (+ (* grep kill) *p++)
(+ (* grep %1) (* ↑[↑:]*:: a.out))
(+ *p++ (* /usr/etc/passwd a.out)))))
(*argv[] (++)
(cond ((zerop ++) (values 1 0 0))
((= ++ 1) (values 1 1 0))
((evenp ++)
(multiple-value-bind (grep ↑[↑:]*:: /usr/etc/passwd)
(*argv[] (truncate ++ 2))
($1 grep ↑[↑:]*:: /usr/etc/passwd grep ↑[↑:]*::
/usr/etc/passwd)))
(t
(multiple-value-bind (grep ↑[↑:]*:: /usr/etc/passwd)
(*argv[] (1- ++))
($1 1 1 0 grep ↑[↑:]*:: /usr/etc/passwd))))))
(prog1 (*argv[] ++))))
%!$don
∂01-Apr-87 1953 @MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com Re: A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 19:53:18 PST
Received: from BFLY-VAX.BBN.COM (TCP 20026200235) by MC.LCS.MIT.EDU 1 Apr 87 19:50:49 EST
To: Guy Steele <gls@think.com>
cc: scheme@mc.lcs.mit.edu, RPG@sail.stanford.edu, allen@bfly-vax.bbn.com
Subject: Re: A Couple of Fun Programs
In-reply-to: Your message of Tue, 31 Mar 87 12:06 EST.
<870331120636.7.GLS@FEUERBACH.THINK.COM>
Date: 01 Apr 87 17:54:35 EST (Wed)
From: allen@bfly-vax.bbn.com
To help you get a start in your gnu career as a Unix hacker, here's my
conjecture as to how you might have written the second function had
you worked at Bell Labs or Berkeley:
(defun yucc (++)
(labels (($1 (grep ↑[↑:]*:: /usr/etc/passwd kill %1 a.out)
(let ((*p++ (* ↑[↑:]*:: %1)))
(values (+ (* grep kill) *p++)
(+ (* grep %1) (* ↑[↑:]*:: a.out))
(+ *p++ (* /usr/etc/passwd a.out)))))
(*argv[] (++)
(cond ((zerop ++) (values 1 0 0))
((= ++ 1) (values 1 1 0))
((evenp ++)
(multiple-value-bind (grep ↑[↑:]*:: /usr/etc/passwd)
(*argv[] (truncate ++ 2))
($1 grep ↑[↑:]*:: /usr/etc/passwd grep ↑[↑:]*::
/usr/etc/passwd)))
(t
(multiple-value-bind (grep ↑[↑:]*:: /usr/etc/passwd)
(*argv[] (1- ++))
($1 1 1 0 grep ↑[↑:]*:: /usr/etc/passwd))))))
(prog1 (*argv[] ++))))
%!$don
∂01-Apr-87 2232 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 22:32:28 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 2 Apr 87 00:20:13 EST
Date: Wed, 1 Apr 87 21:51:51 EST
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: multiple return values
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 31 Mar 87 22:13:26 EST from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <177708.870401.CPH@AI.AI.MIT.EDU>
Date: Tue, 31 Mar 87 22:13:26 EST
From: Jonathan A Rees <JAR at AI.AI.MIT.EDU>
I would strongly oppose the Common Lisp multiple value semantics. I
find it to be very distasteful. If this means that the language has no
multiple values primitively, and I have to implement semantics #1 myself
using lists or closures or whatever, that's fine with me.
If I have many sympathizers then I'd say it appears that we're
as deadlocked as we were last time this came up...
I think that I agree with JAR... I've just got back from vacation and
have not yet read all the mail on this (at 1200 baud, I'll wait for
work tomorrow!), but I am very disturbed by the direction this is
taking. I don't see a need for a complicated semantics! I'll reply
more fully later when I've had a chance to read all of this.
∂01-Apr-87 2333 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU multiple return values (LONG)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Apr 87 23:32:48 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 2 Apr 87 02:20:53 EST
Received: by GENEVA.AI.MIT.EDU; Wed, 1 Apr 87 22:53:32 est
Date: Wed, 1 Apr 87 22:53:32 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8704020353.AA11729@geneva>
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, Bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: David Bartley's message of Tue, 31 Mar 87 18:25:03 cst <8704010025.AA08042@home>
Subject: multiple return values (LONG)
*** Note: this is a relatively long message. ***
(1) I agree with ALAN and Jinx that it seems pretty useless to specify
a multiple value capability and not go beyond Will's alternative #1.
Since I intend to implement Common Lisp on top of Scheme, I will want
to extend the essential capability anyway. (Are ALAN and Jinx arguing
for #2 or #3?)
I like #2. More about this below.
(2) In his rationale, Will said "The Common Lisp position would say
that when zero values are returned to a continuation that is expecting
one value, then the symbol NIL is passed to the continuation." I
think we could specify this to be "the false value" or "the empty
list" and remain compatible with Common Lisp without having to make
the symbol NIL noteworthy in Scheme.
I don't like arbitrary values created. Again, more on this below.
(3) Will's proposal does not mention CALL-WITH-CURRENT-CONTINUATION.
It seems that a continuation object should accept an arbitrary number
of arguments if we take alternative #2 or #3. If so, we could define
(RETURN-VALUES A B) to be the same as (CALL/CC (LAMBDA (K) (K A B))).
No and yes, respectively. Again, see below.
(4) It seems to me that the hairiest part of the multiple value
"feature" in Common Lisp is MULTIPLE-VALUE-PROG1. Something like this
is needed, at least "behind the scenes", if we expect DYNAMIC-WIND
(etc.) to pass through multiple values. We could express
(MULTIPLE-VALUE-PROG1 A B ...) as
(receive-values A (lambda L B ... (apply return-values L))) ,
but that is pretty expensive. Is this common enough to require
standardization so implementors could work on more efficient
mechanisms?
I think it is worth thinking about, but given that the above is
sufficient, I don't think there is a need to standardize.
(5) JAR finds the proposed feature "to be pretty unuseable unless
there is some syntactically sugared way to use RECEIVE-VALUES." If
this is true, I think we must agree on what sugar to add. What's the
point of standardizing on something that is too cryptic to be used by
anyone?
I like T's RECEIVE, which I understand to be defined as
(receive <formals> <m-v-expression> . <body>)
==> (receive-values (lambda () <m-v-expression>)
(lambda <formals> . body>))
The key for me is that <formals> is a complete lambda list, possibly
containing "optional" and "rest" arguments, and is not just a list of
"required" identifiers. This seems more flexible than Common Lisp's
MULTIPLE-VALUE-BIND.
If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
but I would prefer something like MULTIPLE-VALUE-LET.
What about MULTIPLE-VALUE-BIND? The syntax is not like LET at all,
and it really is similar to the CL construct.
(6) Let's get down to brass tacks and argue about names! I'm bothered
by the "return" in RETURN-VALUES. As Will pointed out, the name
RETURN would be confusing to refugees from other Lisps. However,
RETURN-VALUES still seems to imply an exit from the calling procedure.
A user might ask whether the procedure
(LAMBDA (A B C) (+ A (RETURN-VALUES B) C))
returns the sum of A, B, and C or just B? I think we all intend for
RETURN-VALUES to "return" to its caller (the middle of the body), not
to that procedure's caller. I suggest renaming RETURN-VALUES to be
MULTIPLE-VALUES.
Likewise, the "receive" in RECEIVE-VALUES seems strange; I would
expect the complementary routine to be SEND-VALUES. How about
CALL-WITH-MULTIPLE-VALUES (call/mv?) by analogy with CALL-WITH-
CURRENT-CONTINUATION (call/cc)? (I'm not sure if I'm joking!)
I don't care much about the names of procedures, but I agree with GLS.
What's wrong with VALUES? Another possibility for RECEIVE-VALUES is
MULTIPLE-VALUE-COMPOSE, or even, CALL-EXPECTING-MULTIPLE-VALUES.
------------------------------------------------------------------------------
Well, here is my argument for proposal #2:
I think that there is a very important symmetry between procedure
invocation and continuation invocation. Indeed, if the code is CPS
converted, they become the same thing.
At apply time there is strict number of arguments checking, although
procedures, through optional or rest arguments, may allow a range of
numbers of arguments. I think it is important to be consistent here
and make continuation invocation be the same. Thus when an explicit
continuation is provided (as in the case of RECEIVE-VALUES), the
number of arguments (values) should be checked just as strictly.
Thus, I think that both
(receive-values (lambda () (values 1 2 3))
(lambda (a b) ...))
(receive-values (lambda () (values 1))
(lambda (a b) ...))
should be in error. The CL semantics can easily be implemented on top
of this by making the actual procedure passed to RECEIVE-VALUES accept
any number of arguments, and then initialize the ones not provided
with #f. Implementations can even be more lax since being in error
does not mean that one is signalled.
Now, wait a minute... This seems like an argument for #1, right?
Well, the difference is that there are (as far as I can tell) no
implicit procedures, but there certainly are implicit continuations,
and the behavior can be different.
The rule is as follows: an implicit continuation may be called with
MORE values than it expects, and these extra values are ignored. Thus
returning zero values to a continuation that expects one should be an
error (as opposed to creating a #f), but returning 2 should be valid.
This makes all the cases that I'm interested in work, yet allows the
error checking when multiple values are explicitely asked for.
Thus, assuming that QUOTIENT returns 2 values,
(let ((x (quotient (fact 100) (expt 2 23))))
...)
should work, but
(receive-values (lambda () (quotient (fact 100) (expt 2 23)))
(lambda (x) ...))
should be in error.
In case you are wondering, the example with the implicit continuation
is equivalent to
(receive-values (lambda () (quotient (fact 100) (expt 2 23)))
(lambda (x . ignore) ...))
As far as continuation objects obtained with CWCC are concerned, they
should accept multiple arguments if the corresponding continuation
accepted multiple values, thus
(receive-values (lambda ()
(cwcc (lambda (here)
(here 2 3))))
(lambda (x y)
(list x y)))
should return (2 3),
(receive-values (lambda ()
(cwcc (lambda (here)
(here 2 3))))
(lambda (x)
x))
should be in error, and
(let ((x (cwcc (lambda (here)
(here 2 3)))))
x)
should return 2.
Thus the number of arguments that continuations expect is not
arbitrary, but it is the case that
(return a b c)
is equivalent to
(cwcc (lambda (k) (k a b c)))
Having said all this, I'll also say that I'm afraid that we will not
be able to standardize. JAR feels relatively strongly about proposal
#1, and I think that other people do also. I feel relatively strongly
agains standardizing on the CL standard, since I don't believe in the
random NILs (or #Fs) being created on demand, so I'm therefore opposed
to #3, and I would not be surprised if other people had their own pet
theories.
∂02-Apr-87 0714 @MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA More bum code
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Apr 87 07:14:04 PST
Received: from nrl-aic.ARPA (TCP 3200200010) by MC.LCS.MIT.EDU 2 Apr 87 10:10:40 EST
Return-Path: <hoey@nrl-aic.ARPA>
Received: Thu, 2 Apr 87 10:09:10 est by nrl-aic.ARPA id AA10377
Date: 2 Apr 1987 09:53:40 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: More bum code
To: scheme@mc.lcs.mit.edu
Message-Id: <544373621/hoey@nrl-aic>
It seems a shame to change the names in the code without improving the
algorithm. So I bummed out a quarter of the multiplications and a
seventh of the additions, and dyked out the useless clause. Sorry it's
so late....
(defun f(| |)
(labels ((|| (| |)
(cond ((zerop | |) (values 1 0))
((evenp | |)
(multiple-value-bind (|(| |)|) (|| (/ | | 2))
(values (+ (* |(| |(|) (* |)| |)|))
(* (+ |(| (- |(| |)|)) |)|))))
(t
(multiple-value-bind (|(| |)|) (|| (/ (1- | |) 2))
(values (* |(| (+ |(| |)| |)|))
(+ (* |(| |(|) (* |)| |)|))))))))
(values (|| | |))))
Dan
∂02-Apr-87 1129 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values (LONG)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Apr 87 11:29:19 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 2 Apr 87 13:32:41 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac22936; 2 Apr 87 13:11 EST
Received: from ti-csl by RELAY.CS.NET id ac00800; 2 Apr 87 13:02 EST
Received: from home (home.ARPA) by tilde id AA18402; Thu, 2 Apr 87 10:31:31 cst
Received: by home id AA01664; Thu, 2 Apr 87 10:31:45 cst
Date: Thu, 2 Apr 87 10:31:45 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704021631.AA01664@home>
To: jinx%geneva.ai.mit.edu@RELAY.CS.NET
Cc: RRRS-Authors@MC.LCS.MIT.EDU, Bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: "Guillermo J. Rozas"'s message of Wed, 1 Apr 87 22:53:32 est
Subject: multiple return values (LONG)
> (1) I agree with ALAN and Jinx that it seems pretty useless to specify
> a multiple value capability and not go beyond Will's alternative #1.
> Since I intend to implement Common Lisp on top of Scheme, I will want
> to extend the essential capability anyway. (Are ALAN and Jinx arguing
> for #2 or #3?)
> I like #2. More about this below.
JINX makes a pretty good case for #2 and I'm persuaded. More below.
Scratch the term "useless"---standardizing on #1 at least gives us a
common basis for our various extensions.
> (4) It seems to me that the hairiest part of the multiple value
> "feature" in Common Lisp is MULTIPLE-VALUE-PROG1. Something like this
> [...]
>
> I think it is worth thinking about, but given that the above is
> sufficient, I don't think there is a need to standardize.
OK.
> (5) JAR finds the proposed feature "to be pretty unuseable unless
> there is some syntactically sugared way to use RECEIVE-VALUES." If
> this is true, I think we must agree on what sugar to add. What's the
> point of standardizing on something that is too cryptic to be used by
> anyone?
>
> I like T's RECEIVE [...]
>
> If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
> but I would prefer something like MULTIPLE-VALUE-LET.
>
> What about MULTIPLE-VALUE-BIND? The syntax is not like LET at all,
> and it really is similar to the CL construct.
Upon reflection, I wonder if there really is a problem. Does anyone
else feel that the proposal is "pretty unuseable unless there is some
syntactically sugared way to use RECEIVE-VALUES" or that it is "too
cryptic"? I don't.
> (6) Let's get down to brass tacks and argue about names! [...]
>
> I don't care much about the names of procedures, but I agree with GLS.
> What's wrong with VALUES? Another possibility for RECEIVE-VALUES is
> MULTIPLE-VALUE-COMPOSE, or even, CALL-EXPECTING-MULTIPLE-VALUES.
OK. I like VALUES or MULTIPLE-VALUES instead of RETURN-VALUES; both
avoid the imperative "return" that seems to imply some kind of throw.
I like WITH-VALUES or CALL-WITH-VALUES or CALL-WITH-MULTIPLE-VALUES
instead of RECEIVE-VALUES. The problem with "RECEIVE-" is that ones
first guess at the meaning of (RECEIVE-VALUES ...) might be that it
"receives" multiple values and returns them, rather than disposing of
them by a further call. The problem with "CALL-" is that it isn't
clear which of the two procedure arguments the "call" refers to. The
"CALL-" in CALL-WITH-MULTIPLE-VALUES refers to the second argument.
The "CALL-" in CALL-EXPECTING-MULTIPLE-VALUES refers to the first.
> Well, here is my argument for proposal #2:
>
> I think that there is a very important symmetry between procedure
> invocation and continuation invocation. Indeed, if the code is CPS
> converted, they become the same thing.
This symmetry gives us a rational basis for the whole idea, so I like
the idea of remaining consistent with it.
> [...]
> Now, wait a minute... This seems like an argument for #1, right?
>
> Well, the difference is that there are (as far as I can tell) no
> implicit procedures, but there certainly are implicit continuations,
> and the behavior can be different.
>
> The rule is as follows: an implicit continuation may be called with
> MORE values than it expects, and these extra values are ignored. Thus
> [...]
I like the idea of defining implicit continuations to look like
(LAMBDA (X . IGNORE) ...)).
> As far as continuation objects obtained with CWCC are concerned, they
> should accept multiple arguments if the corresponding continuation
> accepted multiple values, thus [...]
This is what I was trying to accomplish with my proposal. Thanks for
clarifying the issue.
> Having said all this, I'll also say that I'm afraid that we will not
> be able to standardize. JAR feels relatively strongly about proposal
> #1, and I think that other people do also. I feel relatively strongly
> agains standardizing on the CL standard, since I don't believe in the
> random NILs (or #Fs) being created on demand, so I'm therefore opposed
> to #3, and I would not be surprised if other people had their own pet
> theories.
Will's proposal was carefully worded so as to allow us to standardize
in #1, #2, or #3 and still allow those of us who want to to make
extensions compatible with Common Lisp. I think we should make an
effort to agree on names and syntax for multiple values, preferably
using alternative #2 (but I'll accept #1 if necessary), because it at
least gives us a common base for our extensions.
In summary: I like the names VALUES (or MULTIPLE-VALUES) and
WITH-VALUES (or CALL-WITH-VALUES or CALL-WITH-MULTIPLE-VALUES). I
like the syntax proposed by Will. I prefer alternative #2 but will
accept #1 rather than lose the chance to standardize. I see no need
for MULTIPLE-VALUE-PROG1 or syntactic sugar like MULTIPLE-VALUE-BIND.
Regards,
David Bartley
∂02-Apr-87 1138 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Apr 87 11:37:53 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 2 Apr 87 13:33:13 EST
Received: from relay2.cs.net by RELAY.CS.NET id ad22936; 2 Apr 87 13:11 EST
Received: from ti-csl by RELAY.CS.NET id ad00800; 2 Apr 87 13:03 EST
Received: from home (home.ARPA) by tilde id AA18814; Thu, 2 Apr 87 10:49:03 cst
Received: by home id AA02024; Thu, 2 Apr 87 10:49:21 cst
Date: Thu, 2 Apr 87 10:49:21 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704021649.AA02024@home>
To: CPH@MC.LCS.MIT.EDU
Cc: JAR@MC.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU,
Bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: Chris Hanson's message of Wed, 1 Apr 87 21:51:51 EST
Subject: multiple return values
> Date: Wed, 1 Apr 87 21:51:51 EST
> From: Chris Hanson <CPH@mc.lcs.mit.edu>
>
> Date: Tue, 31 Mar 87 22:13:26 EST
> From: Jonathan A Rees <JAR at AI.AI.MIT.EDU>
>
> I would strongly oppose the Common Lisp multiple value semantics. I
> find it to be very distasteful. If this means that the language has no
> multiple values primitively, and I have to implement semantics #1 myself
> using lists or closures or whatever, that's fine with me.
>
> If I have many sympathizers then I'd say it appears that we're
> as deadlocked as we were last time this came up...
>
> I think that I agree with JAR... I've just got back from vacation and
> have not yet read all the mail on this (at 1200 baud, I'll wait for
> work tomorrow!), but I am very disturbed by the direction this is
> taking. I don't see a need for a complicated semantics! I'll reply
> more fully later when I've had a chance to read all of this.
I hope we can at least agree on the names and the syntax for a
standard facility. I agree that we shouldn't STANDARDIZE on anything
complicated, but that we should have the basis for extensions in the
direction of Common Lisp for those of us that want it.
> Date: Sun, 29 Mar 87 02:29:12 EST
> From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
>
> I will confine myself to reminding you of what I said the last time this
> subject was raised: Any implementation of multiple-values that doesn't
> have the property that ordinary continuations (for example the continuation
> passed to F in (+ (F) 3)) will accept and ignore extra values has missed
> the point of multiple values.
This is why I prefer alternative #2.
> Let me try putting it another way: If you decide on a semantics for
> multiple values that has the property that a correct implementation can be
> written in straight R↑3RS Scheme, then what have you accomplished? You
> haven't given the users anything they couldn't have written for themselves.
> (Yes, perhaps you can arrange to implement it more efficiently, but since
> when has that been the the spirit of the language?)
I would prefer this to no agreement at all. Can we avoid deadlock?
Regards,
David Bartley
∂03-Apr-87 1043 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 10:43:29 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 3 Apr 87 13:39:18 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa04453; 3 Apr 87 10:21 EST
Received: from ti-csl by RELAY.CS.NET id aj00816; 3 Apr 87 11:18 EST
Received: from home (home.ARPA) by tilde id AA19574; Fri, 3 Apr 87 09:55:04 cst
Received: by home id AA16369; Fri, 3 Apr 87 09:55:18 cst
Date: Fri, 3 Apr 87 09:55:18 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704031555.AA16369@home>
To: RRRS-Authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: optional arguments
And now for something completely different...
I believe it is time to consider adopting a simple extension to the
syntax for formal argument lists in Lambda expressions to include
optionally supplied arguments. Here's a proposal that seems to codify
the essentials of existing practice in at least a few implementations.
MOTIVATION
It was successfully argued at Brandeis that "rest" arguments suffice
for the definition of procedures that take arbitrary numbers of actual
arguments. Although this is certainly true, it has at least three
disadvantages. First, a direct implementation of optional arguments
could be more efficient by avoiding the extra consing needed for a
fully general rest argument. Second, error checking is more sporadic
when programmers supply their own mechanisms. It is cumbersome to
specify a finite number of optional arguments given the open ended
nature of rest args. Third, providing for optional arguments is so
common a paradigm that readability and portability would be enhanced
if we could agree on a standard mechanism.
ISSUES
I see several issues to be resolved:
(1) An extended syntax allowing optional arguments must be compatible
with the existing standard for Scheme. It is also desirable that it
not conflict with existing extensions for optional arguments and
existing or proposed extensions in other directions. (For example,
anyone favoring an extension of formal parameter lists to allow
destructuring of arguments has few available syntactic alternatives.)
(2) It must be decided whether a full or barebones facility should be
standardized. If the latter, the extended syntax for optionals should
also allow for further extension.
(3) It should be possible to determine at run time whether a
particular optional argument was supplied by the caller. One way to
do this is to supply a count of the number of arguments passed to the
called procedure. Another way is to allow the called procedure to ask
whether a given argument were supplied.
(4) It is useful to allow specification of values to be bound to
optional arguments when actual parameters are not supplied by the
caller. This facility is convenient but can be built upon the ability
to determine whether a value had been supplied by the caller. It also
has subtle problems, such as the exact lexical environment to be used
in evaluating the initializing expression.
INFORMAL DESCRIPTION
I suggest that we adopt the following mechanism for optional arguments
as a non-essential feature. It is basically the approach used
internally here at TI based on our understanding of a similar facility
in MIT Scheme. However, it includes modifications suggested by Will
Clinger.
-- Formal argument lists containing optional arguments are
distinguished by the presence of the keyword #!OPTIONAL, which acts
like &OPTIONAL in Common Lisp. (I could write out an informal
description here based on Steele's book, but there's no need to yet.)
-- Formal variables which do not receive values are said to be "bound"
but not "assigned". It is an error to reference an unassigned
variable. Ideally, an implementation would trap on such references.
However, it may choose to mark unassigned variables with a
distinguished value (or values), such as the token #!UNASSIGNED.
(The R↑3RS formal semantics assumes that all variables are bound
in the initial environment, but this is an area where implementations
differ. Some implementations may extend the syntax for DEFINE so
(DEFINE X) creates a binding for X but leaves it unassigned.)
The special form (ASSIGNED? <id>) returns #T iff the variable named by
<id> has been assigned a value (e.g., from the calling procedure's
actual argument list). The value of (ASSIGNED? X) is unspecified if X
is unbound. For example the value of (LETREC ((X (ASSIGNED? X))) X)
is not clear, just as the value of (LETREC ((X X)) X) is unspecified.
-- A "rest" argument is always assigned. If the list of actual
arguments is no longer than the number of required and optional
formals, the rest argument receives the value ().
-- Optional arguments may be given default values by first testing
them with ASSIGNED? as in the following example:
(lambda (a #!optional b)
(let ((b (if (assigned? b) b (+ a 42))))
...))
or
(lambda (a #!optional b)
(when (not (assigned? b)) (set! b (+ a 42)))
...)
This makes clear the environment that the initialization expression
for B is to be evaluated in.
FORMAL SEMANTICS
Will Clinger has kindly volunteered the following formal semantics for
ASSIGNED? and LAMBDA. The "\" character should be read as Greek lambda.
E [[ (assigned? I) ]]
= \ r k . hold (lookup r I)
(single (\ e . e = undefined --> false, true))
E [[ (lambda (I0* #!optional I1*) C* E0 ]]
= \ r k . \ s .
new s \in L -->
send (< new s | L,
\ e* k' .
(# e* >= # I0*) & (# e* <= (# I0* + # I1*)) -->
tievals
(\ a* . (\ r' . C [[ C* ]] r' (E [[ E0 ]] r' k'))
(extends r (I0* concat I1*) a*))
(e* concat (seq (# I0* + # I1* - # e*) undefined)),
wrong "wrong number of arguments">
in E)
k
(update (new s | L) unspecified s),
wrong "out of memory" s
E [[ (lambda (I0* #!optional I1* . I) C* E0 ]]
= \ r k . \ s .
new s \in L -->
send (< new s | L,
\ e* k' .
# e* >= # I0* -->
tievalsrest
(\ a* . (\ r' . C [[ C* ]] r' (E [[ E0 ]] r' k'))
(extends r (I0* concat I1* concat <I>) a*))
((takefirst e* (# I0*))
concat (seq (# I0* + # I1* - # e*) undefined)
concat (dropfirst e* (# I0*)))
(# I0* + # I1*),
wrong "too few arguments">
in E)
k
(update (new s | L) unspecified s),
wrong "out of memory" s
where
seq = \ n x . n <= 0 --> <>, <x> concat (seq (n - 1) x)
DISCUSSION
I don't propose a syntactic extension for specifying default
initialization more conveniently because (1) the obvious syntax
would conflict with an extension for argument list destructuring;
(2) testing whether a variable had been supplied by the caller or from
evaluation of the default initialization expression becomes more
complicated; (3) the explicit mechanism given here seems quite
readable and convenient to me; and (4) I think it's important to make
explicit which environment the initialization form is evaluated in and
to allow variations.
I've mentioned destructuring several times because I have the
impression much of the opposition to optional arguments comes from the
desire to leave the way open for destructuring lambda lists. It seems
to me that the simple addition of the #!OPTIONAL keyword should not
seriously hinder destructuring, since it is unambiguous and can be
easily recognized.
I welcome all comments.
Regards,
David Bartley
∂03-Apr-87 1415 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Apr 87 14:15:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Apr 87 16:47:46 EST
Date: Fri, 3 Apr 87 16:47:09 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: optional arguments
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 3 Apr 87 09:55:18 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <178851.870403.JAR@AI.AI.MIT.EDU>
I have a different optional arguments proposal, which people should keep
in mind as an alternative:
Don't make any change to the syntax of LAMBDA. Instead, just introduce
a new special form for taking apart rest arguments. Example:
(LAMBDA (A B . R)
(OPTIONAL ((X 1) (Y (+ X 5))) R
-body-))
would be analogous to the Comon Lisp lambda-expression
(LAMBDA (A B &OPTIONAL (X 1) (Y (+ X 5)))
-body-),
and
(LAMBDA (A B . R)
(OPTIONAL ((X 1) (Y (+ X 5)) . R) R
-body-))
would be like
(LAMBDA (A B &OPTIONAL (X 1) (Y (+ X 5)) &REST R)
-body-),
I think this gets most of the benefits you want without making LAMBDA
hairy. It provides parameter list destructuring and error checking in a
nice orthogonal way, and is only a little bit more verbose than hairy
LAMBDA-isms. And it can be implemented in straightforwardly as a macro.
I have had this in the back of my mind since about 1981. I never got
around to installing it in T, but I should have. I have implemented and
used it on several occasions (e.g. for implementing R↑2 Scheme in T),
and was fairly happy with it.
Effiency note: the mythical "sufficiently clever compiler" can avoid
consing the rest-list if there's only the one reference to R. I think
this would be a very straightforward transformation.
Jonathan
∂04-Apr-87 2028 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA TIPC windows
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Apr 87 20:28:05 PST
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 4 Apr 87 23:26:54 EST
Date: Sat 4 Apr 87 21:24:08-MST
From: Raul Machuca <RMACHUCA@SIMTEL20.ARPA>
Subject: TIPC windows
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12291980245.17.RMACHUCA@SIMTEL20.ARPA>
An application of PC Scheme that I am working on requires that
a large amount of asc2 data be displayed. One large monitor available
is the Amdek 1280 which displays 160 columns by 50 rows. Does
anyone have any experience using PC Scheme with this or any other
monitor that can display as much or more data? Do the PC
window programs work without modification?
-------
∂04-Apr-87 2330 @MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu scheme in prolog
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Apr 87 23:30:43 PST
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 5 Apr 87 01:47:17 EST
Received: by linc.cis.upenn.edu
id AA08740; Sun, 5 Apr 87 01:42:37 EST
Date: Sun, 5 Apr 87 01:42:37 EST
From: tim@linc.cis.upenn.edu (Tim Finin)
Posted-Date: Sun, 5 Apr 87 01:42:37 EST
Message-Id: <8704050642.AA08740@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu, prolog-request@sushi.stanford.edu
Subject: scheme in prolog
A while back there was a discussion on the SCHEME newsgroup concerning
implementations of logic programming languages in Scheme. David Moon
wondered if anyone had implemented Prolog in Scheme. His query
stimulated me to give it a try. I wrote two interpreters for a subset
of Scheme, one with and one without continuation semantics. I'm happy
to share these with anyone who is interested.
What I found most interesting about the exercise has more to do with
Prolog than with Scheme - It is very difficult to implement an
efficient interpreter for a language which has side-effects in prolog.
I could not find a way to represent environments which had what I
consider to be the neccessary features:
1 - unreferenced enviroments should be automatically GCed.
2 - looking up the value of a variable should be cheap and,
in particular, should not depend on the the number of values it
has received in the past.
3 - variable assignment should be cheap and, in particular should not
require copying abritrary portions of an environment.
4 - The interpreter should not require an infinite stack nor
should the host prolog be required to detect and optimize
for tail recursion.
I basically considered two alternatives for representing the environment:
o represent an environment as a term which contains a sequence of
variable-name/variable-value pairs. This achieves (1) in most prologs
but must give up on either (2) or (3).
o represent an environment as a set of assertions in the clausal
database of the form: bound(Symbol,Value,EnvironmentID). This wins on
(2) and (3) but loses on (1).
This makes me think that a side-effect predicate like RPLACARG
(discussed in PROLOG-DIGEST about a year ago) is not such a bad idea.
It also reinforces the notion that Lisp is either a (i) more general
or (ii) lower level language than Prolog, depending, of course, on
your point of view.
Tim
∂06-Apr-87 0927 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Need consultant
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 09:27:36 PDT
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 6 Apr 87 12:22:19 EDT
Date: Mon, 6 Apr 87 10:19:25 MDT
From: Raul Machuca <RMACHUCA@SIMTEL20.ARPA>
Subject: Need consultant
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12292372602.16.RMACHUCA@SIMTEL20.ARPA>
We are working on a small prototype for a range scheduling system using
TIPC Scheme. We need the help of a faculty member familiar with
Scheme and AI concepts. The total time would be 90 days not necessarily
continuous but taking place within 6 months from the date the
contract is initiated. Starting date would be about the end of June.
The work would be done at your installation and graduate students
could be included.
If anyone is interested please let me know and I will send
you more information.
PS. Rate of pay is computed from 9 month salary.
-------
∂06-Apr-87 1044 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 10:44:18 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Apr 87 12:58:28 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aj14655; 6 Apr 87 12:36 EDT
Received: from ti-csl by RELAY.CS.NET id at06040; 6 Apr 87 12:35 AST
Received: from home (home.ARPA) by tilde id AA06696; Mon, 6 Apr 87 10:12:42 cst
Received: by home id AA23220; Mon, 6 Apr 87 11:13:06 cdt
Date: Mon, 6 Apr 87 11:13:06 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704061613.AA23220@home>
To: JAR@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET, RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Fri, 3 Apr 87 16:47:09 EST
Subject: optional arguments
> Date: Fri, 3 Apr 87 16:47:09 EST
> From: Jonathan A Rees <JAR@mc.lcs.mit.edu>
>
> I have a different optional arguments proposal, which people should keep
> in mind as an alternative:
>
> Don't make any change to the syntax of LAMBDA. Instead, just introduce
> a new special form for taking apart rest arguments. Example:
>
> (LAMBDA (A B . R)
> (OPTIONAL ((X 1) (Y (+ X 5))) R
> -body-))
This appears to be more of a destructuring form than one restricted to
defining optional arguments. Would you allow the (OPTIONAL ...) to
appear anywhere or just directly inside a LAMBDA as its body? Must
the second "argument" (R) be the name of a "rest" arg?
> [...]
> I think this gets most of the benefits you want without making LAMBDA
> hairy. It provides parameter list destructuring and error checking in a
> nice orthogonal way, and is only a little bit more verbose than hairy
> LAMBDA-isms. And it can be implemented in straightforwardly as a macro.
It apparently only allows destructuring at the top level of a list.
My suggestion can also be implemented straightforwardly as a macro.
> [...]
> Effiency note: the mythical "sufficiently clever compiler" can avoid
> consing the rest-list if there's only the one reference to R. I think
> this would be a very straightforward transformation.
I like this notation, but not the idea that its efficiency depends on
the cleverness of the compiler, since that inhibits using such
features in portable code. It would require a compiler to determine
whether the declared rest arg R were otherwise referenced from within
the body of the procedure in order to approach the efficiency a dumb
compiler could get with my approach.
On the other hand, if one customarily wrote
(LAMBDA (A B . R1)
(OPTIONAL ((X 1) (Y (+ X 5)) . R2) R1
-body-))
with the variables R1 and R2 having the same name, then a preprocessor
for LAMBDA could "look ahead" for an OPTIONAL form in its body and
determine that R1 could possibly have but one use. This would be a
fairly localized test. (But is it proper for one macro to assume that
another macro has not been redefined?)
Regards,
David Bartley
∂06-Apr-87 1232 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU Optionals
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 12:32:09 PDT
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 6 Apr 87 14:48:44 EDT
Date: 06 Apr 87 1144 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Optionals
To: rrrs-authors@MC.LCS.MIT.EDU
Jonathan proposes:
(LAMBDA (A B . R)
(OPTIONAL ((X 1) (Y (+ X 5))) R
-body-))
As one of the sad, major forces behind Common Lisp, I'm glad to
see that Common Lisp doesn't have a monopoly on bad taste.
The only palletable line in this code reads:
-body-))
-rpg-
∂06-Apr-87 1241 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU current membership
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 12:41:16 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Apr 87 14:52:52 EDT
Date: Mon, 6 Apr 87 14:20:42 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: current membership
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <179905.870406.JAR@AI.AI.MIT.EDU>
Enclosed is the current membership of RRRS-AUTHORS. Sometime in
February or March I added two members of the Eulisp committee, Julian
Padget and Andy Norman. Most list members seem to be observers rather
than participants, which I take to be a sign that we're doing something
right.
We could use a new name for the mailing list, since "RRRS-authors"
hasn't been appropriate since the R↑2 report came out (a year and a half
ago). Maybe something like "Scheme-authors" or "Scheme-designers" or
"Scheme-report-authors". "R↑NRS-authors" isn't pronounceable.
- Jonathan
;;; MIT:
(file [LSPMAI;RRRS MAIL]) ;Local archive file
SCHEME-RRRS@OZ.AI.MIT.Edu ;Oz people
alco@VX.LCS.MIT.Edu ;Dave Alcocer
LS.SRB@Deep-Thought.MIT.Edu ;Steve Balzac
ALAN ;Alan Bawden
Ziggy@VX.LCS.MIT.Edu ;Michael Blair
RHH ;Bert Halstead
CPH ;Chris Hanson
NICK ;Nick Papadakis
JAR ;?
;;; Non-MIT:
jleech@ADS.ARPA ;ADS / Jay Leech
william@ADS.ARPA ; William Bricken
andy@ADS.ARPA ; Andy Cromarty
padget%uk.ac.bath.ux63@CS.UCL.AC.UK ;Bath / Julian Padget
HP-SCHEME@HPLABS.HP.Com ;HP / Henry Wu
ange%hplb.csnet@Relay.CS.Net ; Andy Norman
dyb%indiana@Relay.CS.Net ;Indiana/ Kent Dybvig
scheme-rrrs%indiana@Relay.CS.Net ;Indiana / ...
linus!ramsdell@Mitre-Bedford.ARPA ;MITRE / John Ramsdell
wand%corwin.ccs.northeastern.edu@Relay.CS.Net ;Northeastern / Mitch Wand
("#COMSCH.MSG[SCH,LSP]" @SAIL.Stanford.Edu) ;Stanford / file archive
ANDY@Sushi.Stanford.Edu ; Andy Freeman
RPG@SAIL.Stanford.Edu ; Dick Gabriel
Daniel ; Daniel Weise
RDZ ; Ramin Zabih
KMP ;Symbolics / Kent Pitman
adams%tekchips%tektronix@Relay.CS.Net ;Tektronix / Norman Adams
willc%tekchips%tektronix@Relay.CS.Net ; Will Clinger
rrrs-authors-incoming%TI-CSL@Relay.CS.Net ;TI / ...
GLS ;TMI / Guy Steele
patel@CS.UCLA.EDU ;UCLA / Dorab Patel
Hudak@Yale.ARPA ;Yale / Paul Hudak
Kelsey@Yale.ARPA ; Richard Kelsey
Kranz@Yale.ARPA ; David Kranz
Philbin-Jim@Yale.ARPA ; Jim Philbin
∂06-Apr-87 1319 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 13:19:38 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Apr 87 15:38:24 EDT
Date: Mon, 6 Apr 87 15:03:55 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: optional arguments
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 6 Apr 87 11:13:06 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <179940.870406.JAR@AI.AI.MIT.EDU>
Date: Mon, 6 Apr 87 11:13:06 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
This appears to be more of a destructuring form than one restricted to
defining optional arguments. Would you allow the (OPTIONAL ...) to
appear anywhere or just directly inside a LAMBDA as its body? Must
the second "argument" (R) be the name of a "rest" arg?
It can appear anywhere, and R can be any list. In other words, it's
the obvious macro, nothing more or less, semantically at least.
(The syntax "(OPTIONAL r ((var default) ...) body)" is probably better than
"(OPTIONAL ((var default) ...) r body)".)
It apparently only allows destructuring at the top level of a list.
My use of the term "destructuring" was a little too free then. Your
proposal also only allows it at top level, yes? Mixing default
values with full destructuring would be awful...
My suggestion can also be implemented straightforwardly as a macro.
Into what would it expand? You would still need either (1) a
PRIMITIVE-LAMBDA expression type, (2) an incompatible LAMBDA in some
distinct syntax table, or (3) the ability to overload macros. I think
there are problems with all three approaches. I prefer the orthogonal
approach of giving distinct features distinct names.
(Well... why does LAMBDA support rest-arguments, you ask? And why does
the language have "named LET"? I remember that Dan Friedman argued
against overloading LAMBDA for n-ary procedures back in '84, for exactly
this reason. I vacillate between agreeing with him and not. I argued
against named LET, but other people said you can view unnamed LET as a
special case of named LET, therefore the overloading is OK, and
desirable because you want to minimize the number of reserved words at
almost any cost. They shouted more loudly, and won.)
I like this notation, but not the idea that its efficiency depends on
the cleverness of the compiler, since that inhibits using such
features in portable code. It would require a compiler to determine
whether the declared rest arg R were otherwise referenced from within
the body of the procedure in order to approach the efficiency a dumb
compiler could get with my approach.
As Alan Bawden asked, since when were efficiency considerations so
important in language design? However, I don't think OPTIONAL need be
inefficient. Sure, it needs a two-pass compiler, but given that,
detecting the situation is trivial, much easier than detecting whether a
LETREC is a loop or that an environment may be allocated on a stack or
in registers. I assume the PC Scheme compiler and most others are
already two-pass, so I don't think this is a big deal. I don't know of
anyone who is using a pure interpreter these days.
If you're concerned about the speed of portable code, I'd say this is
probably the least of your worries. Other kinds of unnecessary consing,
especially of environments, procedures, and continuations, will dominate
this kind if the compiler is only one-pass.
(But is it proper for one macro to assume that
another macro has not been redefined?)
The answer is no, if syntactic keywords are scoped at all (and they
ought to be) then it is definitely not proper, but that doesn't mean a
macro has no hope of examining subforms. Did you read my macro
proposal? You could deal with situations like this if there was some
way to examine preprocessed expressions. The ->CORE procedure in the
proposal would suffice if OPTIONAL-expressions were in its range.
But I think it would be better to put it in the compiler, especially
since the case without the rest-argument is the important one for error
checking. You don't want people to forego the error checking -- one
of the main reasons having an explicit optional-argument feature comes
up -- just in order to reduce consing, and you don't want macros doing
optimizations in any case.
Jonathan.
∂06-Apr-87 1404 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU Taste
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:04:17 PDT
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 6 Apr 87 16:40:54 EDT
Date: 06 Apr 87 1334 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Taste
To: rrrs-authors@MC.LCS.MIT.EDU
Sorry, I mispelled ``palatable.''
I was under the impression that people on this list were not required
to explain why they thought something was in bad taste nor provide
alternatives. Jonathan wrote recently:
``I would strongly oppose the Common Lisp multiple value semantics. I
find it to be very distasteful.''
There was no further discussion of reasons or alternatives.
The line:
(LAMBDA (X Y Z . R) ...)
puts a lot semantic emphasis on the character `.'. It relies on a joke
involving the (coincidental) underling data structure that is sometimes
used to represent expressions. The line that starts
(OPTIONALS ...)
is simply a recovery from the language design error reflected on the
previous line.
I think that if we (may I be so bold?) are considering a richer
parameter-passing language, we should carefully consider and decide what
information we wish to have expressed regarding how variables will be
bound upon function entry. Possibly we want to define a language for
passing structures of various types which will then be decomposed and bound
upon function entry - this would be much like alien structure languages
in some languages.
The advantage of Common Lisp &-markers is that it is relatively clear that
something funny is going on, and a programmer doesn't have to rely on a
human reader to always see the tiny `.'.
If the strategy is to be able to pass an arbitrary number of arguments,
then a syntax that binds one variable to all of them following by a
pretty destructuring bind of some sort is much better than a
syntax that mixes required with &rest (as Jonathan suggested).
-rpg-
∂06-Apr-87 1431 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Optionals
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:30:59 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Apr 87 17:09:14 EDT
Date: Mon, 6 Apr 87 16:10:23 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Optionals
To: RPG@SAIL.STANFORD.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 06 Apr 87 1144 PDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Message-ID: <179987.870406.JAR@AI.AI.MIT.EDU>
Date: 06 Apr 87 1144 PDT
From: Dick Gabriel <RPG at SAIL.STANFORD.EDU>
As one of the sad, major forces behind Common Lisp, I'm glad to
see that Common Lisp doesn't have a monopoly on bad taste.
The only palletable line in this code reads:
-body-))
Don't be elliptical. Please elaborate, explain why tasteless, propose
alternative, and explain to me whether or not the following is legal
Common Lisp and what it returns:
((lambda (&rest foo &key ((foo foo) 3 foo)) foo)
:foo 5 :foo 8 :allow-other-keys nil :allow-other-keys 13)
PS I don't find "palletable" in my dictionary. I do find
pallet n. 1. a wooden flat-bladed instrument 2. a lever or surface in a
timepiece that receives an impulse fom the escapement wheel and imparts
motion to a balance or pendulum 3. a portable platform for handling,
storing or moving materials and packages (as in warehouses, factories,
or vehicles)
palletize vt. to place on, transport, or store by means of pallets
Perhaps you mean "palletizable"?
J.
∂07-Apr-87 0542 @MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 05:42:06 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 7 Apr 87 08:44:44 EDT
Full-Name:
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
id AA08662; Tue, 7 Apr 87 07:44:26 est
Date: Tue, 7 Apr 87 07:44:26 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 7 Apr 87 07:44:26 est
Message-Id: <8704071244.AA08662@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: macros
Multiple returns and optional arguments are interesting
to discuss, but everybody uses macros. It seems to me
that an agreement on macros is much more important. JAR's
proposal appears to satisfy most needs for macros. At first
I worried about the added complexity of specifying macros, but
now I think that its good to discourage its use by making it
hairy. Do I understand the lack of discussion to mean that
there are no objections to JAR's proposal? If so, let's adopt
it and move on.
John
∂07-Apr-87 0825 @MC.LCS.MIT.EDU:gls@Think.COM Optionals
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 08:25:21 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 7 Apr 87 11:07:05 EDT
Received: from godot.think.com by Think.COM; Tue, 7 Apr 87 11:02:33 EST
Received: from thorlac by godot.think.com via CHAOS; Tue, 7 Apr 87 11:02:22 EST
Date: Tue, 7 Apr 87 10:03 EST
From: Guy Steele <gls@Think.COM>
Subject: Optionals
To: JAR@ai.ai.mit.edu, RPG@sail.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <179987.870406.JAR@AI.AI.MIT.EDU>
Message-Id: <870407100325.3.GLS@THORLAC.THINK.COM>
Date: Mon, 6 Apr 87 16:10:23 EDT
From: Jonathan A Rees <JAR@ai.ai.mit.edu>
... Please ...
explain to me whether or not the following is legal
Common Lisp and what it returns:
((lambda (&rest foo &key ((foo foo) 3 foo)) foo)
:foo 5 :foo 8 :allow-other-keys nil :allow-other-keys 13)
RPG did not respond to this point in his reply, so I will take
the liberty here:
There are three distinct areas that you are muddling here. One is the
question of whether Common Lisp specifies the meaning of this
expression precisely and unambiguously. The second is whether the
facilities of the language can be abused to produce unreadable code.
The third is, if the scond is true, does the language design encourage
such abuse.
The existing Common Lisp specification unfortunately is not entirely
precise unambiguous. For example, it does not address the question of
whether there may be two parameters of the same name in a single
lambda-list. (The latest sentiment I have observed is that it should be
an error.) On the other hand, the first keyword argument FOO will be
bound to 5, not 8; that is specified on page 62. You have raised an
interesting point concerning :allow-other-keys; the wording of the
second bulleted point on page 63 is unfortunately inconsistent with the
statement on page 62 about taking the leftmost pair.
I think we have already seen in the last week how easy it is to produce
unreadable code, and I will not belabor the point here beyond the simple
assertion that it simply IS NOT A VALID ARGUMENT to assert that a language
is bad because it is possible to write programs that are difficult to
understand.
Now, if you had argued that the design of Common Lisp actively encourages
such abuse, rather than merely permitting it, I would be sympathetic.
∂07-Apr-87 1337 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 13:37:45 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Apr 87 16:35:13 EDT
Date: Tue, 7 Apr 87 16:33:22 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: macros
To: ramsdell%faron@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 7 Apr 87 07:44:26 est from John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
Message-ID: <180699.870407.JAR@AI.AI.MIT.EDU>
Date: Tue, 7 Apr 87 07:44:26 est
From: John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
Multiple returns and optional arguments are interesting
to discuss, but everybody uses macros. It seems to me
that an agreement on macros is much more important. JAR's
proposal appears to satisfy most needs for macros. At first
I worried about the added complexity of specifying macros, but
now I think that its good to discourage its use by making it
hairy. Do I understand the lack of discussion to mean that
there are no objections to JAR's proposal? If so, let's adopt
it and move on.
I believe there are serious objections from Gene Kohlbecker and/or Dan
Friedman, at least. Gene is off the net, but I'll get in touch with
him. Perhaps Dan will overcome his shyness and let us know why an
"unhygienic" least common denominator is the wrong thing.
Jonathan
∂07-Apr-87 1710 @MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU scheme in prolog
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 17:10:13 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 APR 87 20:08:11 EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 36410; 7 Apr 87 20:07:38-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 62778; Tue 7-Apr-87 19:38:06-EST
Date: Tue, 7 Apr 87 19:38 est
From: mike%acorn@oak.lcs.mit.edu
To: tim@linc.cis.upenn.edu (Tim Finin)
Reply-to: mike%acorn@oak.lcs.mit.edu
Subject: scheme in prolog
Cc: scheme@mc.lcs.mit.edu, prolog-request@sushi.stanford.edu
Date: Sun, 5 Apr 87 01:42:37 EST
From: tim@linc.cis.upenn.edu (Tim Finin)
What I found most interesting about the exercise has more to do with
Prolog than with Scheme - It is very difficult to implement an
efficient interpreter for a language which has side-effects in prolog.
No more difficult, I think, than interpreting a language with
side-effects in a language without side effects. Consider writing a
scheme interpreter in Pure Scheme or in ML (not using the side
effects). In either case, the technique you end up using makes the
interpreter look alot like a denotational semantics (Pure Scheme or ML
case) or a Plotkin-Style operational semantics (Prolog Case).
I basically considered two alternatives for representing the environment:
o represent an environment as a term which contains a sequence of
variable-name/variable-value pairs. This achieves (1) in most prologs
but must give up on either (2) or (3).
o represent an environment as a set of assertions in the clausal
database of the form: bound(Symbol,Value,EnvironmentID). This wins on
(2) and (3) but loses on (1).
I think you should build an abstract data type for this rather than
expecting terms and pattern matching or the interpreter to do it for you.
The best you'll be able to do in prolog is a tree like representation,
requiring logarithmic access time and update time (as well as logarithmic
space for copying on updates.)
lookup (X, Env, Value) :- ....given X find value V in environment E.
update (X, V, Env1, Env2) :- update X to value V in environment Env1 to get
environment Env2.
This makes me think that a side-effect predicate like RPLACARG
(discussed in PROLOG-DIGEST about a year ago) is not such a bad idea.
Yup. The difficulty is that it is hard to use side effects in a language
with automatic control structures. You basically can't get the level
of operational control you need, but the declarative model also breaks down.
In any case I'd say RPLACARG will be infinitely MORE useful than
assert and retract ever were. Consider for example the UPDATE predicate
above. This, written using RPLACARG would destructively update the environment
Env1 to make Env2, which is exactly what you need.
It also reinforces the notion that Lisp is either a (i) more general
or (ii) lower level language than Prolog, depending, of course, on
your point of view.
Both I'd say. Prolog is a very high level language, and is less expressive
than languages with side effects. What I mean by expressive here is not
the usual formal definition, since Prolog is clearly complete in that
all computable functions can be computed, but rather a pragmatic
view. Any language without side effects is restricted in that it
cannot describe changes of state over time without having representations
of those states separately.
Try writing code for hash-tables in prolog or pure scheme and you'll
see what I mean. Hashing (like most side effect oriented code) requires
side effects in its essence since it has to reason about whether buckets
in the table are in use "yet". They also lack any notion of EQ-ness
as in Lisp or Scheme for the same reason.
...mike beckerle
Gold Hill Computers
∂07-Apr-87 1944 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Taste
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 19:44:34 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Apr 87 21:19:09 EDT
Date: Tue, 7 Apr 87 21:17:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Taste
To: RPG@SAIL.STANFORD.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 06 Apr 87 1334 PDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Message-ID: <180826.870407.JAR@AI.AI.MIT.EDU>
Date: 06 Apr 87 1334 PDT
From: Dick Gabriel <RPG at SAIL.STANFORD.EDU>
I was under the impression that people on this list were not required
to explain why they thought something was in bad taste nor provide
alternatives. Jonathan wrote recently:
``I would strongly oppose the Common Lisp multiple value semantics. I
find it to be very distasteful.''
There was no further discussion of reasons or alternatives.
No one asked... if you care to know, it's because I think ignored
values, as well optional arguments for that matter, are a form of
overloading, and overloading is a kind of pun, and punning is to be
avoided where possible, since (in my opinion) it's likely to lead to
code that's buggy and/or unreadable and/or not well thought out.
Sometimes overloading is just what you want in order for your code to be
modular, but I haven't observed that in these situations. This is all
very vague, of course, which is why I waved my hands.
The line:
(LAMBDA (X Y Z . R) ...)
puts a lot semantic emphasis on the character `.'. It relies on a joke
involving the (coincidental) underling data structure that is sometimes
used to represent expressions.
I agree, this is a feature of dubious design. This probably ought to be
written (LAMBDA ARGS (... something which takes apart ARGS ...)).
Perhaps the n-ary version of LAMBDA ought to have a different name.
The line that starts
(OPTIONALS ...)
is simply a recovery from the language design error reflected on the
previous line.
I think that if we (may I be so bold?) are considering a richer
parameter-passing language, we should carefully consider and decide what
information we wish to have expressed regarding how variables will be
bound upon function entry. Possibly we want to define a language for
passing structures of various types which will then be decomposed and bound
upon function entry - this would be much like alien structure languages
in some languages.
The advantage of Common Lisp &-markers is that it is relatively clear that
something funny is going on, and a programmer doesn't have to rely on a
human reader to always see the tiny `.'.
I know of no instance where someone has failed to see the dot, or where
someone has been confused about its basic meaning... a bigger problem with
it than its small size is the fact that you can't write
(LAMBDA (. R) ...)
(which, by the way, is legal in T, and it does what you'd expect). &REST,
#!REST, &DOT, |.|, etc., it is true, do not suffer from this problem.
If the strategy is to be able to pass an arbitrary number of arguments,
then a syntax that binds one variable to all of them following by a
pretty destructuring bind of some sort is much better than a
syntax that mixes required with &rest (as Jonathan suggested).
I agree. In my experience, pattern-matching languages seem to have an
inevitable tendency to become baroque and disgusting. But let's not
stop looking for a decent one.
Thanks for explaining.
Jonathan...
∂08-Apr-87 0803 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU Concurrency in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 08:03:28 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 8 Apr 87 11:00:55 EDT
Date: 8 Apr 1987 10:56-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Concurrency in Scheme
From: VERACSD@A.ISI.EDU
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd.ck@A.ISI.EDU
Message-ID: <[A.ISI.EDU] 8-Apr-87 10:56:52.VERACSD>
I am in the process of writing a metacircular Lisp interpreter which
accommodates concurrent programming constructs (e.g. parbegin/parend's
and semaphores) and have recently come across *engines* in PC Scheme.
Engines seem like they offer much potential for this sort of thing,
however, they seem somewhat tricky. It is especially unclear to me
how to elegantly handle waits & signals for semaphores.
(There must be a better way than Ben-Ari's Pascal concurreny simulator.)
Any advice, pointers to sources, or code would be much appreciated.
Cris Kobryn
VERACSD.CK@A.ISI.EDU
∂08-Apr-87 0917 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 09:17:29 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 8 Apr 87 12:20:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from relay2.cs.net by RELAY.CS.NET id ai04077; 7 Apr 87 17:07 EDT
Received: from ti-csl by RELAY.CS.NET id ao16423; 7 Apr 87 17:05 AST
Received: from home (home.ARPA) by tilde id AA17230; Tue, 7 Apr 87 14:48:35 cst
Received: by home id AA18814; Tue, 7 Apr 87 15:48:56 cdt
Date: Tue, 7 Apr 87 15:48:56 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704072048.AA18814@home>
To: ramsdell%faron@mitre-bedford.ARPA
Cc: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
In-Reply-To: "John D. Ramsdell"'s message of Tue, 7 Apr 87 07:44:26 est
Subject: macros
> Date: Tue, 7 Apr 87 07:44:26 est
> From: "John D. Ramsdell" <ramsdell%faron@MITRE-BEDFORD.ARPA>
>
> Multiple returns and optional arguments are interesting
> to discuss, but everybody uses macros. It seems to me
> that an agreement on macros is much more important.
I agree that it is equally important, but harder to resolve.
> JAR's
> proposal appears to satisfy most needs for macros. At first
> I worried about the added complexity of specifying macros, but
> now I think that its good to discourage its use by making it
> hairy.
I can't agree that any language feature should be made hairy in order
to discourage its use. If a feature deserves to be in Scheme then it
deserves to be done right. You (or I, at least) can't morally
discourage the use of a feature by booby-trapping it with excess
complexity.
> Do I understand the lack of discussion to mean that
> there are no objections to JAR's proposal? If so, let's adopt
> it and move on.
No, I at least just haven't finished preparing a response. His
proposal is detailed, has much merit, and deserves serious study.
This topic is *much* more complicated than the others raised so far,
so it's hard to critique one proposal without suggesting alternatives.
> John
--db--
∂08-Apr-87 1025 @MC.LCS.MIT.EDU:Kahn.pa@Xerox.COM Re: scheme in prolog
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 10:25:50 PDT
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 8 Apr 87 13:24:10 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 APR 87 10:20:52 PDT
Date: Wed, 8 Apr 87 10:20:31 PDT
From: Kahn.pa@Xerox.COM
Subject: Re: scheme in prolog
In-Reply-To: "mike%acorn@LIVE-OAK.LCS.MIT.EDU's message of Tue, 7 Apr 87
19:38:00 EST"
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
cc: scheme@mc.lcs.mit.edu, prolog-request@sushi.stanford.edu
Message-ID: <870408-102052-1129@Xerox>
Tim Finin says "It is very difficult to implement an efficient
interpreter for a language which has side-effects in prolog," while mike
beckerle says "No more difficult, I think, than interpreting a language
with side-effects in a language without side effects."
Notice that Tim says "efficient" and mike doesn't. I think that much of
the argument hinges on this point. Just to muddy the waters I want to
bring up a paper in the 2nd international logic programming conference
(1984) called "Mutable arrays in Prolog" (or some such). The paper
essentially presents a naive implementation of arrays in Pure Prolog
where every write copies and a read entails a linear search. It then
goes on to describe a primitive implementation of the predicates for
creating and accessing arrays. The primitive implementation in some
cases actually had the same computational complexity as array primitives
in conventional languages. Is there any specification of Prolog which
would rule out a compiler that did such optimizations?
The point is that something is wrong with the question of whether one
language can EFFICIENTLY implement another. One can ask whether a
particular implementation of a language can efficiently implement
another. A more interesting question I think is whether one language
can EASILY and NATURALLY implement another.
- ken kahn
References
mike%acorn@LIVE-OAK.LCS.MIT.EDU's message of Tue, 7 Apr 87 19:38:00 EST
-- scheme in prolog
∂08-Apr-87 1532 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET towards an agenda
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 15:31:50 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Apr 87 18:24:44 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab14032; 8 Apr 87 17:50 EDT
Received: from ti-csl by RELAY.CS.NET id ab23460; 8 Apr 87 17:46 AST
Received: from home (home.ARPA) by tilde id AA15867; Wed, 8 Apr 87 14:38:40 cst
Received: by home id AA06501; Wed, 8 Apr 87 15:39:02 cdt
Date: Wed, 8 Apr 87 15:39:02 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704082039.AA06501@home>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: towards an agenda
I had hoped to propose an agenda here, but I tripped over too many
unknowns, so let's try to nail a few things down first.
Is there agreement on which days we will meet? Jonathan, can you
suggest which hours of the day will be available for scheduling?
Can everyone arrange to attend?
Will and I suggested the following topics that we would like to see
resolved:
1. multiple return values
2. customizable reader
3. number syntax and exactness
4. macros
5. optional arguments
6. structures and opaque objects (& set!, maybe)
7. environments and modules
These are roughly in descending order of priority as we see it. We
already have proposals for 1, 4, and 5. Will hopes to cover 2 soon.
I suggested a more Common Lisp-like number syntax last year, so I'll
plan to clean that up and propose it again. Kent Dybvig's book
contains some language about exactness that I'd like to comprehend in
my proposal. Chez Scheme and TI Scheme (and perhaps others) have
somewhat contradictory define-structure features, so it would be nice
to head off further divergence in that area.
Although topic 7, environments and modules, is last on the list, I see
it as having long-term impact on whether Scheme continues to be used
for ever larger and larger "production" systems. "Programming in the
large" is a serious challenge for everyone looking to Lisp dialects
for new programming paradigms right now, and I'd like to find a way to
give Scheme an edge over other languages.
Other topics were suggested at the 1986 Lisp conference luncheon, e.g.
a way to declare that a variable such as CAR is never assigned. Would
anyone care to propose any of them for discussion at our next meeting?
--db--
∂08-Apr-87 2121 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 21:21:03 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Apr 87 23:55:12 EDT
Date: Wed, 8 Apr 87 23:29:15 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <181512.870408.CPH@AI.AI.MIT.EDU>
I've finally finished reading all of the mail on this topic, and I'd
like to offer a few comments:
First, I disagree with Alan when he states that not discarding extra
values misses the point of multiple values. In fact, I think there
are two things that one gets, which JAR indicated with his message.
First, just having multiple values of any kind is useful by itself.
The extra functionality of discarding additional values is an
additional convenience and not in any way "essential" to the concept
of multiple values. Like JAR, I've been using semantics #1 for some
time and have found it quite useful, even implemented in Scheme as I
have done.
Jinx's argument in favor of semantics #2 contains an additional flaw.
In fact, the particular example he chose highlights it rather clearly:
given an implementation of quotient that returned two values, why is
there any particular reason that the first value should be treated
specially? In fact, one might be interested in the remainder more
often than the quotient, and the order of arguments then enforces a
built in prejudice about which value is used more often. Am I then to
assume that, to correct for this bias, `remainder' also returns two
values, but in the opposite order?
Another argument in favor of semantics #1 is that programs written in
that semantics will also run in an implementation with semantics #2.
On possible way to resolve the conflict is to accept semantics #1
immediately with a provision to upgrade to semantics #2 later if
everyone can be convinced that it is reasonable.
However, I'd like to propose something different. We have already
accepted (I think) that multiple values are optional extensions rather
than required. Why not accept BOTH semantics? That gives
implementations more flexibility since they can choose between three
options: no multiple values, or either of the semantics #1 or #2.
People can write programs in any of those forms, with appropriate
restrictions to portability: in my case I might choose to write using
semantics #1, accepting that my programs will not run in systems
without multiple values (or else supplying my own implementation in
those cases). Others could write using semantics #2 and accept that
their programs would be somewhat less portable.
In any case, because multiple values are optional, I think that
standard procedures (like `quotient') should not return multiple
values.
Lastly, I like the names `values' and `with-values'. But I must admit
that I wish
(with-values (lambda () <generate>) <receive>)
would read
(with-values <generate> <receive>.
However, I understand why this might be undesirable from the
implementor's point of view.
∂08-Apr-87 2219 @MC.LCS.MIT.EDU:munnari!goanna.oz!hal@seismo.CSS.GOV towards an agenda
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 22:18:56 PDT
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 9 Apr 87 00:48:41 EDT
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA13684; Wed, 8 Apr 87 22:51:15 EDT
Message-Id: <8704090251.AA13684@seismo.CSS.GOV>
Received: from goanna by munnari with SunIII (5.5)
id AA09438; Thu, 9 Apr 87 12:23:00 EST
Date: Thu, 9 Apr 87 10:49:43 EST
From: munnari!goanna.oz!hal@seismo.CSS.GOV (Hal Abelson)
Received: by goanna.OZ (4.3)
id AA14144; Thu, 9 Apr 87 10:49:43 EST
To: rrrs-authors@mc.lcs.mit.edu
Subject: towards an agenda
Bartley's agenda doesn't include error-handling mechanisms.
I thought we had decided to worry about that.
∂08-Apr-87 2243 @MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu scheme in prolog
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 22:43:35 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 9 Apr 87 01:01:40 EDT
Received: by linc.cis.upenn.edu
id AA03895; Wed, 8 Apr 87 23:31:29 AST
Date: Wed, 8 Apr 87 23:31:29 AST
From: tim@linc.cis.upenn.edu (Tim Finin)
Posted-Date: Wed, 8 Apr 87 23:31:29 AST
Message-Id: <8704090331.AA03895@linc.cis.upenn.edu>
To: Kahn.pa@xerox.com, mike%acorn@live-oak.lcs.mit.edu, hudak-paul@yale-arpa
Cc: scheme@mc.lcs.mit.edu, prolog-request@sushi.stanford.edu
Subject: scheme in prolog
The points that Ken, Mike and Paul make are quite valid and very
interesting. Implementing an interpreter for a language with side
effects in a language without them is bit of a problem and leads to
some known tradeoffs. The mutable array example is a case in point.
However, Prolog, as opposed to a purer and more abstact logic
programming language does have side effects. One is free, if one
chooses, to dynamically assert and retract clauses in the database. I
was, in general, pleased with the way my scheme-in-prolog interpreter
turned out, except when it came to implementing SET!. I was surprised
that Prolog's side-effecting operations did not enable handle this in
what I considered a good way.
Tim
∂09-Apr-87 0052 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: scheme in prolog
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 00:52:05 PDT
Received: from yale-celed.arpa (TCP 20011000034) by MC.LCS.MIT.EDU 8 Apr 87 19:21:14 EDT
Received: by yale-celed.arpa; Wed, 8 Apr 87 17:17:56 EDT
Date: Wed, 8 Apr 87 17:17:56 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8704082117.AA14910@yale-celed.arpa>
Received: by yale-ring (midas.ring.cs.yale.edu/58D)
via WIMP-SWEEP (Version 1.8/1.4) ; Wed Apr 8 16:06:30
Received: by yale-ring (node-add2.ring.cs.yale.edu/ADD2)
via WIMP-SPOOL (Version 1.2/1.4) ; Wed Apr 8 16:10:21
Subject: Re: scheme in prolog
To: scheme@mc.lcs.mit.edu, prolog-request@sushi.stanford.edu
Cc: mike%acorn@oak.lcs.mit.edu, tim@linc.cis.upenn.edu, Kahn.pa@Xerox.COM
I was about to respond to the Tim Finin / Mike Beckerle discussion
in much the same way that Ken Kahn did, so I won't bother now, except
to point out that the efficiency issue, in particular the "aggregate
update" or "copy avoidance" issue, has also been addressed by the
functional programming community. This includes work in
semantics-directed compilation as well as more general work by Alan
Mycroft (in his dissertation), David Schmidt (see a recent TOPLAS
paper about detecting "singlethreaded stores") and me (see POPL 85,
Lisp and FP 86).
The nice thing about doing all this in the functional programming
paradigm is that the implementation of an interpreter for a language
looks VERY MUCH (if not identical) to the formal semantics of the
language. At Yale we have been experimenting a bit with such "truly
direct" semantics-directed compilation/interpretation with very
encouraging results. Thus, assuming one believes in denotational
semantics (and I realize that some people don't...), then the answer
to Ken Kahn's question:
A more interesting question I think is whether one language
can EASILY and NATURALLY implement another.
would have to be in the affirmative.
-Paul Hudak
-------
∂09-Apr-87 0732 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU towards an agenda
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:32:04 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 9 Apr 87 10:33:53 EDT
Received: by GENEVA.AI.MIT.EDU; Thu, 9 Apr 87 09:32:58 est
Date: Thu, 9 Apr 87 09:32:58 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8704091432.AA18976@geneva>
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, Bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: David Bartley's message of Wed, 8 Apr 87 15:39:02 cdt <8704082039.AA06501@home>
Subject: towards an agenda
I feel very strongly against customizable readers. I think they are
not really very useful, and on the other hand are abused immensely.
I've seen plenty of code which I can no longer recognize as Lisp code
because of all the reader extensions used in it.
I think it is a bad idea to standardaize on one.
∂09-Apr-87 1001 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 10:01:42 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Apr 87 12:40:25 EDT
Date: Thu, 9 Apr 87 12:38:35 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: readers & tokenizers
To: jinx@GENEVA.AI.MIT.EDU
cc: bartley%home%ti-csl.csnet@RELAY.CS.NET,
rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 9 Apr 87 09:32:58 est from jinx at GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-ID: <181778.870409.JAR@AI.AI.MIT.EDU>
Date: Thu, 9 Apr 87 09:32:58 est
From: jinx at GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
To: bartley%home%ti-csl.csnet at RELAY.CS.NET
cc: rrrs-authors at MC.LCS.MIT.EDU,
Bartley%home%ti-csl.csnet at RELAY.CS.NET
Re: towards an agenda
I feel very strongly against customizable readers. I think they are
not really very useful, and on the other hand are abused immensely.
I've seen plenty of code which I can no longer recognize as Lisp code
because of all the reader extensions used in it.
I think it is a bad idea to standardaize on one.
I sympathize with this. However, the argument I see for this is as
follows: many Scheme implementations internally have high-speed
tokenizers which either are or could easily be made to be table-driven.
If for some reason one writes a Scheme program which needs a tokenizer,
a (Pascal, Prolog, ...) compiler for example, one has a choice between
writing slow portable code and writing fast unportable code. The
speedup can be quite significant; how many implementations have readers
that are written using only the i/o primitives in the report?
(The reader in the meta-circular Scheme implementation I'm working on
comes close, except that it uses PEEK-CHAR.)
I'm not going to be precise about what I mean by "tokenizer" but at the
very least it means something akin to READ-LINE which stops when it
comes upon a "delimiter", and perhaps does some sort of filtering or
parsing (e.g. case normalization, escape sequence handling) in the
process.
Of course, you can in this case use the technique I described in a
previous message, of defining your own interface and then making a
different bummed implementation of it for each different implementation
you actually use. But any situation like this is a candidate for
standardization, if more than one person is likely to use it.
For things like this (the category also includes multiple values #1,
hash tables, Chris's string-manipulation primitives, and other things I
have mentioned before), we are really in the business of standardizing
on interfaces to libraries of things that can be written portably but
are often better not. We're not talking changes to the language, we're
talking making life easier for those who use these features and people
who read their code.
As for defining "read macros" for scheme programs, that's another story.
I've never felt much need for this except when emulating one lisp
dialect in another, and this application has certainly diminished in
importance now that there is some degree of standardization. In cases
where I feel I just can't do without, e.g. if I'm playing with some idea
for a language design which for some bizarre reason really needs a new
read macro, I probably wouldn't mind too terribly writing my own reader,
which isn't such a difficult thing, especially if there's already a
tokenizer handy. You probably want to do that if you're emulating other
dialects (like Common Lisp), too.
The peculiar thing about the Common Lisp situation is that it supports
read macros, but it doesn't give you any control of the tokenizer. E.g.
if you're implementing C and need to distinguish case, you're out of
luck. If you want 1A to be an error, or colon to be alphabetic, or
... to be a valid symbol, give up. But then generality was explicitly
not one of their design goals in this case.
Jonathan
∂09-Apr-87 1012 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 10:12:14 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 9 Apr 87 12:49:07 EDT
Received: by GENEVA.AI.MIT.EDU; Thu, 9 Apr 87 11:48:40 est
Date: Thu, 9 Apr 87 11:48:40 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8704091648.AA19230@geneva>
To: JAR@AI.AI.MIT.EDU
Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Thu, 9 Apr 87 12:38:35 EDT <181778.870409.JAR@AI.AI.MIT.EDU>
Subject: readers & tokenizers
I'm not opposed to making available the tokenizer to users. I think
that's a good idea. But I really dislike the idea of reader macros,
and would much rather make people write their own readers when
imbedding/implementing other languages.
If by customizable reader you mean tokenizer (as a procedure or set of
procedures to invoke on a port, for example), then I don't mind, but I
will very strongly oppose anything which allowes users to define #.
easily.
∂09-Apr-87 1324 @MC.LCS.MIT.EDU:gls@Think.COM readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 13:24:24 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 9 Apr 87 16:10:24 EDT
Received: from feuerbach by Think.COM via CHAOS; Thu, 9 Apr 87 16:05:08 EST
Date: Thu, 9 Apr 87 16:05 EDT
From: Guy Steele <gls@Think.COM>
Subject: readers & tokenizers
To: jinx@geneva.ai.mit.edu, JAR@ai.ai.mit.edu
Cc: bartley%home%ti-csl.csnet@relay.cs.net, rrrs-authors@mc.lcs.mit.edu,
gls@think.com
In-Reply-To: <8704091648.AA19230@geneva>
Message-Id: <870409160550.5.GLS@FEUERBACH.THINK.COM>
Date: Thu, 9 Apr 87 11:48:40 est
From: jinx@geneva.ai.mit.edu (Guillermo J. Rozas)
I'm not opposed to making available the tokenizer to users. I think
that's a good idea. But I really dislike the idea of reader macros,
and would much rather make people write their own readers when
imbedding/implementing other languages.
If by customizable reader you mean tokenizer (as a procedure or set of
procedures to invoke on a port, for example), then I don't mind, but I
will very strongly oppose anything which allowes users to define #.
easily.
Connection Machine Lisp would have been considerably more difficult
to prototype if not for the availability of the reader-macro facility.
--Guy
∂09-Apr-87 1412 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 14:11:58 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 9 Apr 87 17:14:23 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 112884; Thu 9-Apr-87 17:07:22 EDT
Date: Thu, 9 Apr 87 17:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: multiple return values
To: jinx@GENEVA.AI.MIT.EDU, JAR@AI.AI.MIT.EDU,
adams%tekchips.tek.com@RELAY.CS.NET, ALAN@AI.AI.MIT.EDU,
willc%tekchips.tek.com@RELAY.CS.NET
cc: RRRS-AUTHORS@MC.LCS.MIT.EDU
In-Reply-To: <8703272347.AA03757@tekchips.TEK.COM>,
<8703301804.AA09557@geneva>
Message-ID: <870409170703.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The Common Lisp decision to allow additional return values to be silently
ignored when unreferenced is an interesting decision but it is certainly
not the only position that one can take.
The CL specification is muddied by having to explain that there are
different kinds of bound variable lists, some of which care how many
values are passed through and others of which do not. I would be sad if
Scheme went down this road.
I think that the Scheme community is in a unique position in being able
to see clearly the close relation between returning (invoking functions
which are continuations) and calling (invoking functions which are not
continuations). I think that in the long run it would be much more valuable
to the computer science community as a whole for us to explore the
consequences of that close relation than it would be for us to be
gratuitously compatible with CL.
I think that great advantage in terms of static and dynamic error
checking can come from explicitly specifying when these values are to be
returned and when not. I think that continuations which take optional
or rest arguments are fine as long as they're notated as such. This
protects people who want the error checking that comes from return
values being mismatched in number and who can afford to pay for that
checking. If we adopt a strategy which says that checking is illegal,
we're making it very hard for people to get checking.
I do agree with a subset of the worry that Alan expressed, though, which
is that (+ (F) 3) should work whether F is implemented by
(LAMBDA () 4)
or
(LAMBDA () (RETURN-VALUES 4)).
I don't think that:
(LAMBDA () (RETURN-VALUES 4 5))
needs to work, though. In fact, I think it should be permitted (and
encouraged) to signal an error. I think some syntactic sugar could
easily make this palatable; eg, (+ (VALUE 0 (F)) 3)... or better
still, (+ (G) 3) where G was a function defined to do what I really
meant to be doing.
∂09-Apr-87 1420 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 14:20:47 PDT
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 9 Apr 87 17:16:11 EDT
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA09630; Thu, 9 Apr 87 14:11:51 PDT
Date: Thu, 9 Apr 87 14:11:51 PDT
From: andy@hobbes.ads.ARPA (Andy Cromarty)
Message-Id: <8704092111.AA09630@hobbes.ads.arpa>
To: rrrs-authors@mc.lcs.mit.edu
Subject: readers & tokenizers
One of the difficulties with conventional read tables is that
they become very dangerous in a "real" production software
environment, relying on lots of Scout's Honor programming
practices and usage restrictions. If you write one 10,000 line
component of a large system and I write another, there is a risk
that you will change the semantics of (READ) out from under me,
breaking my code in ways that I will find extremely difficult
to debug. To the extent that we are serious about having people
use Scheme outside the classroom, this is an important concern.
I have used many LISPs that lack both a user-modifiable reader and
reader "macros" -- in fact, I have written compilers using those LISPs
(including, of course, lexical and syntactic analysis) in a relatively
painless fashion. It merely requires good coding practices combined
with a little extra effort to build up the lexical analysis subsystem
yourself (really a fairly small number of additional functions). I
offer this as an "existence proof" of sorts to indicate that we don't
really *need* extra gook in the reader, and to suggest that we should
be careful about how and why we make it more complex.
I have no objection to an improved input system if it is stateless.
A trivial new function that would be useful is a (READ-LINE [PORT])
procedure that reads a sequence of characters terminated by NEWLINE
or EOF-OBJECT, whichever it encounters first, returning it as a string.
A slight extension of this capability would require you to provide
the termination character yourself, e.g. (READ-LINE CHAR [PORT]).
This can be further extended to take a list of termination characters
instead of one character (making it similar to the scanning and breaking
functions in SNOBOL), or perhaps a predicate procedure of one argument that
returns #T iff the character it is passed is a token terminator, viz.
(READ-TOKEN TERMINATOR?-PROC [PORT]). This permits you to perform
lexical analysis of an input stream in a quite straightforward fashion
without adding significantly to the complexity of the reader for the >90%
of the cases where you are just reading symbols, lists, and other objects
that the reader already handles well.
The advantage I see in such an approach is that all the state is tied
up in your predicate or your specific invocation of READ-LINE. There
thus is no risk of collisions between different modules, even if they
are interleaving reads on the same port. Further, it can be implemented
in a quite straightforward fashion.
One might object that this could be "inefficient." Such an argument
doesn't seem compelling on the face of it, first because a non-stateless
reader imposes risks that are significantly more costly than the loss
of a few cpu cycles, and second because if we take seriously the suggestion
that Scheme should be a useful systems programming language, then such
an approach will help ensure that implementors will be pressured into
improving the performance of those critical parts of the Scheme system
that usually are very slow in LISPs (i.e. readers).
I don't know that I want to call this a "proposal," but at least I
feel that the spirit of a proposal is there, i.e. that the reader
should be stateless if we can find an effective way to achieve that goal.
Finally, I would advocate one extension to the reader itself.
That is the inclusion of #+ and #-. We already have added these
to the ADS Scheme reader, because we found that it had a tremendous
impact on portability of code from one LISP environment to another.
Again, this sort of capability is critical for large development
efforts or for the production of commercial tools that are intended
to work in multiple LISP dialects. I further suggest that "scheme"
specifically be recognized by #+ and #- and that "#+scheme" be true
in R?RS Scheme.
asc
∂09-Apr-87 1638 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 16:38:43 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Apr 87 18:47:11 EDT
Received: from relay2.cs.net by RELAY.CS.NET id af25165; 9 Apr 87 18:19 EDT
Received: from ti-csl by RELAY.CS.NET id ac00940; 9 Apr 87 18:17 AST
Received: from home (home.ARPA) by tilde id AA14513; Thu, 9 Apr 87 15:19:09 cst
Received: by home id AA23970; Thu, 9 Apr 87 16:19:28 cdt
Date: Thu, 9 Apr 87 16:19:28 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704092119.AA23970@home>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: number syntax
Before I make another proposal on number syntax, I'd like some
feedback on current practice.
Has anyone implemented exactness using a mechanism substantially
different from the one Kent Dybvig describes in his new book?
(Quoting his page 111: "In practice, the internal representation for
an exact quantity is as an integer or ratio, and the internal
representation for an inexact quantity is as a floating point number,
although other representations are possible." Also, "The exactness of
a complex numeric object depends on the exactness of its real and
imaginary parts.") How do people feel about this approach? Does this
fulfill the spirit of exactness? Does anyone want to pay for a more
orthogonal exactness attribute for numbers?
Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
inexact 2 to print as 2.0?
Has anyone implemented the -1+2i or 5@7 syntax for complex numbers?
Is there strong resistance to Common Lisp's #c(-1 2) representation?
In general, is there anyone strongly opposed to the idea that Scheme
number representations should be made to look more like Common Lisp's?
--db--
∂09-Apr-87 1648 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 16:48:14 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Apr 87 18:48:03 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac25167; 9 Apr 87 18:19 EDT
Received: from ti-csl by RELAY.CS.NET id ae00940; 9 Apr 87 18:17 AST
Received: from home (home.ARPA) by tilde id AA14868; Thu, 9 Apr 87 15:28:47 cst
Received: by home id AA24121; Thu, 9 Apr 87 16:29:05 cdt
Date: Thu, 9 Apr 87 16:29:05 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704092129.AA24121@home>
To: JAR@MC.LCS.MIT.EDU
Cc: jinx%geneva.ai.mit.edu@RELAY.CS.NET,
bartley%home%ti-csl.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Thu, 9 Apr 87 12:38:35 EDT
Subject: readers & tokenizers
> For things like this (the category also includes multiple values #1,
> hash tables, Chris's string-manipulation primitives, and other things I
> have mentioned before), we are really in the business of standardizing
> on interfaces to libraries of things that can be written portably but
> are often better not. We're not talking changes to the language, we're
> talking making life easier for those who use these features and people
> who read their code.
Perhaps we should discuss a more formal way to share libraries of
useful code (a "yellow pages"). Then we could concentrate our
standardization efforts on the library interface (modules and
environments again!) and other true language features.
∂09-Apr-87 1803 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 18:03:45 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 9 Apr 87 20:49:10 EDT
Received: by GENEVA.AI.MIT.EDU; Thu, 9 Apr 87 19:11:01 est
Date: Thu, 9 Apr 87 19:11:01 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8704100011.AA22486@geneva>
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: David Bartley's message of Thu, 9 Apr 87 16:19:28 cdt <8704092119.AA23970@home>
Subject: number syntax
Has anyone implemented exactness using a mechanism substantially
different from the one Kent Dybvig describes in his new book?
(Quoting his page 111: "In practice, the internal representation for
an exact quantity is as an integer or ratio, and the internal
representation for an inexact quantity is as a floating point number,
although other representations are possible." Also, "The exactness of
a complex numeric object depends on the exactness of its real and
imaginary parts.") How do people feel about this approach? Does this
fulfill the spirit of exactness? Does anyone want to pay for a more
orthogonal exactness attribute for numbers?
That is very much against the proposal. We have not implemented it at
MIT, but the original proposal is such that both exact and inexact
flonums are possible (and desirable), and similarly for the other
types. Although we have not implemented it, we have an implementation
in mind, and it is orthogonal: for each type of number, there is a bit
specifying whether it is exact or not.
Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
inexact 2 to print as 2.0?
It depends on the format specification. For the explicit ones, there
should be no question. I think, however, that if the format is (HEUR)
it should print as #i2 .
Has anyone implemented the -1+2i or 5@7 syntax for complex numbers?
Is there strong resistance to Common Lisp's #c(-1 2) representation?
CPH has implemented the r↑3rs complex notation for MIT Scheme. Having the #c
notation should be optional. I don't think the syntax becomes
ambiguous if it is added, but there is no need for it.
In general, is there anyone strongly opposed to the idea that Scheme
number representations should be made to look more like Common Lisp's?
Not I, as long as it does not run counter to what the report already
states.
∂09-Apr-87 1848 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU yellow pages
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 18:48:09 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Apr 87 21:50:50 EDT
Date: Thu, 9 Apr 87 21:49:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: yellow pages
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 9 Apr 87 16:29:05 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <182098.870409.JAR@AI.AI.MIT.EDU>
Date: Thu, 9 Apr 87 16:29:05 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Perhaps we should discuss a more formal way to share libraries of
useful code (a "yellow pages"). Then we could concentrate our
standardization efforts on the library interface (modules and
environments again!) and other true language features.
I agree completely. I think the distinction would be very useful in
taking some of the heat out of our discussions, since people needn't be
as sensitive about things which have no impact on semantics (and
therefore no impact on implementation).
We really need to think in general about what the eventual documentary
outcome of our next meeting (or two) ought to be. I think a yellow
pages of some sort, clearly separated from a description of extensions
to the semantics, is definitely in order.
Jonathan.
∂09-Apr-87 1921 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 19:21:19 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Apr 87 22:23:10 EDT
Date: Thu, 9 Apr 87 22:21:24 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: readers & tokenizers
To: andy@ADS.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 9 Apr 87 14:11:51 PDT from andy at hobbes.ads.ARPA (Andy Cromarty)
Message-ID: <182109.870409.JAR@AI.AI.MIT.EDU>
Date: Thu, 9 Apr 87 14:11:51 PDT
From: andy at hobbes.ads.ARPA (Andy Cromarty)
One of the difficulties with conventional read tables is that
they become very dangerous in a "real" production software
environment...
I have no objection to an improved input system if it is stateless.
...
Just for the record, I fell obliged to point out that T has a
parameterized reader (i.e. readtables), and at the same time it is
completely safe and stateless. There is no such thing as *READTABLE* in
T; the global default reader parameters are immutable. There is a
version of READ (called READ-OBJECT) which takes a read table as an
argument. READ extracts a read table out of the port being read from
and then calls READ-OBJECT. A port's readtable is initially the
standard readtable when the port is opened, but it can be set to be
something else after the port is opened; thus readtables are lexically
scoped. A user can create new readtables and mutate them (e.g. define a
read macro or alter the input radix), but the standard readtable is
immutable, so there's no way you can accidentally step on a readtable
that someone else will see.
I do not propose this for Scheme, but I thought you should know that
stateless doesn't mean you have to throw away the possibility of something
higher level than the scanner you suggest, or even read macros.
I think a function of the sort you propose would be fine, that's
basically the minimum I had in mind for a "tokenizer". We might
consider introducing "character sets" as in Icon (and MIT Scheme?? I
vaguely remember seeing something of the sort) to help make this go even
faster (since that's the point of the proposal). One procedure could
coerce a list of or predicate on characters to a character set, and then
the character set specifying the delimiters could be passed to READ-LINE
(actually READ-STRING is probably a better name).
Finally, I would advocate one extension to the reader itself.
That is the inclusion of #+ and #-. We already have added these
to the ADS Scheme reader, because we found that it had a tremendous
impact on portability of code from one LISP environment to another.
Again, this sort of capability is critical for large development
efforts or for the production of commercial tools that are intended
to work in multiple LISP dialects. I further suggest that "scheme"
specifically be recognized by #+ and #- and that "#+scheme" be true
in R?RS Scheme.
I have used read-time conditionalization in the past and have concluded
that it is not a good idea. If a language must have conditionalization,
it must have run-time semantics (although of course a compiler can
optimize it into load-time or compile-time, depending on what it knows
about the target system). The problem with read time conditionalization
is that it interacts extremely poorly with cross-compilation, static
code analysis, and macros.
What I always do is encapsulate implementation dependencies by defining
an interface, and then write multiple implementations of the same
interface. In my experience this leads to code that's much prettier,
more modular, AND more portable. Why won't this work for you?
Jonathan.
∂09-Apr-87 2348 @MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA Re: readers & tokenizers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 23:48:02 PDT
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 10 Apr 87 02:46:39 EDT
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA10303; Thu, 9 Apr 87 23:41:40 PDT
Date: Thu, 9 Apr 87 23:41:40 PDT
From: andy@hobbes.ads.ARPA (Andy Cromarty)
Message-Id: <8704100641.AA10303@hobbes.ads.arpa>
To: JAR@AI.AI.MIT.EDU
Subject: Re: readers & tokenizers
Cc: andy%hobbes@ads.arpa, rrrs-authors@MC.LCS.MIT.EDU
Reply-To: andy@ADS.arpa
The T model, or something like it, seems to meet the criteria
I proposed for statelessness. What I would prefer to see us
avoid is the monolithic global model of read tables. T seems to
offer one nice way to do that, given your description.
I have used read-time conditionalization in the past and have concluded
that it is not a good idea. If a language must have conditionalization,
it must have run-time semantics....
What I always do is encapsulate implementation dependencies by defining
an interface, and then write multiple implementations of the same
interface. In my experience this leads to code that's much prettier,
more modular, AND more portable. Why won't this work for you?
In what I recall you guys at universities calling the "real world,"
we often don't have the luxury of writing all the code ourselves,
nor even of specifying it. One specific case I had in mind when
I wrote my note was a medium-sized (~25,000 lines of code) LISP
software tool written in Common LISP that we have been rendering
compatible with Scheme. (Note that I did not say "porting to Scheme"
-- it must remain fully compatible with the other LISPs in which it
executes, and given its size it is unthinkable to maintain separate
versions of the source as the software is constantly extended.)
Use of #+/#- reader conditionals have permitted us to add minimal
annotations to this software and make it compatible with Scheme.
Perhaps more importantly, the code *already* contains #+ and #-, because
it is "real" code written to run under 3 brands of Common Lisp, as well as
MacLISP and Franz, and we don't have the option of ripping all that
stuff out (nor the budget and wo/manpower to rip all the offending
conditionalization code out). The harsh reality was that being able to use
existing desirable software tools required us to support #+ and #-, because
historically that has been viewed as the "clean" way to conditionalize
other LISP code. (Note that this is not the same as arguing, for
example, that the Scheme reader should support InterLisp CLisp syntax
or something along those lines. It merely recognizes that the way code
has been written to make it portable is using #+ and #-, and if we want
to make it possible to run non-trivial non-Scheme LISP code in Scheme,
this may be the lowest-cost highest-payoff addition to Scheme's reader
that we could make.)
I disagree with the implication that Scheme has escaped run-time
conditionalization. I made a comment about this many months ago
when we discussed LOAD. If we really want to be able to view our
files as containing static code, then we cannot have a LOAD of the
sort we presently use, in my view; we need an INCLUDE instead, specifically
one that is utterly literal in its interpretation. That is, for files as
in
file1: (set! *closed-var 1)
(set! *closed-var 2)
file2: (let ((*closed-var '()))
(if (read)
(include "file1"))
*closed-var)
then "loading" or "executing" file2 would be identical to executing
(let ((*closed-var '()))
(if (read)
(set! *closed-var 1)
(set! *closed-var 2))
*closed-var)
The use of LOAD introduces some fascinating difficulties into
the sort of static analysis of code you wish to perform; for
example consider "loading or executing" file2, with contents as per
file1: (set! foo (lambda () (write 'goodbye)(newline)))
file2: (define foo (lambda () (write 'hello)(newline)))
(if (read)
(load "file1"))
(foo)
The extension to problems with macros (especially if we can redefine
IF, for example -- which I advocate permitting, BTW), is equivalently
problematic, or more so. The point is that we already have introduced
constructs that render static analysis difficult or meaningless, even
where there might have been cleaner alternatives (INCLUDE instead of
LOAD, say). I would not find an argument that this is poor use of LOAD
very interesting, since these (ab)uses of LOAD seem to me to be very much
in the spirit of dynamic-scoping-of-the-execution-environment that was
precisely the reason LOAD was defined the way it was in R3RS, at least
according to my recollection of the discussion.
I also would add that, although we did create additional primitives for
managing a sort of "features list" in ADS Scheme, there is no need to do this
if you wish to have a Scheme that supports #+scheme and yet remains
susceptible to static analysis. If the user may not change the "features
list," then the compiler always can know that #+scheme can be ignored and
that #-scheme means "the following expression reliably will be discarded."
The same static interpretation rules can hold for other #+/#- "features." I
see no problems for static analysis in this case.
Regards, asc
∂10-Apr-87 0734 @MC.LCS.MIT.EDU:jmiller@MEPHISTOPHELES.AI.MIT.EDU yellow pages
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 07:34:45 PDT
Received: from mephisto (TCP 2206400250) by MC.LCS.MIT.EDU 10 Apr 87 10:37:23 EDT
Received: by MEPHISTOPHELES.AI.MIT.EDU; Fri, 10 Apr 87 10:33:31 edt
Date: Fri, 10 Apr 87 10:33:31 edt
From: jmiller@MEPHISTOPHELES.AI.MIT.EDU (Jim Miller)
Message-Id: <8704101433.AA00738@mephisto>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Thu, 9 Apr 87 21:49:15 EDT
Subject: yellow pages
D'Accord! I personally feel that the highest and simplest item on the
agenda should be an agreement on a STANDARD way to guarantee in ALL
implementations that a program written using all and only the features
in R↑nS will run. We discussed and rejected an attempt to work on
this just before publication of the report because of time
constraints.
This means, essentially, some standardized way to wrap code indicating
that the R↑nS syntax and reader are to be used. Once we have this, we
can actually begin to exchange our code with confidence that it will
work as intended at the recipient's end -- which simply isn't true
today without a wizard as the receiver.
--Jim
∂10-Apr-87 0944 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 09:44:39 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Apr 87 12:20:11 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac03508; 10 Apr 87 12:06 EDT
Received: from ti-csl by RELAY.CS.NET id ae06442; 10 Apr 87 12:02 AST
Received: from home (home.ARPA) by tilde id AA04458; Fri, 10 Apr 87 09:28:07 cst
Received: by home id AA06276; Fri, 10 Apr 87 10:26:31 cdt
Date: Fri, 10 Apr 87 10:26:31 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704101526.AA06276@home>
To: RRRS-Authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: macros
I confess that I find the macro problem to be one of the hairiest yet
one of the most important ones we face. I'm not yet ready to comment
on Jonathan's proposal because it differs so much from my current
approach that I need to re-examine my assumptions and biases.
Before debating the specific merits of any particular proposal,
perhaps we should discuss some basic issues first and work our way up
from there. I'd also like to get a feel for what kind of an
agreement, and how much of one, we should be working towards.
My list of basic issues regarding macros includes...
-- One or two namespaces or a hybrid?
How do we deal with the fact that both macro/syntax keywords and
variables are drawn from the same set of identifiers? I think
lambda-bound names should take precedence over keywords, but should
LET-SYNTAX-bound keywords take precedence over lambda-bound names of
an outer level?
What about top-level DEFINE? Does (DEFINE X ...), like (LAMBDA (X) ...),
take precedence over keywords?
What do we do with keywords that appear in places where a keyword is not
expected, like (+ IF AND), and thus appear to be variable references?
Should we embed syntax tables in the lexical environment or keep them
separate?
For those who might prefer a single namespace: should INLINE and other
optimizations be encompassed? How about named constants like PI and
EOF-OBJECT?
-- Mutable or immutable syntax tables?
It seems excessively cumbersome to wrap a LET-SYNTAX around a file or
collection of files.
Why should extending the syntax differ from the style of incrementally
adding definitions with DEFINE?
Perhaps INCLUDE is a better answer than LOAD.
-- Solution of capture problems
Eugene and others have addressed this.
-- Must a macro expand into an expression--i.e. not a keyword?
Suppose an (*IF*) macro expands into the identifier IF. Then how does
one interpret the result of the expansion ((*if*) a b c) ==> (if a b c)?
-- Which syntax table is used by various REPLs, LOAD, COMPILE-FILE, etc.?
-- What about macros that expand into multiple definitions?
-- Should a macro writer have the ability to make absolute (that is,
"qualified") references?
-- Should COMPILE-FILE execute any of the forms it compiles?
-- Can we avoid EVAL-WHEN ?
* * *
How much agreement must we reach to be useful?
-- basic principles?
Deciding how identifiers in programs are resolved as references is a
good start.
-- a syntax for >using< macros?
We're probably wedded to the current syntax that can only distinguish
macros from applications by recognizing keywords.
-- a syntax for >defining< macros?
A portable way for defining "global" macros would satisfy many users
and may be easier to reach agreement on than dealing more deeply with
scoping issues. On the other hand, many of us will probably proceed
to implement lexically scoped syntax definitions.
-- user-friendly syntax for defining macros
Since user-friendly macro definition capabilities tend to have
restricted capabilities, this will probably always be an extension
beyond more primitive capabilities. Perhaps this is a candidate for
the "yellow pages."
What is a reasonable goal for us to work towards?
--db--
∂10-Apr-87 1000 @MC.LCS.MIT.EDU:gls@Think.COM number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 10:00:13 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 10 Apr 87 12:46:18 EDT
Received: from godot.think.com by Think.COM; Fri, 10 Apr 87 12:42:01 EST
Received: from desiderius by godot.think.com via CHAOS; Fri, 10 Apr 87 12:41:55 EST
Date: Fri, 10 Apr 87 11:42 EST
From: Guy Steele <gls@Think.COM>
Subject: number syntax
To: bartley%home%ti-csl.csnet@relay.cs.net, rrrs-authors@mc.lcs.mit.edu
Cc: gls@think.com
In-Reply-To: <8704092119.AA23970@home>
Message-Id: <870410114254.2.GLS@DESIDERIUS.THINK.COM>
Date: Thu, 9 Apr 87 16:19:28 cdt
From: David Bartley <bartley%home%ti-csl.csnet@relay.cs.net>
Has anyone implemented the -1+2i or 5@7 syntax for complex numbers?
Is there strong resistance to Common Lisp's #c(-1 2) representation?
Actually, I think the #C(1 2) notation is really awful. It was the result
of a compromise--some persons did not want to have to implement hairier
token parsing for complex numbers. Much of the motivation for the notion
of "potential numbers" was to leave the path open for Common Lisp eventually
to adopt such a notation as -1+2i.
--Guy
∂10-Apr-87 1238 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 12:38:05 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Apr 87 15:41:03 EDT
Date: Fri, 10 Apr 87 15:39:27 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: number syntax
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 9 Apr 87 16:19:28 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <182630.870410.CPH@AI.AI.MIT.EDU>
Date: Thu, 9 Apr 87 16:19:28 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Has anyone implemented exactness using a mechanism substantially
different from the one Kent Dybvig describes in his new book?
(Quoting his page 111: "In practice, the internal representation for
an exact quantity is as an integer or ratio, and the internal
representation for an inexact quantity is as a floating point number,
although other representations are possible." Also, "The exactness of
a complex numeric object depends on the exactness of its real and
imaginary parts.") How do people feel about this approach? Does this
fulfill the spirit of exactness? Does anyone want to pay for a more
orthogonal exactness attribute for numbers?
Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
inexact 2 to print as 2.0?
We have not yet implemented exactness.
Has anyone implemented the -1+2i or 5@7 syntax for complex numbers?
Is there strong resistance to Common Lisp's #c(-1 2) representation?
We have implemented this syntax. I don't have strong feelings about this.
∂10-Apr-87 1637 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 16:36:53 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Apr 87 18:48:42 EDT
Date: Fri, 10 Apr 87 18:46:55 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: macros
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 10 Apr 87 10:26:31 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <182704.870410.JAR@AI.AI.MIT.EDU>
Date: Fri, 10 Apr 87 10:26:31 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
-- One or two namespaces or a hybrid?
I think this could coherently go either way. T switched from one
namespace to two after a year or so in order to be compatible with MIT
Scheme. I'll flame about this later if need be.
How do we deal with the fact that both macro/syntax keywords and
variables are drawn from the same set of identifiers? I think
lambda-bound names should take precedence over keywords, but should
LET-SYNTAX-bound keywords take precedence over lambda-bound names of
an outer level?
For symmetry, the answer must be yes.
What about top-level DEFINE? Does (DEFINE X ...), like (LAMBDA (X) ...),
take precedence over keywords?
A harder question. The definition could be an error if X has a keyword
binding in that lexical contour.
What do we do with keywords that appear in places where a keyword is not
expected, like (+ IF AND), and thus appear to be variable references?
Error.
Should we embed syntax tables in the lexical environment or keep them
separate?
This is practically the same as the one versus two namespace question.
I don't know what distinction you're trying to make here.
For those who might prefer a single namespace: should INLINE and other
optimizations be encompassed? How about named constants like PI and
EOF-OBJECT?
No. No.
-- Mutable or immutable syntax tables?
Immutable. Otherwise you get all sorts of obscure bugs and disgusting
semantic questions. The semantic questions remain if an STF (i.e.
expander) can detect or produce side-effects, but every little bit of
sanity helps.
It seems excessively cumbersome to wrap a LET-SYNTAX around a file or
collection of files.
Immutable does not imply LET-SYNTAX. A DEFINE-MACRO-esque for could
work just as well. Simply make DEFINE-MACRO part of the syntax of a
<program> (or perhaps even a <body>. The scope of the macro then starts
at the point the DEFINE-MACRO occurs, and ends at the end of the file,
<program>, or <body>.
Why should extending the syntax differ from the style of incrementally
adding definitions with DEFINE?
Maybe it shouldn't. The main difference is that DEFINE's can be
mutually recursive, whereas you run into all sorts of nasty problems if
you try to make the scope a macro definition include any text that
precedes it. (This is because you have to expand macros in order to
determine whether or not a macro definition is present in the first
place.)
Perhaps INCLUDE is a better answer than LOAD.
Perhaps. This seems like an independent question, however, more
properly discussed under the heading of "modules".
-- Solution of capture problems
Eugene and others have addressed this.
What is the computational complexity of the hygienic expansion
algorithm, by the way?
-- Must a macro expand into an expression--i.e. not a keyword?
Yes.
-- Which syntax table is used by various REPLs, LOAD, COMPILE-FILE, etc.?
The report doesn't talk about REPL's. The syntax table for files should
be the standard one (i.e. the one with only the official bindings in it,
no user bindings). If the file wants to use nonstandard syntax it must
explicitly request them using a DEFINE-MACRO or USE-SYNTAX-TABLE form
which is effective only for that file.
For controlling the REPL's syntax table, you could have something like
(set-current-syntax-table ...). This should have no effect on which
macros are seen by LOAD, however.
-- What about macros that expand into multiple definitions?
No problem: the expansion can be (begin (define ...) (define ...)).
BEGIN behaves like Maclisp's (PROGN 'COMPILE ...).
-- Should a macro writer have the ability to make absolute (that is,
"qualified") references?
I don't see what the alternative is. Otherwise there's no way to write
things like QUASIQUOTE.
-- Should COMPILE-FILE execute any of the forms it compiles?
Yes, the right-hand side of a DEFINE-MACRO or USE-SYNTAX-TABLE, and the
body of an (AT-PREPROCESS-TIME ...).
-- Can we avoid EVAL-WHEN ?
Yes, but we might need something like (AT-PREPROCESS-TIME ...) in order
to make definitions available to expansion procedures.
* * *
How much agreement must we reach to be useful?
-- basic principles?
Deciding how identifiers in programs are resolved as references is a
good start.
The R↑3 report hedges this question, and we may be able to persist in
this.
-- a syntax for >using< macros?
Necessary. There's not much point in defining a macro if you can't use
it.
We're probably wedded to the current syntax that can only distinguish
macros from applications by recognizing keywords.
This is not a problem.
-- a syntax for >defining< macros?
A portable way for defining "global" macros would satisfy many users
and may be easier to reach agreement on than dealing more deeply with
scoping issues. On the other hand, many of us will probably proceed
to implement lexically scoped syntax definitions.
I think scoped macros are absolutely essential. Otherwise there's
absolutely no hope of writing portable code, as Jim Miller has reminded
us.
-- user-friendly syntax for defining macros
Since user-friendly macro definition capabilities tend to have
restricted capabilities, this will probably always be an extension
beyond more primitive capabilities. Perhaps this is a candidate for
the "yellow pages."
Please define user-friendly. I certainly would hope that something that
complicated could be defined as a yellow-pages layer. Obviously no one
would would want to actually write macros using only the low-level
primitives in my proposal. I have implemented something a bit higher
level which, like EXTEND-SYNTAX, uses an input pattern, but unlike
EXTEND-SYNTAX doesn't use an output pattern. But it's not obvious that
everyone will like either my pattern language or Gene's, so I advocate
making the lower-level hooks available as well.
Next time try to come up with some challenging questions.... 8*&
Jonathan
∂10-Apr-87 1646 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU meeting dates/times/places
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 16:46:43 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Apr 87 19:18:21 EDT
Date: Fri, 10 Apr 87 19:17:09 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: meeting dates/times/places
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <182720.870410.JAR@AI.AI.MIT.EDU>
KMP's suggestion that we meet over the weekend of 27-28 June was
seconded by Jinx and assented to by Will. The weekend is fine with me
too. I don't think it will be difficult to find a reasonable room in
which to meet on a weekend, but I'll officially arrange for a room if
possible. Getting into Tech Square is no problem; the lobby doors on
each floor will be locked, but we can probably work something out
(doorbell, a room near a door, or a room somewhere else on the MIT
campus).
If I hear no objections to 27-28 within the next couple weeks, I'll start
looking into this more seriously. Then we can start thinking about what
time of day we want to start on Saturday and Sunday.
****** Let me know if think you might attend so I can determine the optimal
****** room size.
KMP et al. -- is Monday morning a possibilty? If so we could consider
meeting Sunday all day and Monday morning. What time of day will the
X3J13 subcommittees start meeting?
Jonathan.
∂10-Apr-87 1653 @MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 16:53:34 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Apr 87 19:37:25 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ae15584; 10 Apr 87 19:22 EDT
Received: from ti-csl by RELAY.CS.NET id al08455; 10 Apr 87 19:19 AST
Received: from home (home.ARPA) by tilde id AA05738; Fri, 10 Apr 87 17:15:01 cdt
Received: by home id AA13566; Fri, 10 Apr 87 17:13:35 cdt
Date: Fri, 10 Apr 87 17:13:35 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704102213.AA13566@home>
To: jinx%geneva.ai.mit.edu@RELAY.CS.NET
Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: "Guillermo J. Rozas"'s message of Thu, 9 Apr 87 19:11:01 est
Subject: number syntax
> [Bartley:]
> Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
> inexact 2 to print as 2.0?
>
> [Jinx:]
> It depends on the format specification. For the explicit ones, there
> should be no question. I think, however, that if the format is (HEUR)
> it should print as #i2 .
I agree that an inexact integer 2 >should< print as #i2, but is it
permissible to print it as 2.0?
Likewise, is it permissible for the reader to read 2.0 as an inexact
integer 2? May it read #e3.5 as the rational number 7/2 rather than
an "exact" float (whatever that may be)? What I'm leading to is that
any discussion about how to represent numbers that are read in without
benefit of an explicit exactness indicator will have to deal with the
issue of alternative ways to represent exactness.
BTW--How do those that believe in keeping exactness orthogonal to numeric
subtype plan to deal with "exact" reals that are not rational?
--db--
∂10-Apr-87 2103 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Apr 87 21:03:06 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Apr 87 23:56:13 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa19043; 10 Apr 87 23:48 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ae09755; 10 Apr 87 23:41 AST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA21241; Fri, 10 Apr 87 16:19:49 PDT
Received: by tekchips.TEK.COM (5.31/6.19)
id AA07578; Fri, 10 Apr 87 16:18:13 PDT
Message-Id: <8704102318.AA07578@tekchips.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET,
willc%tekchips.tek.com@RELAY.CS.NET, jinx%geneva.ai.mit.edu@RELAY.CS.NET
Subject: Re: number syntax
In-Reply-To: Your message of Thu, 9 Apr 87 19:11:01 est.
<8704100011.AA22486@geneva>
Date: 10 Apr 87 16:18:11 PDT (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Bartley:
Has anyone implemented exactness using a mechanism substantially
different from the one Kent Dybvig describes in his new book?
(Quoting his page 111: "In practice, the internal representation for
an exact quantity is as an integer or ratio, and the internal
representation for an inexact quantity is as a floating point number,
although other representations are possible." Also, "The exactness of
a complex numeric object depends on the exactness of its real and
imaginary parts.") How do people feel about this approach? Does this
fulfill the spirit of exactness? Does anyone want to pay for a more
orthogonal exactness attribute for numbers?
The passage quoted says "integer" and "ratio" and "floating point number"
when the proper R3RS terminology is "fixnum or bignum" and "ratnum" and
"flonum". I feel like I'm being overly picky by pointing this out, since
all of these terms (except integer) are implementation-dependent and the
book describes only Chez Scheme, but Jinx's response shows why precision
is important in words as well as numbers.
Jinx:
That is very much against the proposal. We have not implemented it at
MIT, but the original proposal is such that both exact and inexact
flonums are possible (and desirable), and similarly for the other
types. Although we have not implemented it, we have an implementation
in mind, and it is orthogonal: for each type of number, there is a bit
specifying whether it is exact or not.
I have to disagree with Jinx's first two sentences above. R3RS makes
clear that exact reals and inexact integers are both possible and
desirable, but it says nothing at all about exact flonums and inexact
fixnums. Though their semantics are poorly defined in R3RS, "exact" and
"inexact" are intended to be significant concepts in the language. By
contrast, "flonum" and "fixnum" are names for internal representation
strategies that have no standing in the language. Thus "exact flonum"
is at best an implementation concept, and at worst a category error.
Suppose I implement Scheme (without complex numbers, to keep things
simpler) by representing all numbers as ratnums, augmented by a bit
that tells whether the number is exact or inexact. This is perfectly
legitimate, right? Now suppose people complain about its performance
on certain numerical programs, and my investigations show that the
reason for the poor performance is that it takes too long to add and
to multiply inexact reals. Suppose I tweak my implementation by
arranging for inexact reals to be represented as flonums, augmented
by a bit that tells whether the number is exact or inexact. That's
a perfectly legitimate efficiency hack, right? Suppose I then notice
that the exactness bit for a real represented as a flonum always says
that the real is inexact, because I'm still representing exact reals
as ratnums. So I flush the exactness bit for reals represented as
flonums, because the fact that the real is represented as a flonum
implies that it's inexact. I would be silly not to, right?
If I then add two more efficiency hacks by representing exact integers
as bignums, and by representing small exact integers as fixnums, I
arrive at an implementation similar to that hinted at by Dybvig's book.
Not only do I see nothing wrong with this, it seems the obvious way to
go. In terms of Jinx's remarks, you can be orthogonal at the language
level without being orthogonal at the implementation level.
I would oppose any attempt to mandate particular implementation strategies.
Cadence Research and TI and Tektronix have no more right to impose their
favorite implementation strategy on MIT than MIT has to impose its
favorite strategy on us.
Bartley:
Is it permissible for an exact 3.5 to print (by default) as 7/2 or an
inexact 2 to print as 2.0?
Fine with me. I'm more concerned about whether "7/2" reads as an exact
3.5 and whether "2.0" reads as an inexact 2. The examples in section 6.8
of R3RS are sufficient to imply that "1" and "5" read as exact integers,
assuming that the same reader is used to read both programs and data.
Peace, Will
∂11-Apr-87 0814 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU towards an agenda - yeller pages
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 08:14:24 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Apr 87 11:16:22 EDT
Date: Sat, 11 Apr 87 11:15:02 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: towards an agenda - yeller pages
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 8 Apr 87 15:39:02 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <183040.870411.JAR@AI.AI.MIT.EDU>
I nominate the general topic of "yellow pages" for the agenda, with the
following subtopics:
- what the yellow pages are for
- string manipulation
- bitwise logical operators
- byte vectors (or something a little more general)
- hash tables
- I/O extensions (e.g. READ-LINE, READ-STRING, maybe a simple FORMAT)
- sets ?
- arrays ?
Some thoughts:
By yellow pages I mean a collection of facilities that are implementable
(although not necessarily implemented) in terms of things that are
already in the language. A description of a yellow pages facility should
be accompanied by a sample implementation for two reasons: (1) as a
substitute for a formal specification (which are hard to write); (2) as
an existence proof that the facility is implementable. The informal
description should specify what behavior of the sample implementation is
accidental and what's not (e.g. (PAIR? a-hash-table) might be true in a
sample implementation, but not part of the spec).
If we can figure out modules (packages, whatever) then we might even be
able to get away with keeping these things out of the global
namespace.
If we have an official notion of yellow-page, then we should be able to
demote some of the things that are currently in the main part of the
report (MEMQ, EQUAL?, VECTOR-FILL!). In addition, if we can agree on
macros, most of the derived expression types (with the possible
exception of BEGIN and LETREC) can be similary demoted.
I don't think I like the term "yellow page", but that's another story.
- Jonathan
∂12-Apr-87 1158 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:LISP@BROWNVM.BITNET Scheme85 interpreter from Indiana...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 11:58:25 PDT
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 12 Apr 87 14:39:35 EDT
Received: from BROWNVM(MAILER) by MITVMA (Mailer X1.23) id 9156;
Sun, 12 Apr 87 14:32:12 EDT
Received: by BROWNVM (Mailer X1.23) id 9090; Sun, 12 Apr 87 14:34:44 EDT
Date: Sun, 12 Apr 87 14:30:13 EDT
From: David G. Durand <LISP@BROWNVM>
To: SCHEME@MC.LCS.MIT.EDU
Subject: Scheme85 interpreter from Indiana...
I was interested in ftp-ing the scheme85 source, but the routing tables used on
bitnet seem to be rather old, and we have no way of getting to your node. If
you could send me some mail maybe we can figure something out.
Thanks much,
David G. Durand (LISP@BROWMVM.BITNET (or something like that))
∂12-Apr-87 1724 @MC.LCS.MIT.EDU:harris%hplwhh@hplabs.HP.COM Re: number syntax
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 17:24:20 PDT
Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 12 Apr 87 20:24:38 EDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Sun, 12 Apr 87 16:20:01 pst
Received: from hplwhh (hplwhh) by hplms1; Sun, 12 Apr 87 16:19:39 pst
Return-Path: <harris@hplwhh>
Received: by hplwhh ; Sun, 12 Apr 87 17:19:23 pdt
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
Message-Id: <8704130019.AA04702@hplwhh>
To: jinx@geneva.ai.mit.edu, bartley%home%ti-csl.csnet@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu
X-Mailer: mh
Subject: Re: number syntax
In-Reply-To: Your message of 10 Apr 87 16:18:11 PDT (Fri).
<8704102318.AA07578@tekchips.TEK.COM>
Date: Sun, 12 Apr 87 16:19:17 PST
> ... the original proposal is such that both exact and inexact
> flonums are possible (and desirable), and similarly for the other
> types. Although we have not implemented it, we have an implementation
> in mind, and it is orthogonal: for each type of number, there is a bit
> specifying whether it is exact or not.
In the presence of an exactness indicator bit, I would be all for adding
an exactness indicator to number syntax. This would allow the user to
explicitly specify whether a number is exact or inexact, independent
of its type. For example, one could use:
-3.14, 7/8, 2+7i,
to mean an exact quantities, and:
~-3.14, ~7/8, ~2+7i
to mean inexact quantities. (I use tilde to indicate "approximately" as
opposed to "not" like in C).
This explicit notation would allow exactness to be preserved by coersion
operators:
(float ~7/2) => ~3.5
as well as removing ambiguities from operations such as:
(sqrt 4) => 2
(sqrt ~4) => ~2
(sqrt 4.0) => 2.0 ; this would have been considered inexact
; if all flonums were inexact
(sqrt 3) => ~1.7320508075688772 ; finite precision
(sqrt -4) => 0+2i ; this might have been considered inexact too
∂12-Apr-87 2125 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: meeting dates/times/places
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 21:25:43 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 13 Apr 87 00:26:48 EDT
Received: from relay2.cs.net by RELAY.CS.NET id af12757; 13 Apr 87 0:20 EDT
Received: from northeastern.edu by RELAY.CS.NET id ag20908; 13 Apr 87 0:17 AST
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Sun, 12 Apr 87 23:46 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA08253; Sun, 12 Apr 87 22:36:39 AST
Date: Sun, 12 Apr 87 22:36:39 AST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: JAR@MC.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: meeting dates/times/places
I would prefer not meeting on Saturday, if it is at all possible --Mitch
∂13-Apr-87 0951 @MC.LCS.MIT.EDU:larus@paris.Berkeley.EDU Scheme programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 09:51:35 PDT
Received: from paris.Berkeley.EDU (TCP 20010113056) by MC.LCS.MIT.EDU 13 Apr 87 12:49:19 EDT
Received: by paris.Berkeley.EDU (3.2/1.22)
id AA00188; Mon, 13 Apr 87 09:45:15 PDT
From: larus@paris.Berkeley.EDU (James Larus)
Message-Id: <8704131645.AA00188@paris.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu
Cc: Jonathan A Rees <JAR@ai.ai.mit.edu>
Subject: Scheme programs
Date: Mon, 13 Apr 87 09:45:12 PDT
I'm sure that this question has been asked before (in fact, I
may have asked it a while ago), but I'll ask again.
I am looking for some moderate-sized (< 2,000 lines) Scheme
programs that I can use as input for a program restructurer that I am
writing. I would prefer programs that actually solve a definite
problem and that are not IO bound.
If you know of such a program and are willing to share it,
please send me some mail describing it.
Thanks,
/Jim
∂13-Apr-87 1346 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 13:45:50 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 13 Apr 87 16:23:55 EDT
Date: Mon, 13 Apr 87 15:19:27 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Pattern matching, not optional arguments
RPG: If the strategy is to be able to pass an arbitrary number of arguments,
then a syntax that binds one variable to all of them following by a
pretty destructuring bind of some sort is much better than a
syntax that mixes required with &rest (as Jonathan suggested).
JAR: I agree. In my experience, pattern-matching languages seem to have an
inevitable tendency to become baroque and disgusting. But let's not
stop looking for a decent one.
Me too. Our experience at Indiana is that a relatively simple match
facility goes a long long way. It does not need to complicate the
rest of the language. On the contrary, I think it eliminates any
justification for making lambda baroque and disgusting. Please, let's
make an honest attempt to standardize on a matching facility first,
and only then decide if their is sufficient justification to corrupt
the jewel of Scheme. Given match, we may even be able to polish our
jewel by relegating the "." rest feature to optional or discarded
status.
To fuel the debate, which I hope will have matured by the time of our
next meeting, here is documentation for a match facility that I've
enjoyed using.
-----------------------------
(match <exp> (<pattern> <body> ...) ...)
<pattern> ::= <variable>
| <number> | <string> | (quote <object>)
| (vector <pattern> ...)
| (? <predicate> <pattern>)
| (<pattern> ...)
| (<pattern> <pattern> ... . <pattern>)
Match is a fairly general pattern matching and destructuring facility. <exp>
is evaluated and its value is matched against the <pattern>s in order until a
matching pattern is found. An error is signaled if no pattern matches. When
a match is found, the value of <exp> is destructured with the variables in
the matching pattern bound to the corresponding components of <exp>'s value.
The <body> expressions of the matching pair are then evaluated in an
environment formed by extending the environment of the match expression with
these new bindings. The value of the last <body> expression is returned as
the value of the match expression.
The symbols QUOTE, VECTOR and ? are reserved in patterns to identify
literals, vectors and predicate tests. Numbers, strings and
quoted literal <object>s must be EQUAL? to corresponding components of
<exp>s value, or the pattern fails. <predicate> expressions should evaluate
to unary functions that are applied to the corresponding component of <exp>s
value when matching of the ? pattern is attempted. If the predicate returns
false, the pattern fails. Otherwise, the value applied to the predicate is
matched against the pattern following the predicate.
(match '(2 . 3) ((a . b) (* a b))) ==> 6
(match '(1 2) ((a) a) ((a b) (+ a b)) (c c)) ==> 3
(match (list 33 "string" (vector 1 2))
((33 "string" (vector a b)) (cons a b))) ==> (1 . 2)
(let ((num 3))
(match (cons 'x 4)
(((? (lambda (v) (or (symbol? v) (and (number? v) (= v num))))
c)
. (? number? d)) (list c d)))) ==> (x 4)
(match '(bar 3 4 5)
(('foo x y) (cons x y))
(('bar x y . z) (list x y z))
(else (error "didn't match: " else))) ==> (3 4 5)
-----------------------------
The most questionable feature of this proposal is the predicate
mechanism. I like it, but some others here don't. I'd like to have
others opinions, and would not mind if this feature were dropped.
A more significant issue is how to distinguish literal symbols from
pattern variables. Scheme84 currently had an experimental match
facility that is similar to that above, but without a predicate
mechanism, with an optional else clause (rather than the ELSE variable
hack used above), and with a required list of pattern variables that
eliminated the need for literal quoting. For example, in the current
version of Scheme84 the last example above would have required the pattern
variable list (x y z):
(match '(bar 3 4 . 5) (x y z)
((foo x y) (cons x y))
((bar x y . z) (list x y z))
(else (error "No match"))) ==> (3 4 5)
We found that remembering to update the list of pattern variables when
patterns were changed is a nuisance. Also, the quote mechanism seems
more natural, simpler and more expressive than the pattern variable
list, so we no longer favor the pattern list approach.
I'd be quite happy if there were no other matching or destructuring
facility. In the absense of a multiple value mechanism, I'd favor a
destructuring option for LET, e.g. (let (((x y) (cons 1 2))) ...);
however multiple values eliminates much of the need for this.
If I were writing a system in which many functions had optional
arguments, I would want to write a macro like Jonathan's OPTIONALS,
but that could be done easily with match. In other situations I might
want
(match-lambda pairs ...) ==> (lambda args (match args pairs ...)))
or versions of lambda and let that destructured, but this sort of
thing probably doesn't belong in the standard.
-- Chris Haynes
Dan
∂13-Apr-87 2114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU towards an agenda - yeller pages
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 21:14:18 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Apr 87 23:50:22 EDT
Date: Mon, 13 Apr 87 23:49:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: towards an agenda - yeller pages
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <184057.870413.JAR@AI.AI.MIT.EDU>
[Seems that CSNET had amnesia this weekend, so I'm re-sending this message.
- Jonathan]
Date: Sat, 11 Apr 87 11:15:02 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: towards an agenda - yeller pages
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 8 Apr 87 15:39:02 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <183040.870411.JAR@AI.AI.MIT.EDU>
I nominate the general topic of "yellow pages" for the agenda, with the
following subtopics:
- what the yellow pages are for
- string manipulation
- bitwise logical operators
- byte vectors (or something a little more general)
- hash tables
- I/O extensions (e.g. READ-LINE, READ-STRING, maybe a simple FORMAT)
- sets ?
- arrays ?
Some thoughts:
By yellow pages I mean a collection of facilities that are implementable
(although not necessarily implemented) in terms of things that are
already in the language. A description of a yellow pages facility should
be accompanied by a sample implementation for two reasons: (1) as a
substitute for a formal specification (which are hard to write); (2) as
an existence proof that the facility is implementable. The informal
description should specify what behavior of the sample implementation is
accidental and what's not (e.g. (PAIR? a-hash-table) might be true in a
sample implementation, but not part of the spec).
If we can figure out modules (packages, whatever) then we might even be
able to get away with keeping these things out of the global
namespace.
If we have an official notion of yellow-page, then we should be able to
demote some of the things that are currently in the main part of the
report (MEMQ, EQUAL?, VECTOR-FILL!). In addition, if we can agree on
macros, most of the derived expression types (with the possible
exception of BEGIN and LETREC) can be similary demoted.
I don't think I like the term "yellow page", but that's another story.
- Jonathan
∂13-Apr-87 2343 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu meeting dates
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 23:43:40 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 14 Apr 87 02:34:44 EDT
Date: Tue, 14 Apr 87 01:31:05 est
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Received: by iuvax.cs.indiana.edu; id AA06378; Tue, 14 Apr 87 01:31:05 est
To: rrrs-authors@mc.lcs.mit.edu
Subject: meeting dates
These letters/dates appeared to have arrived but apparently they did not.
/* Written 12:20 am Mar 30, 1987 by dfried@iuvax.cs.indiana.edu in iuvax:scheme-rrrs */
/* ---------- "meeting" ---------- */
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
I agree with Will about getting together. Any time before July 1st
will be very difficult for me
Dan
/* End of text from iuvax:scheme-rrrs */
/* Written 8:48 am Apr 10, 1987 by dfried@iuvax.cs.indiana.edu in iuvax:scheme-rrrs */
/* ---------- "travel plans" ---------- */
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
I need to know the date/dates that we will be meeting asap.
Dan
/* End of text from iuvax:scheme-rrrs */
/* Written 10:22 am Apr 11, 1987 by dfried@iuvax.cs.indiana.edu in iuvax:scheme-rrrs */
/* ---------- "date of meeting" ---------- */
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
I am unable to make a meeting until July.
The first weekend in July would be fine with me.
Dan
/* End of text from iuvax:scheme-rrrs */
-----
Dan
∂14-Apr-87 0048 @MC.LCS.MIT.EDU:mcvax!inria!crcge1.cge.fr!adams@seismo.CSS.GOV Scheme85 interpreter from Indiana...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 00:48:46 PDT
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 14 Apr 87 03:45:26 EDT
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA29142; Tue, 14 Apr 87 03:41:42 EDT
Received: by mcvax.cwi.nl; Tue, 14 Apr 87 09:19:30 +0200 (MET)
Received: by inria.inria.fr; Tue, 14 Apr 87 09:14:01 +0200 (MET)
Date: Tue, 14 Apr 87 09:08:33 -0200
Received: by crcge1.cge.fr, Tue, 14 Apr 87 09:08:33 -0200
From: mcvax!inria!crcge1.cge.fr!adams@seismo.CSS.GOV (Drew Adams)
Message-Id: <8704140708.AA06992@crcge1.cge.fr>
To: BROWNVM.bitnet@mit-multics.arpa, SCHEME@mc.lcs.mit.edu
Subject: Scheme85 interpreter from Indiana...
Voila! Here's some mail. Let me know if you don't receive it :).
∂15-Apr-87 0952 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Pattern matching, not optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:51:56 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Apr 87 12:42:26 EDT
Date: Wed, 15 Apr 87 12:41:00 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Pattern matching, not optional arguments
To: cth@IUCS.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 13 Apr 87 15:19:27 est from Chris Haynes <cth at iucs.cs.indiana.edu>
Message-ID: <185067.870415.JAR@AI.AI.MIT.EDU>
Date: Mon, 13 Apr 87 15:19:27 est
From: Chris Haynes <cth at iucs.cs.indiana.edu>
<pattern> ::= <variable>
| <number> | <string> | (quote <object>)
| (vector <pattern> ...)
| (? <predicate> <pattern>)
| (<pattern> ...)
| (<pattern> <pattern> ... . <pattern>)
Phil Wadler recently complained in SIGPLAN that Scheme has no built-in
pattern matching like ML and its affiliates do. I think there may be
something to what he says. Matching of the ML variety happens a fair
amount in informal notations (e.g. mathematics, denotational
semantics). What you suggest is almost the same as ML's matching
facility, but not quite as elegant. Yours treats lists and vectors
asymmetrically, and doesn't allow for additional constructors without
redefining the macro. You should consider going even closer to ML,
which you could do by changing the last two alternatives to be
| (list <pattern> ...)
| (list* <pattern> <pattern> ... <pattern>)
(In ML you'd write <pattern>,<pattern>,... instead of
(list <pattern> <pattern> ...), and <pattern>::<pattern> instead of
(cons <pattern> <pattern>).)
This eliminates the reserved word problem; it is possible to take a list
apart and name its car VECTOR, and it is possible to make MATCH
understand new kinds of constructors without causing old code to break
due to name conflicts. In fact, if you changed
(? <predicate> <pattern>)
to
((? <predicate>) <pattern>)
then you could change the syntax to be simply
<pattern> ::= <variable>
| <number> | <string> | (quote <object>)
| (<expression> <pattern> ...)
This would permit you to say things like
(let ((widget list)) ...
(match w
((widget wrench connector) ...)))
to take a widget (implemented as a list) apart into its wrench and
connector components, and we have taken another step closer to being
like ML. Giving a semantics for this in Scheme is harder than in ML
since Scheme is a dynamically-typed language with only one namespace,
and ML is statically typed and has four namespaces. The feat can be
accomplished by making MATCH expand into a call to some procedure, call
it MATCH-INTERNAL:
(match x ((exp pat ...) body ...) clause ...) ==>
(let ((z x))
(match-internal exp number-of-pats-following-exp z
(lambda (val ...) (match val ...) ...)
(lambda () (match z clause ...))))
I.e. MATCH-INTERNAL takes the constructor, the number of arguments to
the constructor (i.e. subpatterns), the thing to be matched, and success
and failure continuations. MATCH-INTERNAL then dispatches on the
constructor:
(define (match-internal constructor nargs obj succeed fail)
(cond ((eq? constructor list)
(if (and (list? obj)
(= (length obj) nargs))
(apply succeed obj)
(fail)))
((eq? constructor list*) ...)
((eq? constructor vector) ...)
((?-constructor? constructor)
(if (and (= nargs 1)
((?-predicate constructor) obj))
(succeed obj)
(fail)))
...
(else (error "unknown constructor" ...))))
(define (? pred)
...something which answers true to the ?-constructor? predicate ...)
This the same kind of mechanism as is used for T's equivalent of Common
Lisp's SETF. Like T's SETF, it could be made user-extensible, and
it could be made efficiently compilable.
If it expanded macro forms, then it could also handle QUASIQUOTE with no
extra work (as long as the expansion conatained only constructors that
MATCH-INTERNAL knew about).
By the way, if numbers and strings can be patterns, then booleans and
characters ought to be patterns too.
Jonathan
∂16-Apr-87 1319 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:19:22 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 16 Apr 87 16:21:57 EDT
Date: Thu, 16 Apr 87 15:16:57 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Wed, 15 Apr 87 12:41:00 EDT <185067.870415.JAR@AI.AI.MIT.EDU>
Subject: Pattern matching, not optional arguments
Date: Wed, 15 Apr 87 12:41:00 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Phil Wadler recently complained in SIGPLAN that Scheme has no built-in
pattern matching like ML and its affiliates do. I think there may be
something to what he says.
Yes indeed. Phil's article was one of my motivations to push for
pattern matching (the other was what I saw happening to lambda). Some
of the ways in which Phil finds Miranda superior to Scheme I disagree
with, feeling they are simply different; for example quote. I'd like
to see strong type checking widely used in Scheme, but that is a very
difficult matter. The one respect in which I feel Miranda is clearly
superior, and that we can address with relatively little effort, is
pattern matching.
Yours treats lists and vectors
asymmetrically, and doesn't allow for additional constructors without
redefining the macro. You should consider going even closer to ML,
which you could do by changing the last two alternatives to be
| (list <pattern> ...)
| (list* <pattern> <pattern> ... <pattern>)
Did you mean | (list* <pattern> <pattern> . <pattern>) ?
(In ML you'd write <pattern>,<pattern>,... instead of
(list <pattern> <pattern> ...), and <pattern>::<pattern> instead of
(cons <pattern> <pattern>).)
So let's also add | (cons <pattern> <pattern>), which is the same as
| (list* <pattern> . <pattern>).
This eliminates the reserved word problem; it is possible to take a list
apart and name its car VECTOR, and it is possible to make MATCH
understand new kinds of constructors without causing old code to break
due to name conflicts.
Another way to eliminate the reserved word VECTOR would be to replace
the vector line with
| #(<pattern> ...)
This is consistant with the rest of the approach I took, which is to
have patterns match the print syntax, rather than the construction
expression syntax, as you would have it. (I recall originally wishing
I could use the vector syntax above, but being forced to the VECTOR
keyword syntax because I was working in Scheme84 at the time and it
does not support the standard vector notation. Sorry I neglected to
correct this damage before making the proposal public.)
The use of construction pattern syntax certainly is an alternative worth
consideration. It also has the big advantage that quote becomes
completely consistent with the pattern style; e.g. (list 'x var) is
more natural than ('x var).
The ability to add new constructors in a smooth way if constructor
syntax is used is potentially a big win. But to do it right
(something like the clarification of your proposal below) complicates
the match mechanism substantially. It also makes it clunkier to use
when only lists and vectors are involved, which I expect will be the
vast majority of the time. It's much like the difference between
making things with list and cons vs. using quasiquote. (Actually,
quasiquote might be used to make constructor syntax patterns. Argh!)
If matching is to be much used for such things as optional arguments
(where only lists are involved), the simplicity of the print syntax is
a real plus. It's a hard choice.
In fact, if you changed
(? <predicate> <pattern>)
to
((? <predicate>) <pattern>)
then you could change the syntax to be simply
<pattern> ::= <variable>
| <number> | <string> | (quote <object>)
| (<expression> <pattern> ...)
Then what would be the meaning of the second and subsequent
subpatterns in a pattern of the form ((? <predicate>) <pattern> ...)?
The predicate should see an arbitrary value that can then be
destructured with a single pattern.
This would permit you to say things like
(let ((widget list)) ...
(match w
((widget wrench connector) ...)))
to take a widget (implemented as a list) apart into its wrench and
connector components, and we have taken another step closer to being
like ML. Giving a semantics for this in Scheme is harder than in ML
since Scheme is a dynamically-typed language with only one namespace,
and ML is statically typed and has four namespaces. The feat can be
accomplished by making MATCH expand into a call to some procedure, call
it MATCH-INTERNAL:
(match x ((exp pat ...) body ...) clause ...) ==>
(let ((z x))
(match-internal exp number-of-pats-following-exp z
(lambda (val ...) (match val ...) ...)
(lambda () (match z clause ...))))
The (lambda (val ...) ...) success continuation above doesn't quite
work. The the success continuation should be passed a fail
continuations (the same as the one passed to match-internal), and body
... should be within the scope of the pattern variables in each of the
subpatterns. Match can also be implemented by expanding the tests
inline, which results in considerable code expansion and slower
compilation, but runs faster. We've used both approaches at Indiana.
To provide for user defined constructors, some mechanism is needed for
associating a predicate and destructuring function with each
constructor. This could be done in several ways, such as a global
(hash?)table or using constructor objects that responded to messages
asking for their associated predicate and destructuring functions. If
constructors are regularly created in dynamic ways, the global table
presents garbage collection problems. But let's not get carried away
with implementation concerns at this stage.
In any event, I suggest that the destructuring functions take two
arguments: a function to receive the component values and the value to
be destructured. Thus APPLY would be the list destructuring function.
(lambda (f v) (apply f (vector->list v)))
could be used for vectors, but some implementations might provide a
more efficient version that didn't cons up a list.
If match is to support user supplied constructors, we had better be
convinced that they will be regularly used and that it is important
for them to be abstract. If abstraction isn't critical, one can
always use lists or vectors that begin with certain flags to
distinguish objects created by new constructors. For example, using
this old trick the widget constructor might be
(define widget
(lambda (wrench connector)
(list 'widget wrench connector)))
A widget pattern (in print syntax) would then be
('widget wrench connector)
and no widget destructuring function is needed. Our biggest use of
match so far has been doing this sort of thing to represent abstract
syntax.
By the way, if numbers and strings can be patterns, then booleans and
characters ought to be patterns too.
Yes. This oversight was also a throwback to the original Scheme84
implementation of match.
Jonathan
Chris
∂16-Apr-87 1329 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Pattern matching, not optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:28:40 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 16 Apr 87 16:21:57 EDT
Date: Thu, 16 Apr 87 15:16:57 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Wed, 15 Apr 87 12:41:00 EDT <185067.870415.JAR@AI.AI.MIT.EDU>
Subject: Pattern matching, not optional arguments
Date: Wed, 15 Apr 87 12:41:00 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Phil Wadler recently complained in SIGPLAN that Scheme has no built-in
pattern matching like ML and its affiliates do. I think there may be
something to what he says.
Yes indeed. Phil's article was one of my motivations to push for
pattern matching (the other was what I saw happening to lambda). Some
of the ways in which Phil finds Miranda superior to Scheme I disagree
with, feeling they are simply different; for example quote. I'd like
to see strong type checking widely used in Scheme, but that is a very
difficult matter. The one respect in which I feel Miranda is clearly
superior, and that we can address with relatively little effort, is
pattern matching.
Yours treats lists and vectors
asymmetrically, and doesn't allow for additional constructors without
redefining the macro. You should consider going even closer to ML,
which you could do by changing the last two alternatives to be
| (list <pattern> ...)
| (list* <pattern> <pattern> ... <pattern>)
Did you mean | (list* <pattern> <pattern> . <pattern>) ?
(In ML you'd write <pattern>,<pattern>,... instead of
(list <pattern> <pattern> ...), and <pattern>::<pattern> instead of
(cons <pattern> <pattern>).)
So let's also add | (cons <pattern> <pattern>), which is the same as
| (list* <pattern> . <pattern>).
This eliminates the reserved word problem; it is possible to take a list
apart and name its car VECTOR, and it is possible to make MATCH
understand new kinds of constructors without causing old code to break
due to name conflicts.
Another way to eliminate the reserved word VECTOR would be to replace
the vector line with
| #(<pattern> ...)
This is consistant with the rest of the approach I took, which is to
have patterns match the print syntax, rather than the construction
expression syntax, as you would have it. (I recall originally wishing
I could use the vector syntax above, but being forced to the VECTOR
keyword syntax because I was working in Scheme84 at the time and it
does not support the standard vector notation. Sorry I neglected to
correct this damage before making the proposal public.)
The use of construction pattern syntax certainly is an alternative worth
consideration. It also has the big advantage that quote becomes
completely consistent with the pattern style; e.g. (list 'x var) is
more natural than ('x var).
The ability to add new constructors in a smooth way if constructor
syntax is used is potentially a big win. But to do it right
(something like the clarification of your proposal below) complicates
the match mechanism substantially. It also makes it clunkier to use
when only lists and vectors are involved, which I expect will be the
vast majority of the time. It's much like the difference between
making things with list and cons vs. using quasiquote. (Actually,
quasiquote might be used to make constructor syntax patterns. Argh!)
If matching is to be much used for such things as optional arguments
(where only lists are involved), the simplicity of the print syntax is
a real plus. It's a hard choice.
In fact, if you changed
(? <predicate> <pattern>)
to
((? <predicate>) <pattern>)
then you could change the syntax to be simply
<pattern> ::= <variable>
| <number> | <string> | (quote <object>)
| (<expression> <pattern> ...)
Then what would be the meaning of the second and subsequent
subpatterns in a pattern of the form ((? <predicate>) <pattern> ...)?
The predicate should see an arbitrary value that can then be
destructured with a single pattern.
This would permit you to say things like
(let ((widget list)) ...
(match w
((widget wrench connector) ...)))
to take a widget (implemented as a list) apart into its wrench and
connector components, and we have taken another step closer to being
like ML. Giving a semantics for this in Scheme is harder than in ML
since Scheme is a dynamically-typed language with only one namespace,
and ML is statically typed and has four namespaces. The feat can be
accomplished by making MATCH expand into a call to some procedure, call
it MATCH-INTERNAL:
(match x ((exp pat ...) body ...) clause ...) ==>
(let ((z x))
(match-internal exp number-of-pats-following-exp z
(lambda (val ...) (match val ...) ...)
(lambda () (match z clause ...))))
The (lambda (val ...) ...) success continuation above doesn't quite
work. The the success continuation should be passed a fail
continuations (the same as the one passed to match-internal), and body
... should be within the scope of the pattern variables in each of the
subpatterns. Match can also be implemented by expanding the tests
inline, which results in considerable code expansion and slower
compilation, but runs faster. We've used both approaches at Indiana.
To provide for user defined constructors, some mechanism is needed for
associating a predicate and destructuring function with each
constructor. This could be done in several ways, such as a global
(hash?)table or using constructor objects that responded to messages
asking for their associated predicate and destructuring functions. If
constructors are regularly created in dynamic ways, the global table
presents garbage collection problems. But let's not get carried away
with implementation concerns at this stage.
In any event, I suggest that the destructuring functions take two
arguments: a function to receive the component values and the value to
be destructured. Thus APPLY would be the list destructuring function.
(lambda (f v) (apply f (vector->list v)))
could be used for vectors, but some implementations might provide a
more efficient version that didn't cons up a list.
If match is to support user supplied constructors, we had better be
convinced that they will be regularly used and that it is important
for them to be abstract. If abstraction isn't critical, one can
always use lists or vectors that begin with certain flags to
distinguish objects created by new constructors. For example, using
this old trick the widget constructor might be
(define widget
(lambda (wrench connector)
(list 'widget wrench connector)))
A widget pattern (in print syntax) would then be
('widget wrench connector)
and no widget destructuring function is needed. Our biggest use of
match so far has been doing this sort of thing to represent abstract
syntax.
By the way, if numbers and strings can be patterns, then booleans and
characters ought to be patterns too.
Yes. This oversight was also a throwback to the original Scheme84
implementation of match.
Jonathan
Chris
∂16-Apr-87 1646 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU meeting dates/times
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:46:29 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Apr 87 19:20:35 EDT
Date: Thu, 16 Apr 87 19:19:38 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: meeting dates/times
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <186340.870416.JAR@AI.AI.MIT.EDU>
I have heard from very few of you. Please let me know if you are planning
to attend and whether you have any conflicts.
Two different possibilities are being considered:
A. Saturday - Sunday, 27-28 June.
B. Thursday - Friday, 2-3 July.
So far, the only person who has reported a definite conflict is Dan
Friedman, who absolutely can't make it before July 1.
Other data:
- Mitch Wand would prefer not to meet on Saturday.
- Kent Pitman would prefer not to meet Monday-Friday, but does not
have a definite conflict.
- Friday the 3rd might be difficult for Norman Adams due to approach
of 4th of July.
- Kent Pitman and Bill Rozas have suggested that the approach of the
4th might present problems for some people; I would encourage such
people to speak up now.
I am inclined now to suggest that we meet Thursday-Friday so that we can
accomodate Mitch and Dan.
Please reply with your preferences if you have not done so already.
If you are mute you will be ignored.
Jonathan
∂20-Apr-87 0906 @MC.LCS.MIT.EDU:bartley%Home%ti-csl.csnet@RELAY.CS.NET Re: meeting dates/times
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Apr 87 09:06:18 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 20 Apr 87 11:48:20 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa10812; 20 Apr 87 11:40 EDT
Received: from ti-csl by RELAY.CS.NET id ao16289; 20 Apr 87 11:32 AST
Received: from Nero (nero.ARPA) by tilde id AA08324; Mon, 20 Apr 87 10:30:10 cdt
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: RRRS-Authors@MC.LCS.MIT.EDU
From: David Bartley <bartley%Home%ti-csl.csnet@RELAY.CS.NET>
Subject: Re: meeting dates/times
Date: 20-Apr-87 10:29:18
Sender: BARTLEY%Nero%ti-csl.csnet@RELAY.CS.NET
Message-Id: <BARTLEY.2754923354@Nero>
I'm pretty open to meeting at either end of the week. I hope to attend
the SIGPLAN meeting in St. Paul June 24-26, though, so meeting Saturday
won't work out for me. Although I hesitate to travel on the 4 July
weekend, the Thursday-Friday choice may be best. (I may just plan to
stay in Boston over the weekend!)
--db--
∂22-Apr-87 1357 @MC.LCS.MIT.EDU:unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc Please add ...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 13:57:00 PDT
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 22 Apr 87 15:52:39 EDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA22754; Tue, 21 Apr 87 18:29:35 EDT
Received: by unido.uucp with uucp;
Tue, 21 Apr 87 23:48:28 +0100
Received: by gmdzi.UUCP id AA10066; Tue, 21 Apr 87 21:36:19 -0100
Date: Tue, 21 Apr 87 21:35+0100
From: "Juergen Christoffel" <unido!gmdzi!LISPM-1!JC@seismo.CSS.GOV>
Subject: Please add ...
To: scheme@mc.lcs.mit.edu
Fcc: G1:>JC>mail>mail.kbin
Expiration-Date: Tue, 19 May 87 21:35+0100
Message-Id: <870421213507.3.JC@LISPM-1.GMD>
the address "unido!gmdzi!lispm-1!scheme-gmd"@seismo.css.gov to this
mailing list.
Thank you, JC
∂22-Apr-87 1510 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 15:09:51 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 22 Apr 87 15:55:31 EDT
Date: Wed, 22 Apr 87 14:53:10 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: match questions
Here are some questions that we need to answer before adopting a
matching facility, along with my answers. I hope they generate
debate.
1. Do we want a match facility?
YES, very much so.
2. Given a match facility, do we need optional arguments?
No, but something like OPTIONALS might be in the Yellow Pages.
In fact, we could get demote the '.' rest feature to optional
status, or even eliminate it. (Yeh!)
3. Should patterns be in read format (with quote), e.g. ('x 1 y), or
in construction expression format, e.g. (list 'x 1 y)?
I currently favor read format, but not by much, and if we
can get a satisfactory answer to the next question, I'd
probably favor construction format.
4. Can we define a good way of declaring additional constructors, to
get more of an ML like matching mechanism?
I don't know. Whatever it is, I feel it should simultaniously
define constructor, predicate and destructuring functions.
The obvious approaches I've thought of seem a bit clunky, and
I question whether we want to add that much mechanism to
Scheme. Without this, the matching facility is pretty simple
and does not clutter up the rest of the language. (In fact, it
can eliminate the optional arguments clutter.) Still, it would
be very nice and may well be worth the mechanism. I just
don't want to see resistance to this mechanism nix
agreement on a simpler match facility.
5. Do we want to be able to embed arbitrary predicates in patterns,
and if so, with what syntax?
Yes, but I don't feel strongly about this. The
(? <predicate> <pattern>) syntax I proposed isn't wonderful,
but it does the job. Note that ? (and quote) may still be
used as literals, e.g. ('? 'quote foo). It is only their use
as pattern variables that is prohibited.
6. Should the match facility be an abstraction (lambda) or local
binding (let) form, or should it provide both?
Local binding. A MATCH-LAMBDA form might be optional (I could
certainly imagine wanting it), but it's probably better to
have only one abstraction form, and keep it as simple as
possible. If anyone wants MATCH-LAMBDA badly enough, it is
easy to define given MATCH and any syntactic extension
mechanism.
7. Should MATCH be required, optional, or "Yellow Pages".
Optional, since it is not very hard to implement with required
facilities, we want to keep the required base language
simple, and we want to avoid changes to the base if possible so
existing implementations are not invalidated. "Yellow Pages"
status would be better than nothing, but quite dissapointing.
I think it's a feature that should be widely available and
much used.
It seems hard to come up with definitive answers to some of these
questions. However, I don't see any indication that the issues
here are deep, so we should be able to agree on something satisfactory
without a whole lot of research. So let's try to do it in time for
the July (?) meeting.
Chris
∂22-Apr-87 1746 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 17:45:59 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 22 Apr 87 19:20:15 EDT
Received: by GENEVA.AI.MIT.EDU; Wed, 22 Apr 87 17:39:43 est
Date: Wed, 22 Apr 87 17:39:43 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8704222239.AA05975@geneva>
To: cth@iucs.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Haynes's message of Wed, 22 Apr 87 14:53:10 est <8704222223.AA05964@geneva>
Subject: match questions
Reply-To: jinx@zurich.ai.mit.edu
1. Do we want a match facility?
No. Unless it involves adding no new special forms. I won't
object to a couple of utility procedures in the Yellow pages
for the people who use this sort of thing.
2. Given a match facility, do we need optional arguments?
We don't need them as it is. I'd much rather agree on
something for optional arguments (which I use regularly), than
on some facility I find no use for.
3. Should patterns be in read format (with quote), e.g. ('x 1 y), or
in construction expression format, e.g. (list 'x 1 y)?
I could not care less.
4. Can we define a good way of declaring additional constructors, to
get more of an ML like matching mechanism?
I don't know. Whatever it is, I feel it should simultaniously
define constructor, predicate and destructuring functions.
The obvious approaches I've thought of seem a bit clunky, and
I question whether we want to add that much mechanism to
Scheme.
Adding a match facility is adding too much mechanism as it is.
5. Do we want to be able to embed arbitrary predicates in patterns,
and if so, with what syntax?
I could not care less.
6. Should the match facility be an abstraction (lambda) or local
binding (let) form, or should it provide both?
The only way I'll be happy with it is if it involves no
special forms. Then users can write their own syntactic
extensions to make it convenient if they need it.
7. Should MATCH be required, optional, or "Yellow Pages".
Definitely Yellow Pages if at all.
It seems hard to come up with definitive answers to some of these
questions. However, I don't see any indication that the issues
here are deep, so we should be able to agree on something satisfactory
without a whole lot of research. So let's try to do it in time for
the July (?) meeting.
I'm sorry, but I fail to see the point of a MATCH extension to the
language. Every time I've wanted pattern matching, I've built my own,
because the constraints and requirements were different, so a fixed
utility would do me no good. We might as well try to agree on a UNIFY
facility. It would probably be more useful.
∂23-Apr-87 0957 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 09:57:39 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Apr 87 12:23:04 EDT
Date: Thu, 23 Apr 87 12:24:52 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: match questions
To: cth@IUCS.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 22 Apr 87 14:53:10 est from Chris Haynes <cth at iucs.cs.indiana.edu>
Message-ID: <189657.870423.CPH@AI.AI.MIT.EDU>
I agree with Jinx. A match facility is neither needed nor is it a
desirable addition to the core language. I find optional arguments
useful but unnecessary.
∂23-Apr-87 1143 @MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA Re: match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 11:39:51 PDT
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 23 Apr 87 14:06:57 EDT
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA29550; Thu, 23 Apr 87 11:23:04 PDT
Date: Thu, 23 Apr 87 11:23:04 PDT
From: andy%hobbes@ads.ARPA (Andy Cromarty)
Message-Id: <8704231823.AA29550@hobbes.ads.arpa>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: match questions
I agree with Jinx and CPH. Matching, special handling of optionals, etc.
can be convenient when they happen to provide what you want, but let's get
more experience with matching facilities within Scheme, and more reports
of such experience from more people, before we commit to a specific
construct (if any is needed at all).
If we have a standard macro definition capability, and especially if
we allow any token at all to be redefinable (including, e.g., LET),
then there's no need to build matching facilities into the language
definition. Advocates of alternative matching and destructuring
techniques can build the macro packages and distribute them informally
to entice the rest of us to adopt their view of the importance of
such constructs as a part of the language.
asc
∂23-Apr-87 1324 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET Re: match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 13:24:35 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 Apr 87 15:50:55 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ad20226; 23 Apr 87 15:53 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id bb08194; 23 Apr 87 15:45 AST
Received: by tektronix.TEK.COM (5.51/6.20)
id AA13695; Thu, 23 Apr 87 11:28:07 PDT
Received: by tekchips.TEK.COM (5.31/6.19)
id AA13316; Thu, 23 Apr 87 11:28:52 PDT
Message-Id: <8704231828.AA13316@tekchips.TEK.COM>
To: cth%indiana.csnet@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: match questions
In-Reply-To: Your message of Wed, 22 Apr 87 14:53:10 est.
<8704230115.AA05069@tekchips.TEK.COM>
Date: 23 Apr 87 11:28:50 PDT (Thu)
From: willc%tekchips.tek.com@RELAY.CS.NET
Chris's questions give me a welcome chance to express my personal
views on this matter.
1. Do we want a match facility?
No.
2. Given a match facility, do we need optional arguments?
Yes. Optional arguments are in the standard library already,
and that example encourages people to write new procedures
with optional arguments. The problem is that optional arguments
must now be implemented either by rest arguments, which leads
to poor error-checking because few people take the trouble to
check for excess arguments, or by implementation-specific and
therefore non-portable hacks.
Using rest arguments to implement optional arguments is also
inefficient. The worst of it is that the inefficiency biases
people toward omitting optional arguments, when people should
be encouraged to write them explicitly: WRITE-CHAR with two
arguments conses, but WRITE-CHAR with one argument doesn't. If
you don't think that a single cons per character matters, then
the implementation you've been using isn't fast enough.
I would not be opposed to demoting the "." rest flag to optional
or nonexistent status if it were replaced with #!optional and
#!rest, or equivalent.
3. Should patterns be in read format (with quote), e.g. ('x 1 y), or
in construction expression format, e.g. (list 'x 1 y)?
Read format would be `(X 1 ,Y). The above "read format"
corresponds to no existing syntax. It would be a new sublanguage,
like Common Lisp's FORMAT though less silly.
"Construction expression format" is sensible only if you have a
meaningful notion of static type. Without static types,
patterns based on construction expression format offer all the
embarrassments of Common Lisp's SETF. For example, what would the
pattern (LIST 'X 1 Y) mean inside (LET ((LIST VECTOR)) ...)?
Even if you have static types, construction expression format
generalizes only to free constructors, as even Philip Wadler
observed in the SIGPLAN Notices article that seems to have given
impetus to this particular crusade.
4. Can we define a good way of declaring additional constructors, to
get more of an ML like matching mechanism?
Sure, but first you have to turn Scheme into a statically typed
language. Even then it would only work for free constructors
like CONS, and would not work for constructors like ADJOIN.
An ML-like matcher is far too much machinery when you consider
that it does't generalize beyond a small set of rudimentary data
types.
5. Do we want to be able to embed arbitrary predicates in patterns,
and if so, with what syntax?
No. To paraphrase Marie Antoinette, let them use COND.
6. Should the match facility be an abstraction (lambda) or local
binding (let) form, or should it provide both?
Neither. It would be ok as a library procedure.
7. Should MATCH be required, optional, or "Yellow Pages".
Yellow pages, if at all. Unlike optional arguments, it can
be implemented in terms of what we already have at no cost in
efficiency or reliability. It is not a thing I need, and if
I ever find myself wanting it I'd be happy to include it from
a source library. By the way, I have written perhaps half a
dozen specialized matchers for my own programs, some of them
fairly powerful, but I don't believe the proposed facility would
have saved me from writing any of them. My matchers have generally
been written to simplify the construction of mini-compilers for
application-specific languages.
Thank you for requesting my opinions.
Peace, Will
∂23-Apr-87 1343 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Scheme pattern matcher
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 13:43:26 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 23 Apr 87 16:25:00 EDT
Date: Thu, 23 Apr 87 15:29:04 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: philbin-jim@YALE.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: James F Philbin's message of Thu, 16 Apr 87 17:31:11 EDT <8704162131.AA11569@yale-celray.arpa>
Subject: Scheme pattern matcher
For those who would like to look at and perhaps try out a simple
match facility, here's mine.
The Scheme84 MATCH has a bit different syntax and a very different
implementation, due to Bruce Duba. He uses Eugene's extend-syntax
in clever ways to compile MATCH expressions to conditional expressions
(rather than the interpretive approach I use). It is available via
anonymous ftp as part of pub/scheme84/synstd.s on cs.indiana.edu.
;; match: Chez Scheme pattern matching and destructuring facility.
;;
;; Author: Chris Haynes (haynes@cs.indiana.edu)
;;
;;
;; (match <exp> (<pattern> <body> ...) ...)
;;
;; <pattern> ::= <variable>
;; | <number> | <string> | <character> | <boolean> | (quote <datum>)
;; | #(<pattern> ...)
;; | #&<pattern> ; Chez Scheme box (reference)
;; | (? <predicate> <pattern>)
;; | (<pattern> ...)
;; | (<pattern> <pattern> ... . <pattern>)
;;
;; MATCH is a fairly general pattern matching and destructuring
;; facility. <exp> is evaluated and its value is matched against the
;; <pattern>s in order until a matching pattern is found. An error is
;; signaled if no pattern matches. When a match is found, the value
;; of <exp> is destructured with the variables in the matching pattern
;; bound to the corresponding components of <exp>'s value. The <body>
;; expressions of the matching pair are then evaluated in an
;; environment formed by extending the environment of the MATCH
;; expression with these new bindings. The value of the last <body>
;; expression is returned as the value of the MATCH expression.
;;
;; The symbols QUOTE and ? are used in patterns to identify literals
;; and predicate tests, so they may not be used as pattern variables.
;; Number, string, boolean, character and quoted literal <datum>s must
;; be EQUAL? to corresponding components of <exp>s value, or the
;; pattern fails. <predicate> expressions should evaluate (in the
;; environment of the MATCH expression) to unary functions that are
;; applied to the corresponding component of <exp>s value when
;; matching of the ? pattern is attempted. If the predicate returns
;; false, the pattern fails. Otherwise, the value applied to the
;; predicate is matched against the pattern following the predicate.
;;
;;
;; (match '(2 . 3) ((a . b) (* a b))) ==> 6
;;
;; (match '(1 2) ((a) a) ((a b) (+ a b)) (c c)) ==> 3
;;
;; (match (list 33 "string" #\c (not #t) #(1 2))
;; ((33 "string" #\c #f #(a b)) (cons a b))) ==> (1 . 2)
;;
;; (let ((num 3))
;; (match (cons 'x 4)
;; (((? (lambda (v) (or (symbol? v) (and (number? v) (= v num))))
;; c)
;; . (? number? d)) (list c d)))) ==> (x 4)
;;
;; (match '(bar 3 4 5)
;; (('foo x y) (cons x y))
;; (('bar x y . z) (list x y z))
;; (else (error "didn't match: " else))) ==> (3 4 (5))
;;
(define matcher
(lambda (exp pairs-info)
(if (null? pairs-info)
(error 'match "no pattern for: ~s" exp)
(let ((pat (caar pairs-info))
(fn (cadar pairs-info))
(preds (cddar pairs-info))
(fail (lambda () (matcher exp (cdr pairs-info)))))
(let loop ((exp exp)
(pat pat)
(succeed (lambda (args) (apply fn args))))
(cond
((or (null? pat) (number? pat) (char? pat)
(string? pat) (boolean? pat))
(if (equal? pat exp) (succeed '()) (fail)))
((symbol? pat) (succeed (list exp)))
((box? pat)
(if (box? exp)
(loop (unbox exp) (unbox pat) succeed)
(fail)))
((vector? pat)
(if (vector? exp)
(let ((len (vector-length pat)))
(if (= len (vector-length exp))
(let inner ((n 0) (args '()))
(if (= n len)
(succeed args)
(loop (vector-ref exp n)
(vector-ref pat n)
(lambda (car-args)
(inner (+ 1 n)
(append! args car-args))))))
(fail)))
(fail)))
((eq? (car pat) 'quote)
(if (equal? (cadr pat) exp) (succeed '()) (fail)))
((eq? (car pat) '?)
(if ((car preds) exp)
(begin (set! preds (cdr preds))
(loop exp (caddr pat) succeed))
(fail)))
((pair? exp)
(loop (car exp) (car pat)
(lambda (car-args)
(loop (cdr exp)
(cdr pat)
(lambda (cdr-args)
(succeed (append! car-args
cdr-args)))))))
(else (fail))))))))
(define-macro! match (exp . pairs)
(let ((ids&preds-of
(lambda (pat)
(let* ((preds '())
(ids (let loop ((pat pat))
(cond
((or (null? pat) (number? pat) (char? pat)
(string? pat) (boolean? pat))
'())
((symbol? pat) (list pat))
((box? pat) (loop (unbox pat)))
((vector? pat) (loop (vector->list pat)))
((eq? (car pat) 'quote) '())
((eq? (car pat) '?)
(set! preds (cons (cadr pat) preds))
(loop (caddr pat)))
(else
(let ((cdrids (loop (cdr pat))))
(append! (loop (car pat)) cdrids)))))))
(cons ids preds)))))
`(matcher
,exp
(list . ,(map (lambda (pair)
(let ((pattern (car pair))
(body (cdr pair)))
(let ((ids&preds (ids&preds-of pattern)))
`(cons ',pattern
(cons (lambda ,(car ids&preds) . ,body)
(list . ,(cdr ids&preds)))))))
pairs)))))
∂23-Apr-87 1433 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:33:12 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 23 Apr 87 17:02:54 EDT
Date: Thu, 23 Apr 87 16:20:27 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: match questions
From: "Guillermo J. Rozas" <jinx@geneva.ai.mit.edu>
I'm sorry, but I fail to see the point of a MATCH extension to the
language. Every time I've wanted pattern matching, I've built my own,
because the constraints and requirements were different, so a fixed
utility would do me no good.
My experience, which reflects what I've done with Scheme (I've never
written an emacs), is simply different. I've seldom felt the need for
optional arguments, and never a pressing need for more than the '.'
rest feature we already have. Thus my don't care attitude toward the
optional argument proposals, except for a general desire that all that
mechanism not be added to the language when I don't expect to use it.
But I respect the desires of the many who do use optional arguments,
at least as long as the facility is optional.
What I don't understand is why more people don't find use for MATCH
(or maybe they do, and we just haven't heard from them). I find a
constant need for destructuring (I hate car/cdr chains), and frequent
need for matching. Many a COND expression would look better if it
were a MATCH expression. I, and others here, have found the simple
sort of match facility I've outlined to be quite adequate for almost
all our needs. And people seldom build their own matches, but instead
use car/cdr chains and COND at every turn. The functional programming
community (broadly speaking, including languages like ML) certainly
goes for matching in a big way (and not optional arguments). Why is
the Lisp community traditionally so different?
We might as well try to agree on a UNIFY
facility. It would probably be more useful.
Not at all. Unification requires logic variables, which are a
significant semantic addition to any language (whereas MATCH is
semantically trivial). Also, it isn't clear how much unification is
worth without backtracking (multiple values, Prolog style), and that
is pretty clearly a step into another language.
Chris
∂23-Apr-87 1726 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 17:26:29 PDT
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 23 Apr 87 20:02:16 EDT
Date: Thu 23 Apr 87 15:36:18-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: match questions
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Message from "Chris Haynes <cth@iucs.cs.indiana.edu>" of Thu 23 Apr 87 14:33:37-PDT
Message-ID: <12296897659.45.ANDY@Sushi.Stanford.EDU>
I think that all of the scheme match proposals I've seen during the
last two weeks, as well as Miranda and other languages favored by the
functional programming community and logic programming languages (any
other oxen to gore?), confuse some things that I work very hard to
keep separate. Unfortunately, I don't have a word for them, but I can
illustrate my point with one of Wadler's examples.
He wrote:
treenum ::= Leaf num | Branch treenum treenum
sumtree :: treenum -> num
sumtree (Leaf x) = x
sumtree (Branch xt yt) = sumtree xt + sumtree yt
To my mind, the following commonlispish program is superior. For one
thing, I can change the things that are in a branch without changing
the sumtree program. Note the absense of positional notation/
information.
(defstruct (leaf weight)
(weight number)) ;;; since this is lisp, type decls are optional
(defstruct (branch left right)
(right (or leaf branch))
(left (or leaf branch)))
; This may win the hokiest accessor syntax award but it does
; suggest an obvious extension if multiple values are introduced....
(define (sumtree tree)
(cond ((leaf? tree) (leaf tree weight))
((branch? tree) (+ (sumtree (branch tree left))
(sumtree (branch tree right))))
(else <halt and catch fire>)))
(Yes, some people want to push the cond into the function calling
mechanism but since I usually have procedures with multiple arguments,
I don't like to go that far.)
One "feature" of this idea is that it doesn't support "generic"
information, ie things that are common to a number of different
"type", such as printer, since the accessors specify the "type." This
suggests that T's limited object-oriented style is a big win because
it allows (left tree) to do the right thing even though lots of
"types" have a "left." On the other hand, perhaps common/inherited
components are rare enough that they should be handled via a separate
mechanism.
I agree that T's destructure, and match-like generalizations of it,
are great, but they're for different problems. I'd rather use a
different hammer for compound-object problems.
-andy
-------
∂23-Apr-87 2014 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU The verdict: 27-28 June
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:14:17 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Apr 87 22:54:52 EDT
Date: Thu, 23 Apr 87 23:12:36 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: The verdict: 27-28 June
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <190062.870423.JAR@AI.AI.MIT.EDU>
Many more people seem to dislike 2-3 July than dislike 27-28 June.
Therefore, since no one else seems to be stepping forward to take
responsibility, I have reserved the MIT EECS Dept.'s Grier Room for
9 am to 5 pm on Saturday 27 and Sunday 28 June.
My apologies to those of you who can't make it then. You should feel
free to try to work out a different date with the group if you want; I
certainly have no more claim to authority than anyone else on this
matter, nor do I want it....
Jonathan
∂24-Apr-87 1720 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 17:20:37 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Apr 87 19:53:45 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00914; 24 Apr 87 20:05 EDT
Received: from northeastern.edu by RELAY.CS.NET id ab03143; 24 Apr 87 20:00 AST
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Fri, 24 Apr 87 16:37 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA04605; Fri, 24 Apr 87 10:31:40 AST
Date: Fri, 24 Apr 87 10:31:40 AST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: ANDY@SUSHI.STANFORD.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, cth%indiana.csnet@RELAY.CS.NET
In-Reply-To: "Andy Freeman"'s message of Thu 23 Apr 87 15:36:18-PDT
Subject: match questions
Much as I like pattern matching as proposed by Chris, I think Andy may be on
to something, though I don't completely understand it.
treenum ::= Leaf num | Branch treenum treenum
sumtree :: treenum -> num
sumtree (Leaf x) = x
sumtree (Branch xt yt) = sumtree xt + sumtree yt
To my mind, the following commonlispish program is superior. For one
thing, I can change the things that are in a branch without changing
the sumtree program. Note the absense of positional notation/
information.
(defstruct (leaf weight)
(weight number)) ;;; since this is lisp, type decls are optional
(defstruct (branch left right)
(right (or leaf branch))
(left (or leaf branch)))
; This may win the hokiest accessor syntax award but it does
; suggest an obvious extension if multiple values are introduced....
(define (sumtree tree)
(cond ((leaf? tree) (leaf tree weight))
((branch? tree) (+ (sumtree (branch tree left))
(sumtree (branch tree right))))
(else <halt and catch fire>)))
I guess I don't completely understand this. If I understand it, the second
defstruct exports the following global definitions:
[Let's not argue about the word "global" and what happens if the defstruct
appears in an interior scope, OK?]
branch?
branch
left
right
I guess I don't understand why there is both "branch" and "left/right" here.
If I understand it correctly, I couldn't have another defstruct that had a
different "left". Is that right?
What Chris and I most commonly use matching for is as a rough-and-ready
device for decomposing variant record structures. In general, one needs an
interface between the design of the record structure and the code that uses
that design. There are a number of conflicting design goals:
1. Locality of reference. The code that uses the record should be readable
without reference to a textually-distant definition of the record structure.
2. Control of the namespace. The interface should garbage as little of the
global namespace as possible.
Pattern-matching scores heavily on both these counts; in particular, it
uses no globally named access functions. Andy's proposal seems deficient,
though again I'm not sure I understand it.
3. Modifiability. Changes in the record definition should not require
rewriting the code that uses that definition.
This is where pattern-matching loses: user code must be rewritten whenever
fields are reordered or added. This is where defstruct's (eg Common Lisp's)
are on the right track. Reordering or adding fields does not require recoding
of user functions.
Common Lisp defstruct (and Chez Scheme define-structure) also do pretty well
on the side of not garbaging the global namespace: the names of the access
functions form a distinguished sublanguage (identifiers of the form
structname-fieldname, though I'd probably prefer structname->fieldname), so
the only "really global" identifiers established are structname (and
structname?).
I think it is possible to get something at a higher level than defstruct that
still has the right properties, while increasing locality of reference, but I
haven't figured it out well enough to share it quite yet.
--Mitch
∂24-Apr-87 1854 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 18:54:12 PDT
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 24 Apr 87 21:18:56 EDT
Date: Fri 24 Apr 87 18:22:11-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: match questions
To: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU, cth%indiana.csnet@RELAY.CS.NET
In-Reply-To: Message from "wand%corwin.ccs.northeastern.edu@RELAY.CS.NET" of Fri 24 Apr 87 17:07:43-PDT
Message-ID: <12297190001.12.ANDY@Sushi.Stanford.EDU>
Before I forget. I don't think structures are a counter-proposal to
matchers. They're for problems that matchers aren't the right tool
for and are completely inappropriate for the things that matchers do
best.
Actually, I was serious about the hokey accessor syntax award. I
don't like it, there are lots of better syntaxes, but it does
illustrate my point. The following defstruct only defines a predicate
function and accessor syntax.
(defstruct (branch left right)
(left (or leaf branch))
(right (or leaf branch)))
The predicate is branch? and the accessor syntax "verb" is branch.
(branch tree left) is syntax for accessing the left of tree's value
(which is a branch), but left isn't evaluated. (This order obviously
has problems.) Left is recognized as a field name in that position by
the branch accessor syntax. Other structs can have a left and left
can be used for other purposes without confusion.
Yes, each instance of a struct in my proposal does add three names to
the namespace, but that's independent of the number of fields. (I
didn't mention creators.) On the other hand, one could define a
create syntax, (create branch left x right y), so that no creator name
is added to the namespace. This create would be global syntax that
recognizes struct names and fields. Similar games can be played with
accessor syntax and predicates so that no names are added to the
namespace by a definition. (I think they'd be silly, but ....)
I don't understand the less-local objection. Either you know what you
want out of the struct or you don't. Matchers rely on positional
notation, structures rely on names.
The real bug with my proposal is that any user of a structure can see
everything in it; matchers have this problem too. "private" fields
and the like are the solution, but I don't have a syntax.
-andy
-------
∂26-Apr-87 1256 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Apr 87 12:56:38 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 30002424620) by MC.LCS.MIT.EDU 26 Apr 87 15:56:53 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 124764; Sun 26-Apr-87 15:55:20 EDT
Date: Sun, 26 Apr 87 15:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: match questions
To: cth@iucs.cs.indiana.edu
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: The message of 22 Apr 87 15:53 EDT from Chris Haynes <cth@iucs.cs.indiana.edu>
Message-ID: <870426155448.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
When you say you think we want a matcher, does the "we" refer to Scheme
designers or to Scheme users?
In my experience, users want virtually anything that will save them
work. So any user who's got a matching problem would want a matcher.
Of course, users get to wipe clean their assumptions every time they
start over on a new project so they tend to have a more short-sighted
view of things.
On the other hand, a language designer is pretty much stuck with
anything he puts in his language forever after. For that reason, he must
be more particular.
If you're thinking of adding a match facility to Scheme, you must first
decide at what level you were going to add it.
If you add it as linguistic glue (as, for example, in Prolog), you have
a lot of work ahead of you figuring out how to weave it into the fabric
of the language so that it doesn't end up feeling hastily tacked on.
If you just want to add a tool that isn't integrated at the glue level,
you should be ready to justify why you chose to add that tool and not
the myriad of other possible tools that Common Lisp and company have
adopted while Scheme has steadfastly shunned as contrary to the goals of
a simple and elegant language.
By the way, Jonathan has convinced me that a graceful matcher is
possible so I'm not trying to talk you completely out of it. I just
think there's no good argument for it being anywhere but in the Yellow
Pages unless you're willing to go the extra mile and make the language
really use it at a very low level... and I don't see anyone going that
extra mile (nor do I expect that if they did the others would accept it).
∂27-Apr-87 1241 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU match questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 12:40:55 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Apr 87 15:09:04 EDT
Date: Mon, 27 Apr 87 14:58:50 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: match questions
To: cth@IUCS.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 22 Apr 87 14:53:10 est from Chris Haynes <cth at iucs.cs.indiana.edu>
Message-ID: <191716.870427.JAR@AI.AI.MIT.EDU>
Date: Wed, 22 Apr 87 14:53:10 est
From: Chris Haynes <cth at iucs.cs.indiana.edu>
7. Should MATCH be required, optional, or "Yellow Pages".
Yellow pages. Let's get macros into the language so that this is
possible!
∂28-Apr-87 0645 @MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:MDEBAR@BNANDP11.BITNET Scoops
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87 06:45:40 PDT
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 28 Apr 87 09:43:13 EDT
Received: from BNANDP11(MAILER) by MITVMA (Mailer X1.23) id 9049;
Tue, 28 Apr 87 07:19:43 EDT
Received: by BNANDP11 (Mailer X1.23b) id 6570; Tue, 28 Apr 87 13:18:28 SET
Date: Tue, 28 Apr 87 13:17:20 SET
From: michel debar <MDEBAR@BNANDP11>
Subject: Scoops
To: Scheme <SCHEME@MC.LCS.MIT.EDU>
I would like to get a copy of the doc of Scoops. Could someone send me
a copy ?
Michel Debar
fndp computing centre - rue grandgagnage 21 - 5000 namur - belgium
phone +32 81 220631 telex 59222 facnam b earn:mdebar@bnandp11
∂29-Apr-87 1108 @MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu Engine operating system (long msg)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 11:08:05 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 29 Apr 87 14:04:41 EDT
Date: Wed, 29 Apr 87 12:59:28 est
From: Chris Haynes <cth@iucs.cs.indiana.edu>
To: veracsd.ck@a.isi.edu
Cc: scheme@mc.lcs.mit.edu
Subject: Engine operating system (long msg)
/* ---------- "Concurrency in Scheme" ---------- */
From: VERACSD@a.isi.edu
I am in the process of writing a metacircular Lisp interpreter which
accommodates concurrent programming constructs (e.g. parbegin/parend's
and semaphores) and have recently come across *engines* in PC Scheme.
Engines seem like they offer much potential for this sort of thing,
however, they seem somewhat tricky. It is especially unclear to me
how to elegantly handle waits & signals for semaphores.
(There must be a better way than Ben-Ari's Pascal concurreny simulator.)
Any advice, pointers to sources, or code would be much appreciated.
Cris Kobryn
VERACSD.CK@A.ISI.EDU
I also felt their must be a better way thay the Pascal Concurrency
simulator to expose my operating systems classes to concurrency
problems in a high level language. This helped motivate the design of
engines. Here is a simple engine operating system (dispatcher with
semaphores and a few other primitive process operations) that I give
my class, along with some primitive documentation. I hope you enjoy
them.
Chris Haynes
haynes@iuvax.cs.indiana.edu
-----------------------------------------------------------------------------
SCHEME ENGINE OPERATING SYSTEM
Preliminary Documentation
(Spring, 1987)
Christopher T. Haynes
The engine mechanism is documented in the paper "An abstraction of
timed preemption" by C. T. Haynes and D. P. Friedman, to appear in
Computer Languages and also available as Indiana University Computer
Science Department Technical Report No. 178. This paper outlines a
simple dispatcher, similar to that used in this operating system. The
operating system (actually, it is just a dispatcher with trap handler)
documented here is intended to be as simple as possible, yet still be
useful for solving synchronization problems.
No attempt has been made to make this operating system secure. For
example, only the semaphore implementation should be allowed to issue
a WAIT or SIGNAL trap, but this restriction is not enforced. A more
elaborate operating system with a secure semaphore implementation is
described in an earlier paper by Haynes and Friedman, entitled
"Engines build process abstractions," which appeared in the Conference
Record of the 1984 ACM Symposium on LISP and Functional Programming,
pages 18-24.
This operating system is supplied in its Chez Scheme version, but it
may be easily ported to PC Scheme or Scheme84, the other two Scheme
implementations that provide engines.
To run the operating system (after loading it), use
(boot)
This starts the operating system with a single process that runs the
procedure bound to BOOT-THUNK, which is initially defined to be a
read-eval-print loop with the "os>" prompt. To exit from the
operating system, simply (RESET) or make an error!
Whenever any process reads input, time stops! For example, when the
read-eval-print process reads, all computation stops until an
expression has been read.
(spin <n>)
simply loops <n> times. This is a good way for the read-eval-print
process to kill time and let other processes run.
There are two ways to create additional processes.
(parbegin <exp1> ... <expn>)
creates n processes which evaluate <exp1> ... <expn> in parallel while
the parent process (the one that evaluated the PARBEGIN expression) is
blocked, and remains blocked until all the new processes finish
evaluating their expressions and terminate.
(trap 'fork <thunk>)
creates a new process that thaws <thunk>. The thunk should never
return; if it does you get the error message "process tried to
return". The fork operation returns a process object.
(trap 'block <p>)
and
(trap 'unblock <p>)
respectively block and unblock the process associated with process
object <p>.
(trap 'self)
returns the process object of the current proces.
(trap 'pause)
causes the current process to relinquish the rest of its time slice.
Semaphores are the synchronization mechanism of this operating system.
(make-semaphore <n>)
returns a new (general) semaphore with initial value <n>. Semaphores are
objects that respond to the messages WAIT and SIGNAL. That is, if <s>
is a semaphore, then
(<s> 'signal)
and
(<s> 'wait)
are the usual semaphore operations.
The time slice size (in engine ticks) is determined with each
dispatch by thawing the thunk bound to TIME-SLICE. Decreasing the
time slice trades off efficiency for a higher probability of finding
synchronization bugs. Randomness in the time slice increases the
chance of finding bugs by repeating the same test programs, but means
that bugs may not repeatable. Initially, TIME-SLICE is defined to be
(lambda () (+ 5 (random 10))))
The variable DISPATCH-COUNT is incremented with each dispatch. This
provides processes with a crude measure of time.
Assume the file "demo.ss", which follows, has been loaded.
(define time-slice
(lambda () (+ 1 (random 2))))
(define inc-count
(lambda (n)
(recur loop ((n n))
(when (positive? n)
(set!! count (1+ count))
(loop (- n 1))))))
(define count 0)
(define demo
(lambda ()
(set! count 0)
(parbegin (inc-count 100) (inc-count 100))
count))
(define grind
(lambda (x n)
(trap 'fork
(lambda ()
(recur loop ()
(display x)
(flush-output *standard-output*)
(spin n)
(loop))))))
(define a nil)
(define b nil)
(define c nil)
(define s nil)
(define abc
(lambda ()
(set! a (grind 'a 10))
(set! b (grind 'b 20))
(set! c (grind 'c 30))
(set! s (trap 'self))))
We then obtain the following transcript:
> (boot)
os> (demo)
121
os> (demo)
115
os> (abc)
abc#<closure>
os> (spin 50)
aabacaba()
os> (trap 'block a)
*
os> (spin 50)
bcb()
cos> (trap 'block b)
*
os> (spin 100)
ccc()
os> (trap 'unblock b)
b*
os> (spin 100)
cbcbcbb()
os> (reset)
>
When programming in this system using Chez Scheme, use the mutation
operators SET!!, SET-CAR!!, SET-CDR!!, SWAP-BOX!!, SET-BOX!! and
SET-VECTOR!! (instead of the single bang versions) in order to have
more opportunity of discovering synchronization bugs.
Ready processes are maintained in a ring data structure, and processes
blocked on semaphores are kept in queues that are also made of rings.
Processes are ring objects created by MAKE-RING.
MAKE-RING takes a single argument and returns a ring element whose
initial value is the argument value. A ring is a doubly linked
circular list, which may be referenced by any one of its elements. A
ring element, r, respond to messages as follows:
value Returns the current value of r.
set-value! Returns a function that takes a value and makes it the
new value of r.
singleton? Returns true if r is a singleton--a single element ring,
and false otherwise.
left Returns the element to the left of r in the ring.
right Returns the element to the right of r in the ring.
delete! Deletes r, which must not be a singleton, from the ring.
r then becomes a singleton.
insert-left! Returns a function that takes a ring element, which must be
a singleton, and inserts it in the ring to the left of r.
insert-right! Returns a function that takes a ring element, which must be
a singleton, and inserts it in the ring to the left of r.
MAKE-QUEUE is a function of no arguments that returns a new queue
object. Queues are implemented as rings with a distinguished
element, the mark, that separates the head and tail of the queue. A
queue object, q, responds to the following messages as follows:
enq! Returns a functions that takes a ring element and inserts
it at the tail of the queue.
deq! Removes a ring element from the head of the queue and
returns it.
empty? Returns true if the queue is empty, and false otherwise.
-----------------------------------------------------------------------------
;;; Engine Operting System
;;;
;;; Chez Scheme Verion, Spring 1987.
;;;
;;; Author: Chris Haynes (haynes@iuvax.cs.indiana.edu)
;;;
(define-macro! set!! (name value) `(set! ,name (I ,value)))
(define-macro! parbegin exps
`(parbegin-thunks (list . ,(map (lambda (exp) `(lambda () ,exp))
exps))))
(define set-car!! (lambda (pair obj) (set-car! pair obj)))
(define set-cdr!! (lambda (pair obj) (set-cdr! pair obj)))
(define swap-box!! (lambda (box obj) (swap-box! box obj)))
(define set-box!! (lambda (box obj) (set-box! box obj)))
(define vector-set!! (lambda (vector n obj) (vector-set! vector n obj)))
(define I (lambda (x) x))
(define make-ring
(let ((singleton? (lambda (elt) (eq? (cadr elt) elt)))
(key (box 'unique)))
(lambda (value)
(let* ((elt (cons '* '*))
(cdr-elt (cons elt elt)))
(set-cdr!! elt cdr-elt)
(set-car!! elt
(lambda (msg)
(if (eq? msg key)
elt
(case msg
(value value)
(set-value! (lambda (x) (set!! value x)))
(singleton? (singleton? elt))
(left (caar cdr-elt))
(right (cadr cdr-elt))
(delete!
(if (singleton? elt)
(error 'make-ring
"can't delete singleton ring")
(begin
(set-cdr!! (cdar cdr-elt) (cdr cdr-elt))
(set-car!! (cddr cdr-elt) (car cdr-elt))
(set-cdr!! cdr-elt elt)
(set-car!! cdr-elt elt)
'*)))
(insert-left!
(lambda (ring)
(if (ring 'singleton?)
(let ((elt2 (ring key)))
(set-car!! (cdr elt2) (car cdr-elt))
(set-cdr!! (cdr elt2) elt)
(set-cdr!! (cdar cdr-elt) elt2)
(set-car!! cdr-elt elt2)
'*)
(error 'make-ring
"can't insert non-singleton"))))
(insert-right!
(lambda (ring)
(if (ring 'singleton?)
(let ((elt2 (ring key)))
(set-car!! (cdr elt2) elt)
(set-cdr!! (cdr elt2) (cdr cdr-elt))
(set-car!! (cddr cdr-elt) elt2)
(set-cdr!! cdr-elt elt2)
'*)
(error 'make-ring
"can't insert non-singleton"))))
(else (ferror 'make-ring
"bad message to ring: ~a" msg))))))
(car elt)))))
(define make-queue
(lambda ()
(let ((mark (make-ring '())))
(lambda (msg)
(case msg
(enq! (mark 'insert-left!))
(deq! (if (mark 'singleton?)
(error 'make-queue "can't dequeue from empty queue")
(let ((r (mark 'right)))
(r 'delete!)
r)))
(empty? (mark 'singleton?))
(else (ferror 'make-queue "bad message to queue: ~a" msg)))))))
(define running #f)
(define dispatch-count 0)
(define dispatch
(letrec ((k-pt car)
(args-pt cdr)
(fail (lambda (eng) eng))
(success (lambda (trap-val ticks-remaining)
(let* ((ans (apply trap-handler (args-pt trap-val)))
(new-engine (make-engine
(lambda ()
((k-pt trap-val) ans)))))
(if pause
(begin (set! pause #!false)
new-engine)
(new-engine ticks-remaining success fail))))))
(lambda ()
(set! dispatch-count (+ 1 dispatch-count))
(set! running (running 'right))
(let ((set-engine! (running 'set-value!)))
(set-engine! ((running 'value) (time-slice) success fail))
(dispatch)))))
(define pause #!false)
(define time-slice
(lambda ()
(+ 5 (random 10))))
(define os-read
(lambda ()
(let loop ()
(let ((value (read)))
(if (eof-object? value)
(begin (trap 'pause) (loop))
value)))))
(define read-eval-print
(lambda (prompt)
(let loop ()
(display prompt)
(display " ")
(write (eval (read)))
(newline)
(loop))))
(define boot-thunk
(lambda ()
(read-eval-print "os>")))
(define boot
(lambda ()
(set! dispatch-count 0)
(set! running (make-ring (make-engine boot-thunk)))
(dispatch)))
(define spin
(lambda (n)
(when (not (zero? n))
(spin (- n 1)))))
(define trap
(lambda args
(call/cc
(lambda (k)
(engine-return (cons k args))))))
(define trap-handler
(rec trap
(lambda args
(let ((trap-type (car args))
(arg1 (when (not (null? (cdr args))) (cadr args))))
(case trap-type
(unblock ((running 'insert-left!) arg1) '*)
(block (when (eq? running arg1)
(if (running 'singleton?)
(begin (error 'trap-handler "DEADLOCK")
(boot))
(begin (set! running (running 'left))
(set! pause #!true))))
(arg1 'delete!)
'*)
(fork (let ((pcb (make-ring
(make-engine
(lambda ()
(arg1)
(error 'trap-handler
"process tried to return"))))))
((running 'insert-left!) pcb)
pcb))
(pause (set! pause #!true))
(self running)
(wait (let ((↑value arg1) (queue (caddr args)))
(set-box! ↑value (- (unbox ↑value) 1))
(when (negative? (unbox ↑value))
(let ((self (trap 'self)))
(trap 'block self)
((queue 'enq!) self)))
'*))
(signal (let ((↑value arg1) (queue (caddr args)))
(set-box! ↑value (+ 1 (unbox ↑value)))
(when (not (positive? (unbox ↑value)))
(trap 'unblock (queue 'deq!)))))
(else (ferror 'trap-handler "bad trap arguments: ~a" args)
(reset)))))))
(define make-semaphore
(lambda (count)
(let ((↑value (box count))
(queue (make-queue)))
(lambda (msg)
(case msg
(wait (trap 'wait ↑value queue))
(signal (trap 'signal ↑value queue))
(empty? (queue 'empty?)))))))
(define parbegin-thunks
(lambda (thunks)
(let ((n (length thunks))
(mutex (make-semaphore 1))
(done (make-semaphore 0)))
(for-each (lambda (thunk)
(trap 'fork
(lambda ()
(thunk)
(mutex 'wait)
(set!! n (- n 1))
(when (zero? n) (done 'signal))
(mutex 'signal)
(trap 'block (trap 'self)))))
thunks)
(done 'wait))))
∂30-Apr-87 1603 @MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET another set of primitives for concurrency
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 16:03:31 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Apr 87 18:51:54 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa12445; 30 Apr 87 18:44 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ab16539; 30 Apr 87 18:39 EDT
Received: by tektronix.TEK.COM (5.51/6.20)
id AA25359; Thu, 30 Apr 87 13:16:32 PDT
Received: by tekchips.TEK.COM (5.31/6.19)
id AA15776; Thu, 30 Apr 87 13:17:27 PDT
Message-Id: <8704302017.AA15776@tekchips.TEK.COM>
To: Scheme@MC.LCS.MIT.EDU
Subject: another set of primitives for concurrency
Date: 30 Apr 87 13:17:25 PDT (Thu)
From: willc%tekchips.tek.com@RELAY.CS.NET
For comparison with Chris Haynes's posting of the Scheme engine
operating system, here is a quick description of the concurrency
primitives used in MacScheme+Toolsmith. They aren't as useful
as engines for writing a metacircular interpreter, however.
To use the concurrency features, you have to say
(begin-tasking)
You can say
(end-tasking)
to disable scheduling. The END-TASKING procedure doesn't kill any
tasks, so you can resume scheduling by calling BEGIN-TASKING again.
A RESET will kill all tasks and disable tasking. If an error occurs,
tasking continues while you're in the debugger, but if you quit out
of the debugger (instead of fixing the error and resuming) then a
RESET will be performed.
If a task reads from the keyboard when no characters are available,
a task switch occurs so another task can run while the one is waiting
for input. Tasks with time on their hands, such as a background task
that is monitoring the position of the mouse, can call
(surrender-timeslice)
to let some other task do something productive in the meantime. The
approximate size of a time slice is determined by a global variable.
Tasks are created and run by
(start-task <thunk>)
The <thunk> is called with no arguments and runs as a concurrent task.
The value returned by START-TASK is a task object. The task object
dies when <thunk> returns, or when someone calls KILL-TASKS on it:
(kill-tasks <task1> ...)
or when the task calls KILL-CURRENT-TASK. If all tasks die, then a
RESET is performed.
There is no hierarchy of tasks. Thus killing a task does not kill
tasks created by that task.
Synchronization is performed using side effects and
(call-without-interrupts <thunk>)
which calls <thunk> as an atomic action. The atomic action ends when
<thunk> returns.
Interrupts are also executed uninterruptibly (with certain exceptions,
such as when the debugger is called as the result of an error). The
interrupt system is programmable, with dynamically installed handlers
written in Scheme, but that's another discussion. The main use of
interrupts is to implement interactive objects such as windows as part
of the Macintosh user interface.
Scheme source for the task scheduler and interrupt system is supplied
with MacScheme+Toolsmith.
Peace, William Clinger
∂30-Apr-87 1928 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu environment networks
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 19:28:31 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 30 Apr 87 22:25:25 EDT
Received: by linc.cis.upenn.edu
id AA00580; Thu, 30 Apr 87 22:23:34 EDT
Date: Thu, 30 Apr 87 22:23:34 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Thu, 30 Apr 87 22:23:34 EDT
Message-Id: <8705010223.AA00580@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: environment networks
I need to know how I might sandwich an arbitrary environment
between two another environments dynamically. I am presently
finishing up the translation of TI's SCOOPS object oriented
programming system, and I want to eliminate code walk-throughs
entirely. Being able to let a class environment point to
the instance variables in another environment is desirable.
I think the cleanest way to do that is by changing the parent
of the class environment during the run of the program.
Please send any suggestions/solutions to
sherin@linc.cis.upenn.edu.arpa
Thanks.
∂09-May-87 1206 @MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU Re: Engine operating system (long msg)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87 12:06:17 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 9 May 87 14:52:03 EDT
Date: 9 May 1987 14:50-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Re: Engine operating system (long msg)
From: VERACSD@A.ISI.EDU
To: cth@IUCS.CS.INDIANA.EDU
Cc: scheme@MC.LCS.MIT.EDU
Message-ID: <[A.ISI.EDU] 9-May-87 14:50:30.VERACSD>
In-Reply-To: The message of Wed, 29 Apr 87 12:59:28 est from Chris Haynes <cth@iucs.cs.indiana.edu>
Chris,
Thanks very much for sharing your Scheme code to simulate concurrency.
This is very useful to me. (Your operating systems classes are extremely
fortunate. )
Cris Kobryn
VERACSD.CK@A.ISI.EDU
∂14-May-87 1244 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Scheme for lisp machines
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 12:44:20 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 14 May 87 15:18:11 EDT
Date: 14 May 1987 15:13:37 EDT
Subject: Scheme for lisp machines
From: Morris Katz <MKATZ@A.ISI.EDU>
To: scheme@MC.LCS.MIT.EDU
Does anyone know of any versions of scheme for either Symbolics or TI
Lisp machines. Any info would be greatly appreciated.
Morry Katz
mkatz@a.isi.edu
-------
∂18-May-87 1745 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 17:45:43 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 May 87 20:25:42 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa09388; 18 May 87 20:18 EDT
Received: from ti-csl by RELAY.CS.NET id aa12336; 18 May 87 20:15 EDT
Received: by tilde id AA03760; Mon, 18 May 87 17:38:55 CDT
Received: by home id AA17077; Mon, 18 May 87 17:38:47 cdt
Date: Mon, 18 May 87 17:38:47 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8705182238.AA17077@home>
To: RRRS-Authors@mc.lcs.mit.edu
Subject: Should ":" be an extended alphabetic character?
This has come up before, but not in the context of the current
standardization cycle.
The ":" character is defined in 2.1 of R3RS to be one of the extended
alphabetic characters and thus a valid constituent of a Scheme
identifier. This is a minor inconvenience to those of us who would
like to carry over the C*mm*n Lisp notation for package qualifiers
into Scheme implementations that are either based on C*mm*n Lisp or
otherwise coresident with C*mm*n Lisp.
What to do?
(1) Convince everyone that ":" should not be an extended alphabetic
character.
(2) Allow users to declare which meaning of ":" is to be used (e.g.,
on a file by file basis).
(3) Leave ":" alone and use a different notation for package qualifiers.
Is there any hope for #1? Is #2 acceptable? Any suggestions for #3?
Has anyone else faced this problem?
[Note: I am not advocating packages. I hate them. I'm merely
concerned that I find a reasonable way to live with them when
procedures in the two languages need to talk to each other.]
--db--
∂18-May-87 1910 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 19:10:15 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 May 87 22:05:32 EDT
Date: Mon, 18 May 87 21:04:26 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Received: by iuvax.cs.indiana.edu; id AA10631; Mon, 18 May 87 21:04:26 est
To: RRRS-Authors@mc.lcs.mit.edu, bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: Re: Should ":" be an extended alphabetic character?
I remember resolving to remove ":" from the set of extended alphabetic
characters, but apparently I was wrong...the report does indeed say that
":" is an extended alphabetic character. I would (again) vote that it
be removed from this set. One of our stated goals (which we of course
fall short of in other cases) is to avoid gratuitous incompatibilities
with Common Lisp. Removing it means only that portable programs should
not use it, not that we are planning to standardize on packages!
∂18-May-87 1929 @MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA Re: Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 19:29:40 PDT
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU 18 May 87 22:12:41 EDT
Received: from ads.ARPA (ads.arpa.ARPA) by grape.ads.ARPA (4.12/4.7)
id AA14446; Mon, 18 May 87 18:30:22 pdt
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA04880; Mon, 18 May 87 18:31:21 PDT
Date: Mon, 18 May 87 18:31:21 PDT
From: andy%hobbes@ads.ARPA (Andy Cromarty)
Message-Id: <8705190131.AA04880@hobbes.ads.arpa>
To: RRRS-Authors@mc.lcs.mit.edu
Subject: Re: Should ":" be an extended alphabetic character?
Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET
Reply-To: andy@ADS.arpa
We have experienced little difficulty with Common LISP -> R3RS
code ports, precisely because ":" is an extended alphabetic character.
I advocate leaving it this way.
That is, (cons foo:x (list 3)) is meaningful and well-defined as an
operation on the unique variable named "foo:x" in both Scheme and
Common LISP, for the obvious reasons, and in nearly all cases we've
encountered, it ports cleanly without any additional attention or concern.
The cleanliness of this porting task is a function of the uniqueness of
colon-qualified symbols in Scheme, which in turn is in a sense guaranteed
by the very property of ":" being extended-alphabetic.
We have implemented a macro packages, using our local definition of
"macro", to map just enough of the Common LISP package system's
constructs into Scheme so as to permit CL code to run, without making
it desirable to use this pseudo-package kludge when writing new code.
(In my view, discouraging package use in this manner is an important
design feature of this approach.)
asc
p.s. If you want to worry about ":" and Common LISP code ports, worry
about keywords. The only simple way to get your CL code to work
in Scheme (as far as we've been able to see so far) is to quote
all CL keywords -- which, fortuitously, happens to work, since (1)
':foo = :foo in CL and (2) R3RS doesn't contain (SYM)EVAL. But
it does require either alteration of the CL source or preprocessing
of the source before/during loading into the Scheme environment.
∂19-May-87 0654 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 06:54:11 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 19 May 87 09:52:57 EDT
Received: by GENEVA.AI.MIT.EDU; Tue, 19 May 87 08:25:28 edt
Date: Tue, 19 May 87 08:25:28 edt
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8705191225.AA07690@geneva>
To: andy@ADS.arpa
Cc: RRRS-Authors@mc.lcs.mit.edu, bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: Andy Cromarty's message of Mon, 18 May 87 18:31:21 PDT <8705190131.AA04880@hobbes.ads.arpa>
Subject: Should ":" be an extended alphabetic character?
Reply-To: jinx@zurich.ai.mit.edu
I don't think the issue here is porting code from one language to
another, but rather to have implementations of both languages coexist
in a single Lisp environment, so that procedures written in one or the
other are mutually "callable".
I suspect the problem arises when Scheme symbols reside in a Common
Lisp package (called scheme ?) which is part of the startup set of
packages. Then Scheme code would have a hard time referencing
variables (or invoking procedures) whose names belong to packages
which are not in the "current" inheritance chain. CL code would also
have a hard time referencing Scheme variables (or invoking Scheme
procedures) whose name had a ':' character. Note that the
interpretation of ':' at read time is not really an issue, since the
reader could be conditionalized according to the language being read.
If the above is a correct statement of the problem, there are two
possibilities:
1) Remove ':' from Scheme. The Scheme reader could then treat ':' the
same way as the CL reader, and intern the symbol in the right place.
What it would do with the function/value distinction in that package
is quite a different matter.
2) Add some non-standard reader-syntax which allows mutual references.
For example, assuming that #: is not a predefined reader macro in CL
(there are so many, I don't know which mean anything and which do not),
#:foo in CL would specify scheme:foo, and #:foo:bar in CL would be the
symbol in the scheme package whose print name is foo:bar. Similarly
#:foo in Scheme would represent the CL symbol foo (in user ?), while
#:foo:bar in Scheme would be the way to type the CL symbol bar in
package foo.
Although I like to use ':' in my identifiers, I really don't care much
either way. I'm just worried about gratuituous compatibilities with
CL caused by features of CL which I consider distasteful.
∂19-May-87 0818 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 08:18:37 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 May 87 11:17:03 EDT
Date: Tue, 19 May 87 11:17:01 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Should ":" be an extended alphabetic character?
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 18 May 87 17:38:47 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <202163.870519.JAR@AI.AI.MIT.EDU>
Date: Mon, 18 May 87 17:38:47 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
To: RRRS-Authors at mc.lcs.mit.edu
Re: Should ":" be an extended alphabetic character?
I have no opinion on this. When it came up before, there were some
objections to removing : from the list of extended alphabetics, and as
editor I took the "conservative" stance of making minimal changes to the
report.
I have no strong opinion on this question. I wouldn't be sad to see :
classified with / | [ ] { }. In fact such a change would reduce
by one the number of bugs in my implementation (pseudoscheme).
∂19-May-87 0918 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 09:18:41 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 87 12:16:22 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa16101; 19 May 87 12:07 EDT
Received: from ti-csl by RELAY.CS.NET id ab17227; 19 May 87 12:02 EDT
Received: by tilde id AA16633; Tue, 19 May 87 09:33:05 CDT
Received: by home id AA26570; Tue, 19 May 87 09:33:02 cdt
Date: Tue, 19 May 87 09:33:02 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8705191433.AA26570@home>
To: andy@ADS.ARPA
Cc: RRRS-Authors@mc.lcs.mit.edu, Bartley%home%ti-csl.csnet@RELAY.CS.NET
In-Reply-To: Andy Cromarty's message of Mon, 18 May 87 18:31:21 PDT <8705190131.AA04880@hobbes.ads.arpa>
Subject: Should ":" be an extended alphabetic character?
> We have experienced little difficulty with Common LISP -> R3RS
> code ports, precisely because ":" is an extended alphabetic character.
> I advocate leaving it this way.
My problem is not porting code written in Common Lisp over to Scheme.
Leaving ":" as a constituent certainly works well for that purpose.
My problem is implementing the two languages in a single shared
namespace. Procedures written in either language will be exposed to
symbols read by the other's reader.
--db--
∂19-May-87 1645 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 16:45:37 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 87 19:09:13 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab20747; 19 May 87 18:47 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ad19307; 19 May 87 18:41 EDT
Received: by tektronix.TEK.COM (5.51/6.21)
id AA01520; Tue, 19 May 87 13:20:35 PDT
Received: by tekchips.TEK.COM (5.51/6.19)
id AA22634; Tue, 19 May 87 13:02:51 PDT
Message-Id: <8705192002.AA22634@tekchips.TEK.COM>
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: RRRS-Authors@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: Should ":" be an extended alphabetic character?
In-Reply-To: Your message of Mon, 18 May 87 17:38:47 cdt.
<8705182238.AA17077@home>
Date: 19 May 87 13:02:47 PDT (Tue)
From: willc%tekchips.tek.com@RELAY.CS.NET
I'm willing to be convinced otherwise, but right now I'm in favor of
leaving ":" as an extended alphabetic character. Maybe somebody should
explain to me how banning ":" would help. Here's how I see it:
When porting Scheme code to Common Lisp (a thing few of us really want
to do), you can pretty much get away with replacing all occurrences of
":" by a character that's illegal in Scheme but a constituent in Common
Lisp, such as "[".
When porting Common Lisp code to Scheme, there are several problems
you can have with symbols and packages:
1. Symbols in the keyword package. You can pretty much get by
with making ":" into a non-terminating macro character so that
:FOO turns into (QUOTE FOO). My apologies for not having the
customizable reader proposal out yet; you can do fairly well
without a customizable reader by replacing all occurrences of
" :" by " '".
2. Qualified symbols that are not in the USER package. Since ":"
is an extended alphabetic character in Scheme, you can just
leave these alone.
3. Qualified symbols that are in the USER package. Here you
lose, unless the symbol is qualified wherever it appears.
I would think, though, that even the Common Lisp community
considers it poor style to intermix USER:FOO and FOO within
the same file.
4. Unqualified symbols that are in the USER package. You can
leave these alone.
5. Unqualified symbols that are not in the USER package. Here
you lose big, but there's no way to avoid losing big without
adding a package system to Scheme. I know you can use
environments to fake some things, but a silk purse is a
poor substitute for the sow's ear.
The most severe problems come from unqualified symbols (5), so I don't
see how banning ":" from Scheme identifiers would help. To the contrary,
banning ":" would definitely cause new problems with qualified symbols (2).
On the other hand, I've never converted any Common Lisp code that made
significant use of packages so I don't know what I'm talking about.
Peace, Will
∂19-May-87 2117 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU Should ":" be an extended alphabetic character?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 21:17:14 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 May 87 00:15:36 EDT
Date: Wed, 20 May 87 00:15:53 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Should ":" be an extended alphabetic character?
To: RRRS-Authors@MC.LCS.MIT.EDU
Message-ID: <202573.870520.ALAN@AI.AI.MIT.EDU>
By my reading of the Thrice Revised Report, in implementations that truely
support ":" as an extended alphabetic character it should be the case
that:
(eq? 'user:cons 'lisp:cons) => #F
Yet in implementations where ":" provides access to a Common Lisp style
package system it will be the case that this returns #T.
Thus it seems to me that the two are incompatible. If you wish to permit
Scheme implementations to access a package system using ":", while
continuing to conform to the definition of the language, then you have to
give ":" some status other than extended alphabetic.
∂20-May-87 1001 June meeting
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 10:00:59 PDT
Received: from STAR.STANFORD.EDU (TCP 4402400005) by MC.LCS.MIT.EDU 20 May 87 12:56:57 EDT
Received: from ECL1 by STAR.STANFORD.EDU via MAIL-11 with DECnet; Wed,
20 May 87 09:55:45-PST
From: CSC2::EEK%ECL1.SPAN@STAR.STANFORD.EDU
Subject: June meeting
To: ECL1::STAR::"rrrs-authors@mc.lcs.mit.edu"@ECL1.SPAN
Have any local arrangements for a hotel been made? I called the
Marriott reservation number this morning and found out that they don't
have many rooms available at the Cambridge Marriott.
--Eugene
∂20-May-87 1949 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:49:35 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 20 May 87 22:44:28 EDT
Received: by linc.cis.upenn.edu
id AA04490; Wed, 20 May 87 22:43:59 EDT
Date: Wed, 20 May 87 22:43:59 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Wed, 20 May 87 22:43:59 EDT
Message-Id: <8705210243.AA04490@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
*************************************************************************
Just when you thought you could sleep at night...
Just when you thought you were some from unidentified flyin' objects...
SCOOPS arives.
YEAH!! HOORAY!!
*************************************************************************
SCOOPS is an object-oriented system developed for TI Scheme.
It has been fully ported (as far as I can tell) to cscheme, and
it runs under the new cscheme5 beta release. I have written
a small doc file (not very stylish, but hopefully of assistance).
All the files are available by ftp'ing to linc.cis.upenn.edu
and going to /usr/users/sherin/scoops . The originals
are also there in a subdirectory. The file scoops.scm is the fully
functional file--just a copy of the individual files needed
for SCOOPS. Please help yourselves. Anyone with difficulty
getting the data should send me e-mail.
Enjoy it,
Steve
=============================================================================
sherin@linc.cis.upenn.edu
∂21-May-87 0900 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 09:00:25 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 21 May 87 11:51:12 EDT
Received: by linc.cis.upenn.edu
id AA09027; Thu, 21 May 87 11:50:39 EDT
Date: Thu, 21 May 87 11:50:39 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Thu, 21 May 87 11:50:39 EDT
Message-Id: <8705211550.AA09027@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
My apologees to those who couldn't access SCOOPS. It
has been copied to ~ftp/pub/scoops (pub/scoops when ftp'ing
anonymously).
Happy hunting!
PS Please let me know about software developed with SCOOPS.
Steve
sherin@linc.cis.upenn.edu
============================================================================
"Every passing hour brings the Solar System forty-three miles closer
to Globular Cluster M13 in Hercules--and still there are some misfits
who insist that there is no such thing as progress."
--Ransom K. Ferm
preface to Vonnegut's _Sirens of Titan
I received requests from seismo and netnorth. I was unable to
send mail to those places. If you need the SCOOPS files mailedλ
to you, please indicate exactly how to mail them from this arpanet
site.
You can use wiscvm.wisc.edu as my site extension.
Thanks,
Steve
sherin@linc.cis.upenn.edu
∂21-May-87 1027 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU June meeting -- accommodations
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 10:27:00 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 13:12:57 EDT
Date: Thu, 21 May 87 13:13:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: June meeting -- accommodations
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <203556.870521.JAR@AI.AI.MIT.EDU>
From: CSC2::EEK%ECL1.SPAN at STAR.STANFORD.EDU
To: ECL1::STAR::"rrrs-authors@mc.lcs.mit.edu" at ECL1.SPAN
Re: June meeting
Have any local arrangements for a hotel been made? I called the
Marriott reservation number this morning and found out that they don't
have many rooms available at the Cambridge Marriott.
I have as yet made no arrangements. Given that there are so few people
it's probably best if everyone fended for themselves. But here is some
information.
All the big hotels seem to have special rates for official MIT visits.
I'm not sure how anal the hotels are about this; I don't believe MIT has
to be directly involved in order for you to get the rate, and one person
I talked to said that the rate is available to people who just come to
MIT for, say, a lecture. So by all means ask to get the MIT rate. If
for some reason this doesn't work give me a call and I'll see what I can
do.
Here are some nearby hotel possibilities:
name phone 617- approx distance MIT's rate regular rates
from meeting per room single/double
Marriott 494-6600 0.4 mile 99 (I forgot to ask)
Royal Sonesta 491-3600 1 mile 95 130/145
Hyatt Regency 492-1234 1.1 mile 89 155 and up
Howard Johnson 492-7777 1.4 miles 78/84 85/95
All of them said they had rooms available for 26-28 June.
Note that the rate is usually per room, so if you double up you'll save
a lot of money. If you'd like help finding a roommate let me know.
The brand new Cambridge Marriott is extremely convenient to MIT and the
T. All the heavy construction is over, so I don't think noise will be a
problem. I recommend it, although I've never stayed there myself. But
you should act soon if what Eugene says is true.
If these prices are too steep, there are many inns and guest houses
around with rates as low as $15 (as of last year), but few are close to
MIT, and I have no experience with them. I have a list of these,
prepared by MIT, which I can send (US mail) to anyone who wants it.
- Jonathan
∂21-May-87 1112 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU who will be there
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 11:11:04 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 14:08:08 EDT
Date: Thu, 21 May 87 14:08:26 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: who will be there
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <203585.870521.JAR@AI.AI.MIT.EDU>
This group has no policy on either membership or voting; should it?
Membership on rrrs-authors currently depends on being nominated by
someone already on the list. Is being on rrrs-authors the same as being
invited to the June meeting?
The meeting is apparently not open to the public -- we haven't announced
it on the scheme@mc list. In fact, the membership of scheme@mc isn't
even aware of the existence of rrrs-authors or the imminence of the
meeting. It seems like a good idea to restrict attendance somewhat, but
are we going overboard in being so exclusive? I don't necessarily want
to answer yes, I just want to say that I can't remember these questions
ever having been discussed.
I would like to encourage Julian Padget or any of the other Eulisp
designers to come.
----
Here is my current list of people who have told me they plan to
attend.
Norman Adams
David Bartley (will probably miss Saturday)
Michael Blair
Matthias Felleisen
Bert Halstead
Chris Hanson
Chris Haynes
Eugene Kohlbecker
David Kranz
Jim Miller
Jim Philbin
John Ramsdell
Jonathan Rees
Bill Rozas
G J Sussman
I assume that the following people will be there, although I can't
recall having received definite word from them (I forget such things):
Will Clinger
Richard Kelsey
Mitch Wand
The following people participated in the debate over the date, although
they haven't confirmed that they'll attend:
Kent Dybvig
Dick Gabriel
Kent Pitman
Dan Friedman won't be able to attend.
Among the authors of the R↑nRS's (n = 0,1,2,3) this leaves the
following people unaccounted for:
Hal Abelson
Gary Brooks
Guy Steele
I don't think there's any burning need at this point to inform me of
your plans one way or the other, since the dates have been set and the
room has been reserved. If you show up you show up.
What time should we start in the morning? I have reserved the room for
9 to 5, but most of us are either night people or will be jet-lagging,
so would 10 be better?
- Jonathan
∂21-May-87 1300 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU correction
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 13:00:26 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 May 87 15:58:45 EDT
Date: Thu, 21 May 87 15:59:03 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: correction
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <203657.870521.JAR@AI.AI.MIT.EDU>
In my previous message I inadvertantly omitted Don Oxley from the list
of authors whose plans are unknown.
∂21-May-87 2155 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 21:55:03 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 22 May 87 00:47:58 EDT
Received: by linc.cis.upenn.edu
id AA15207; Fri, 22 May 87 00:47:15 EDT
Date: Fri, 22 May 87 00:47:15 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Fri, 22 May 87 00:47:15 EDT
Message-Id: <8705220447.AA15207@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
I am having trouble reaching wu and
munnari!cidam.oz!mg@seismo.css.gov
Please send your ARPA addresses so I can send you scoops.
Also, indicate whether or not you'd like the Texas Instruments
originals in addition.
Any suggestions are welcomed. If you don't get a reply,
keep psending mail. I'll try to be quick about it as I want
SCOOPS to be distributed to everyone that wants it. There
is a slight conversion to run if using an older version
of cscheme, but that should be minor (and is in the README!
file).
Steve
sherin@linc.cis.upenn.edu
∂21-May-87 2314 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu Getting scoops... (Please give arpa pathway back.)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 23:13:59 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 22 May 87 02:08:02 EDT
Received: by linc.cis.upenn.edu
id AA15633; Fri, 22 May 87 02:07:26 EDT
Date: Fri, 22 May 87 02:07:26 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Fri, 22 May 87 02:07:26 EDT
Message-Id: <8705220607.AA15633@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: Getting scoops... (Please give arpa pathway back.)
I am having trouble reaching wu and
munnari!cidam.oz!mg@seismo.css.gov
Please send your ARPA addresses so I can send you scoops.
Also, indicate whether or not you'd like the Texas Instruments
originals in addition.
Any suggestions are welcomed. If you don't get a reply,
keep psending mail. I'll try to be quick about it as I want
SCOOPS to be distributed to everyone that wants it. There
is a slight conversion to run if using an older version
of cscheme, but that should be minor (and is in the README!
file).
Steve
sherin@linc.cis.upenn.edu
∂22-May-87 0732 @MC.LCS.MIT.EDU,@MIT-Multics.ARPA:NETWORK@FRSAC11.BITNET CScheme Rel 5
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 07:31:56 PDT
Received: from MIT-Multics.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 22 May 87 10:22:40 EDT
Received: from FRSAC11(NETWORK) by MITVMA (Mailer X1.23) id 0285;
Fri, 22 May 87 10:17:43 EDT
Date: Fri, 22 May 87 16:05:28 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK@FRSAC11.BITNET
Subject: CScheme Rel 5
Date: 22 May 1987, 15:56:41 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
MIT Scheme Rel 5 is available only by FTP, and I suppose it is a big file.
A suggestion: send it to SIMTEL20.ARPA, they have the previous version
as PD:<unix.gnu>scheme.tar, a file of over 3 megabytes, but being on this
server, anybody from ARPA or BITNET etc... can get it.
If some kind soul want to do it, talk to Tom Harrison
UNIX-SW-REQUEST@SIMTEL20 .
A lot easier than making tapes!!!
P.S. I can FTP the thing, to bring it to my computer would cost me several
hundred dollars in communication cost...
Sincerly,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@wiscvm.wisc.edu (arpanet)
..!ihnp4!frsac11.bitnet!network (usenet ?)
dumas@sumex-aim.stanford.edu (arpanet)
∂22-May-87 1043 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU CScheme Rel 5
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 10:43:29 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 May 87 12:31:46 EDT
Date: Fri, 22 May 87 12:16:58 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: CScheme Rel 5
To: "NETWORK@FRSAC11.BITNET"@AI.AI.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU, info-cscheme%oz@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 22 May 87 16:05:28 GMT from NETWORK at FRSAC11.BITNET
Message-ID: <204092.870522.CPH@AI.AI.MIT.EDU>
Date: Fri, 22 May 87 16:05:28 GMT
From: NETWORK at FRSAC11.BITNET
To: scheme at mc.lcs.MIT.EDU
Re: CScheme Rel 5
MIT Scheme Rel 5 is available only by FTP, and I suppose it is a big file.
A suggestion: send it to SIMTEL20.ARPA, they have the previous version
as PD:<unix.gnu>scheme.tar, a file of over 3 megabytes, but being on this
server, anybody from ARPA or BITNET etc... can get it.
Please don't send mail regarding MIT C Scheme to this list. Send it
to info-cscheme%oz@mc instead. If you or anyone else wants to be on
this list, send a request to info-cscheme-request%oz@mc.
This is not a good time to move a copy of Rel 5 since it is in beta
test and we are about to release it for real. Keep posted on the
info-cscheme list for details.
∂23-May-87 2256 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu Scoops bug fix
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 May 87 22:56:22 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 24 May 87 01:52:22 EDT
Received: by linc.cis.upenn.edu
id AA13233; Sun, 24 May 87 01:51:22 EDT
Date: Sun, 24 May 87 01:51:22 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Sun, 24 May 87 01:51:22 EDT
Message-Id: <8705240551.AA13233@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scoops bug fix
5/24/87--METHODS.SCM:
In the define-methods macro
> ,formal-list <
was changed to > ',formal-list <
to enable methods with parameters.
>>Steve Sherin
;;Here's a little test file:
;;; Stacks with Scoops--Steve Sherin
(define-class stack (instvars the-stack) (options inittable-variables
gettable-variables settable-variables))
(define-method (stack push) (value) (set! the-stack (cons value the-stack)))
(define-method (stack tos) () (if the-stack (car the-stack)))
(define-method (stack pop) () (if the-stack
(let ((top (tos)))
(set! the-stack (cdr the-stack))
top)))
;;Steve
;; sherin@linc.cis.upenn.edu
∂25-May-87 0853 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu scoops bug found
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87 08:53:36 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 25 May 87 11:48:39 EDT
Received: by linc.cis.upenn.edu
id AA18602; Mon, 25 May 87 02:09:13 EDT
Date: Mon, 25 May 87 02:09:13 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Mon, 25 May 87 02:09:13 EDT
Message-Id: <8705250609.AA18602@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: scoops bug found
5/24/87--METHODS.SCM:
In the define-methods macro
> ,formal-list <
was changed to > ',formal-list <
to enable methods with parameters.
>>Steve Sherin
5/25/87
In the file INSTANCE.SCM:
(define-macro (%sc-compile-class class) ... )
has been changed to
(define (%sc-compile-class class)
(begin
(%inherit-method-vars class)
(eval (%make-template (%sc-name class) class)
user-initial-environment)))
This made sure classes always compile in the user-initial-environment.
>>Steve Sherin
I will continue to post bug fixes as they are found and
maintain a list in ~ftp/pub/scoops on linc@cis.upenn.edu.
Steve
∂26-May-87 1413 @MC.LCS.MIT.EDU,@RELAY.CS.NET:janeta@albatross.uss.tek.com Forwarded Mail
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 May 87 14:13:03 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 May 87 16:41:53 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa23017; 26 May 87 16:07 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id au03093; 26 May 87 16:02 EDT
Received: by tektronix.TEK.COM (5.51/6.21)
id AA07988; Tue, 26 May 87 10:54:47 PDT
Received: by albatross.USS.TEK.COM (3.2/6.19)
id AA05828; Tue, 26 May 87 10:54:38 PDT
Message-Id: <8705261754.AA05828@albatross.USS.TEK.COM>
To: scheme@mc.lcs.mit.edu
From: postmaster <@RELAY.CS.NET,@tektronix.tek.com:postmaster@tektronix.tek.com>
Subject: Forwarded Mail
Date: 26 May 87 10:54:36 PDT (Tue)
Sender: janeta%albatross.uss.tek.com@RELAY.CS.NET
You message was interrupted at tektronix, due to a temporary problem.
Sorry, for the inconvenience,
Jan Acker
------- Forwarded Message
From: MAILER-DAEMON@tektronix.TEK.COM (Mail Delivery Subsystem)
Date: Fri, 22 May 87 09:11:51 PDT
To: mmdf@tektronix
Subject: Returned mail: Unable to deliver mail
----- Transcript of session follows -----
554 mmdf... Recipient names must be specified
----- Unsent message follows -----
Received: by tektronix.TEK.COM (5.51/6.21)
id AA17113; Fri, 22 May 87 09:11:51 PDT
Message-Id: <8705221611.AA17113@tektronix.TEK.COM>
Received: from csnet-relay by .TEK.COM id af16738; 22 May 87 8:53 PDT
Received: from relay.cs.net by RELAY.CS.NET id am07904; 22 May 87 10:42 EDT
Received: from mc.lcs.mit.edu by RELAY.CS.NET id aa20788; 22 May 87 10:42 EDT
Received: from MIT-Multics.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 22 May 87 10
:22:40 EDT
Received: from FRSAC11(NETWORK) by MITVMA (Mailer X1.23) id 0285;
Fri, 22 May 87 10:17:43 EDT
Date: Fri, 22 May 87 16:05:28 GMT
To: scheme@mc.lcs.mit.edu
From: NETWORK@frsac11.bitnet
Subject: CScheme Rel 5
Date: 22 May 1987, 15:56:41 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
MIT Scheme Rel 5 is available only by FTP, and I suppose it is a big file.
A suggestion: send it to SIMTEL20.ARPA, they have the previous version
as PD:<unix.gnu>scheme.tar, a file of over 3 megabytes, but being on this
server, anybody from ARPA or BITNET etc... can get it.
If some kind soul want to do it, talk to Tom Harrison
UNIX-SW-REQUEST@SIMTEL20 .
A lot easier than making tapes!!!
P.S. I can FTP the thing, to bring it to my computer would cost me several
hundred dollars in communication cost...
Sincerly,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@wiscvm.wisc.edu (arpanet)
..!ihnp4!frsac11.bitnet!network (usenet ?)
dumas@sumex-aim.stanford.edu (arpanet)
------- End of Forwarded Message
∂01-Jun-87 1824 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com customizable reader
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 18:24:24 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Jun 87 21:23:52 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa08552; 1 Jun 87 21:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ak19626; 1 Jun 87 20:55 EDT
Received: by tektronix.TEK.COM (5.51/6.22)
id AA07280; Mon, 1 Jun 87 16:11:52 PDT
Received: by tekchips.TEK.COM (5.51/6.19)
id AA08602; Mon, 1 Jun 87 16:14:00 PDT
Message-Id: <8706012314.AA08602@tekchips.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: willc%tekchips.tek.com@RELAY.CS.NET
Subject: customizable reader
Date: 01 Jun 87 16:13:58 PDT (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET
Here's a proposal for the yellow pages: a customizable reader patterned
after Guy Steele's in CLtL. It adds yet another optional argument to
read, but at least it doesn't have any global state. If you like global
state you can, of course, redefine the READ and READ-DELIMITED-LIST
procedures to use a different default readtable.
The proposal does not support the following Common Lisp features:
non-preservation of whitespace, eof-error-p, eof-value, recursive-p,
zero return values, packages.
Since the status of #\| and #\\ is not specified, it is not specified
whether there are any single or multiple escape characters in the
standard readtable. Et cetera. I haven't bothered to specify the token
parser used by the standard readtable because the number syntax is still
a topic of discussion.
The description assumes two new types: the readtable and syntax types.
These types do not have to be distinct from existing types. In my
prototype implementation I use vectors. If we had structures, they
would undoubtedly be structures.
================================================================
(read) --> object
(read port) --> object
(read port readtable) --> object
The readtable argument defaults to the standard readtable.
By specifying an explicit readtable you can inflict your own
crazy syntax on the characters read from the port.
(read-delimited-list char) --> object
(read-delimited-list char port) --> object
(read-delimited-list char port readtable) --> object
Following CLtL. This packages up most of the hair involved with
handling comments. I observe that CLtL does not quite give enough
information for a user to write the #\( and #\) macro procedures,
which must deal with the dotted pair syntax in addition to comments.
Neither does this proposal: I think #\(, #\), and #\; have to be
magic, which makes it hard for a user to make #\[ and #\] behave
exactly like #\( and #\).
(copy-readtable)
(copy-readtable readtable) --> readtable
The argument defaults to the standard readtable. Returns a copy of
its argument. Calls to set-token-parser!, set-character-syntax!,
and set-dispatch-character! on the copy do not affect the original.
(get-token-parser readtable) --> parser
Returns the readtable's token parser. The token parser is a procedure
of three arguments s, i, and j. The token parser must return a token
parsed from (substring s i j) or else signal an error. The token
parser used by the standard readtable always returns a symbol or
number if it doesn't signal an error. The token parser is bypassed
for tokens that contain single or multiple escape characters, since
these always indicate a symbol. Neither is the token parser called
for whitespace, illegal, macro, or dispatch characters.
Passing a string and indexes instead of just a string is an efficiency
hack suggested by David Bartley. To prevent the token parser from
depending on the contents of its string argument outside of
(substring s i j), I propose that every token parser foo be equivalent
to
(lambda (s i j) (foo (substring s i j) 0 (- j i)))
This also implies that the token parser is not allowed to side effect
its string argument.
(set-token-parser! readtable parser) --> #!unspecified
This changes the token parser of the first argument to be the second
argument. By changing the token parser and changing all characters
to be either constituent or whitespace, you can have complete control
over the parser. More realistically, this hook lets you experiment
with weird number syntaxes et cetera.
(get-character-syntax readtable char) --> syntax
Returns the character syntax associated with the given character
in the given readtable.
(set-character-syntax! readtable char syntax) --> #!unspecified
Changes the character syntax of the given character in the given
readtable.
(make-character-syntax 'constituent) --> syntax
(make-character-syntax 'whitespace) --> syntax
(make-character-syntax 'illegal) --> syntax
(make-character-syntax 'single-escape) --> syntax
(make-character-syntax 'multiple-escape) --> syntax
(make-character-syntax 'non-terminating-macro proc) --> syntax
(make-character-syntax 'terminating-macro proc) --> syntax
(make-character-syntax 'macro proc) --> syntax
Manufactures syntax objects. The 'macro option is an alias for
the 'terminating-macro option. The proc is a procedure of three
arguments: the macro character that has just been consumed (this
is so you can use one proc for several related macro characters),
a port, and a readtable. (It would gross me out if any of these
arguments were optional.) See CLtL for explanation of what the
options mean.
(get-dispatch-character readtable char) --> proc
Returns the proc associated with octathorpe macro characters. The
proc takes three arguments: the macro character just consumed, a
port, and a readtable.
(set-dispatch-character! readtable char proc) --> #!unspecified
Defines new octathorpe macro characters.
∂03-Jun-87 0832 @MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU OOPSLA Lisp and Object-Oriented Programming Workshop
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 08:32:23 PDT
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Jun 87 11:07:54 EDT
Date: 03 Jun 87 0805 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: OOPSLA Lisp and Object-Oriented Programming Workshop
To: rrrs-authors@MC.LCS.MIT.EDU
There will be a workshop on Lisp and Object-Oriented Programming on Monday
October 5 from 9am until noon at OOPSLA. The Common Lisp Object System
(CLOS) will be the highlight of the workshop, with presentations about
CLOS by the designers along with critiques, analyses, and responses to the
Object System, the latter selected based on contributed position papers.
Attendance will be limited to people who know Lisp and are familiar with
existing object-oriented languages.
If you would like to attend, please send me a 1-2 page description of your
position regarding either the Common Lisp Object System or
Lisp/object-oriented programming before August 1; netmail is acceptable.
Invitations will be sent on September 1. Attendance is limited to 35
people.
Richard P. Gabriel
Lucid, Inc
707 Laurel Street
Menlo Park, CA 94025
(415)329-8400
rpg@sail.stanford.edu
∂03-Jun-87 1121 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Edwin source
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 11:20:54 PDT
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 3 Jun 87 13:50:42 EDT
Date: Wed, 3 Jun 87 11:39:22 MDT
From: Raul Machuca <RMACHUCA@SIMTEL20.ARPA>
Subject: Edwin source
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12307591509.21.RMACHUCA@SIMTEL20.ARPA>
Is the Scheme source code for
Edwin available from any one on this list
or any other source.
-------
∂03-Jun-87 1622 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Edwin source
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 16:22:46 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Jun 87 19:18:39 EDT
Date: Wed, 3 Jun 87 19:19:09 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: Edwin source
To: RMACHUCA@SIMTEL20.ARPA
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 3 Jun 87 11:39:22 MDT from Raul Machuca <RMACHUCA at SIMTEL20.ARPA>
Message-ID: <209337.870603.CPH@AI.AI.MIT.EDU>
Date: Wed, 3 Jun 87 11:39:22 MDT
From: Raul Machuca <RMACHUCA at SIMTEL20.ARPA>
Is the Scheme source code for
Edwin available from any one on this list
or any other source.
There are two versions of Edwin, the one running in TI PC Scheme, and
the one running in MIT 68000 Scheme. The former is available by FTP
from host prep.ai.mit.edu as one of the following files:
/u2/cph/tiedwin.tar tar format file of source code
/u2/cph/tiedwin.tar.Z compressed version of above
/u2/cph/tiedwin.lst `pr' style listing of source code
The MIT Scheme version of Edwin can be obtained by special arrangement
with me. Sometime in early fall this version will have been ported to
MIT C Scheme and will be a part of the normal distribution.
∂04-Jun-87 2032 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu error-handler
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 20:32:41 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 4 Jun 87 23:28:45 EDT
Received: by linc.cis.upenn.edu
id AA15206; Thu, 4 Jun 87 23:26:27 EDT
Date: Thu, 4 Jun 87 23:26:27 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Thu, 4 Jun 87 23:26:27 EDT
Message-Id: <8706050326.AA15206@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: error-handler
I want to know how to interface to the error-handler
so that I can fix/sneak past certain errors sometimes.
The chief use for the technique is to protect the
interpreter from hanging while manipulating environment
parents with scoops system code. Currently, an unbound
variable error during a call to send can be very messy.
THANKS,
Steve Sherin
U of P
Philadelphia, PA
ARPA: sherin@linc.cis.upenn.edu
∂05-Jun-87 0703 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU message passing
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 07:02:57 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Jun 87 10:00:14 EDT
Date: Fri, 5 Jun 87 10:00:55 EDT
From: "Jonathan A. Rees" <JAR@AI.AI.MIT.EDU>
Subject: message passing
To: sherin@LINC.CIS.UPENN.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 4 Jun 87 23:26:27 EDT from sherin at linc.cis.upenn.edu (Steve Sherin)
Message-ID: <210298.870605.JAR@AI.AI.MIT.EDU>
Your question about error handlers is apparently specific to PC Scheme
(it's hard to tell), since Scheme per se has no standard error handling
system (yet). I would like to remind everyone on this list that
discussion that is specific to one implementation (there are at least
six different implementations) should, if possible, be conducted on an
appropriate forum, not here.
However, I don't know what mailing lists (if any) exist for most of the
implementations, including PC Scheme, MacScheme, or chez scheme. If
there are such mailing lists, could someone please announce them? If
not, then for the time being, I suppose this list is as good a place as
any for discussion -- I don't mean to restrict information flow, just to
make it more efficient -- but could someone out there consider creating
such lists?
At the very least, if your message *does* concern a particular
implementation, please state which one at the very beginning of the
message, so that users of other implementations can determine quickly
that your message does not concern them.
The particular lists I do know about are:
info-cscheme%oz@mc.lcs.mit.edu
(send mail to info-cscheme-request%oz@mc.lcs.mit.edu to be added)
t-discussion@yale.arpa
(send mail to t-discussion-request@mc.lcs.mit.edu to be added)
Thanks
-- the management
∂05-Jun-87 1612 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu error handler for cscheme (MIT)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 16:12:11 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 5 Jun 87 19:08:02 EDT
Received: by linc.cis.upenn.edu
id AA21524; Fri, 5 Jun 87 19:05:31 EDT
Date: Fri, 5 Jun 87 19:05:31 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Fri, 5 Jun 87 19:05:31 EDT
Message-Id: <8706052305.AA21524@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: error handler for cscheme (MIT)
My preceding message was wrt Cscheme from MIT. I'm running
a beta version of #5.
Thanks,
Steve
sherin@linc.cis.upenn.edu
∂06-Jun-87 2108 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu scoops--bug fixes 6/6
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jun 87 21:08:10 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 7 Jun 87 00:04:58 EDT
Received: by linc.cis.upenn.edu
id AA26642; Sun, 7 Jun 87 00:02:28 EDT
Date: Sun, 7 Jun 87 00:02:28 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Sun, 7 Jun 87 00:02:28 EDT
Message-Id: <8706070402.AA26642@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: scoops--bug fixes 6/6
5/24/87--METHODS.SCM:
In the define-methods macro
> ,formal-list <
was changed to > ',formal-list <
to enable methods with parameters.
>>Steve Sherin
5/25/87
In the file INSTANCE.SCM:
(define-macro (%sc-compile-class class) ... )
has been changed to
(define (%sc-compile-class class)
(begin
(%inherit-method-vars class)
(eval (%make-template (%sc-name class) class)
user-initial-environment)))
This made sure classes always compile in the user-initial-environment.
>>Steve Sherin
5/25/87
=======
In methods.scm:
(syntax-table-define ... 'define-macro ...)
was modified to
(syntax-table-define system-global-syntax-table 'define-method (macro e
(let ((class-name (caar e))
(method-name (cadar e))
(formal-list (cadr e))
(body (cddr e)))
`(%sc-class-add-method
',class-name
',method-name
',class-name
',class-name
(append (list 'lambda ',formal-list) ',body)
(lambda (env quoted-val)
(let* ((method-name ',method-name)
(temp `(in-package ,env (define ,method-name
,quoted-val))))
(eval temp (the-environment)))
)))))
Change enabled methods with multiple expressions within the main
lambda.
>>Steve Sherin
6/6/87
In INTERF.SCM:
changed
(empty-slot?
(lambda (form)
(not (eval form (the-environment)))))
to
(empty-slot?
(lambda (form)
(cond
((symbol? form) #f)
((eq? form #f) #t)
(else #f))))
Hence, "no more functions" for an active-value set- or get-
method is specified by a CONSTANT value for the false value.
The change provides the ability to use forward references
to methods as yet undefined when active values are declared.
(Thanks Eric.)
NB This code does NOT check for the symbol >> false <<
as it is not used in r3rs and can be modified as any other
variable.
>> Steve Sherin
∂08-Jun-87 1920 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET number syntax and exactness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87 19:18:09 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Jun 87 21:45:47 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa28306; 8 Jun 87 17:32 EDT
Received: from ti-csl by RELAY.CS.NET id eb24079; 8 Jun 87 17:25 EDT
Received: by tilde id AA07226; Fri, 5 Jun 87 17:17:09 CDT
Received: by home id AA18999; Fri, 5 Jun 87 17:16:04 cdt
Date: Fri, 5 Jun 87 17:16:04 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8706052216.AA18999@home>
To: RRRS-Authors@mc.lcs.mit.edu
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: number syntax and exactness
I have been moderately concerned for some time that Scheme's external
representation for numbers was "gratuitously incompatible" with that
of Common Lisp. My worry was that people attempting to use both
languages would trip over minor differences. This might be a small
annoyance when interacting directly with the user at the keyboard but
possibly a major problem when trying to share files containing numeric
data.
In retrospect, I have decided that the problem is probably not as bad
as I feared. Many incompatibilities, like the representation of
complex numbers, can be handled by suitably extending the reader for
each language to understand the other's syntax. And I'm persuaded
that 3+4i is a worthwhile improvement over #c(3 4).
I still feel that we should talk through the differences between the
two, however, and see if we can iron out some of them. Rather than
make a specific proposal, this message outlines the differences I'm
aware of and suggests possible actions we could take. I'll plan to
make a proposal for discussion at the meeting, but first I want to
hear your reactions to these thoughts.
(1) Complex numbers in Scheme look like 3+4i; in Common Lisp they
look like #c(3 4).
Neither notation causes an ambiguity in the standard reader for either
language, so I'm amenable to leaving it as an optional extension in
each language to support the syntax of the other.
(2) The + or - sign in Scheme precedes everything else in a real
number; in Common Lisp the sign may be preceded by a radix indicator.
Common Lisp does not have the #D (decimal) indicator but has a
general purpose #nnR indicator.
Allowing the radix indicator and sign to appear in either order seems
to be a reasonable extension for both languages.
#D and #nnR do not cause ambiguities, so each could be considered an
extension to the language of the other.
(3) Scheme separates the concept of exactness from type; Common
Lisp does not.
This is an advantage for Scheme, although the full ramifications
haven't been felt yet. I don't understand how to make exactness
orthogonal to precision, however (see point 4). What does
#e#s123456789 mean if an implementation can't represent the value
123456789 exactly in a short FLONUM?
(4) Scheme specifies the precision of a real number using #S
(short) or #L (long); Common Lisp specifies the precision of a
floating point number with an <exponent-marker> of S, F, D, or
L (for Short, Single, Double, and Long). The Scheme syntax in
7.1.1 allows a precision specification for rational numbers;
Common Lisp does not.
In Common Lisp, precision is an attribute of (inexact) FLONUMs only.
The last paragraph of 6.5.3 of R3RS says essentially the same thing,
clarifying the syntax in 7.1.1. This seems inconsistent to me,
though, since it relates "precision" to the FLONUM representation type
whereas I see "precision" as an attribute of "inexactness." If we can
speak of inexact integers, then we should perhaps be able to speak of
short or long ones without requiring that they be implemented as
FLONUMs.
What might be meant in Scheme by a "short integer" like #s123456789?
Surely we don't mean that the number is to be arbitrarily truncated to
a machine-specific fixnum, since that may produce a result which loses
all significance in the number. The only interpretation that makes
sense to me is that #S and #L specify that the number is inexact and
may be stored in a fixed number of bits in a way that preserves the
significant digits as well as it can. Floating point is one such
representation but others exist and may be more suitable for those
implementations not blessed (?) by good FLONUM support.
I see two alternatives. We could tie the specification of precision
to FLONUMs only, as we do now, or we could relate precision to exactness.
I prefer the latter.
One way would be to merge the productions for <precision> and <exactness> in
7.1.1 to give
<precision> --> <empty> | #E | #S | #L | #I
where #E specifies an exact number, #I an inexact number of default
precision, #S and #L inexact numbers of (possibly) differing
precision, and <empty> leaving the exactness to the discretion of the
implementation, except that integers expressed without decimal points
or exponent notation are assumed exact.
This is an upwardly compatible liberalization of R3RS.
Another way, which I prefer, is to kill three birds with one stone and
use the exponent marker to indicate exactness and precision as well as
scale. Suppose we took Common Lisp's S (short), F (single), D
(double) and L (long) exponent markers and interpreted them
essentially as Common Lisp does. That is, all denote inexactness as
well as specifying precision. However, Scheme does not require
numbers written with exponent notation to be FLONUMs as Common Lisp
does, so we are free to represent 7.5s3 as the inexact integer 7500 if
we want.
Common Lisp uses the E exponent marker for the default FLONUM
precision. We could do the same but it would be incompatible with
R3RS for E to imply inexactness. We could instead use E to specify
exact numbers, at the expense of compatibility with Common Lisp.
(5) #S denotes a short precision number in Scheme and a structure
object in Common Lisp.
This can be lived with. However, it is the only conflict I can think
of between the two languages in the use of dispatching macro characters.
If we were to choose to allow precision to be specified via exponent
markers, the #S notation would no longer be needed in Scheme.
(6) Scheme specifies that `#' is printed rather than a digit when
the format calls for more digits than are internally represented.
Common Lisp does not address this issue, although some
implementations use the digit `0' in this case.
This seems to be a relatively harmless discrepancy, although I can
imagine a Common Lisp reader choking up a bit.
(7) Scheme allows ratios to have exponents; Common Lisp does not.
It's their loss, I guess.
----
Summary: Let's clean up the exactness/precision problem and try to
free up #S.
--db--
∂09-Jun-87 0226 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU Better late than never
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jun 87 02:26:34 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Jun 87 05:23:15 EDT
Date: Tue, 9 Jun 87 05:20:50 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Better late than never
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <211811.870609.ALAN@AI.AI.MIT.EDU>
Here, as promised at the Macro Summit Meeting, is a "Modified Macro
Proposal". Apologies for not mailing this out sooner, Jonathan and I will
share the blame for not being prompt about this.
This is not a complete proposal any more than Jonathan's previous macro
proposal was. There are many issues of left unaddressed. There is no
simple interface for ordinary users to use, that must wait for a separate
proposal. There are many minor details left unspecified. The only real
difference between this proposal and the last, is that it includes a
mechanism that addresses the various variable capture problems.
I will assume that the reader is already familiar with Jonathan's previous
proposal. (If you care about this stuff, you probably still have a copy.)
I will only describe the differences between the two.
The basic idea is that the thing we usually call an "environment" (a map
from identifiers to locations), can be viewed as the composition of two
separate maps: First, a map from identifiers to "variables", followed by a
second map from variables to locations. The first map is statically
determined by the program text. It is the mapping that compiler writers
normally call "alpha conversion". The second map is dynamically determined
at runtime. It is the mapping that is actually stored in closures.
In other words, consider:
(LAMBDA (X)
(F X
(LAMBDA (X)
(F X))))
Although there is one identifier named "X" here, occurring in four places,
we all recognize that there are really two separate variables named "X",
each occurring just twice. The mapping that tells you which variable named
"X" is meant by a particular occurrence of the identifier named "X", varies
from place to place in the source code, as determined by the scoping rules
of the language.
Now the idea is to make this static mapping from identifiers to variables
part of syntax tables. This has a nice appeal to it since it makes syntax
tables contain -all- of the static, contextual information necessary for
interpreting the meaning of a particular piece of code. In one package you
get both the mapping from keywords to their current meanings, as well as
the mapping from identifiers to their current meanings.
To see how this deals with the various capture problems, here is how one
might define a vanilla PUSH macro:
(DEFINE PUSH-SYNTAX-TABLE
(ADD-KEYWORD SCHEME-SYNTAX-TABLE 'PUSH
(LAMBDA (SYNTAX-TABLE EXPR) ; (PUSH val var)
(LET ((VAL (PREPROCESS SYNTAX-TABLE '() (CADR EXPR)))
(VAR (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR))))
(PREPROCESS SCHEME-SYNTAX-TABLE '()
`(SET! ,VAR (CONS ,VAL ,VAR)))))))
(There are some minor incompatibilities in argument-order here with
Jonathan's original, but they should mostly be obvious. The only real
difference is the second argument to PREPROCESS, which is new, and will be
explained shortly. For the moment, just ignore the '()s.)
As in Jonathan's original modest proposal, the writer need not be concerned
that the definition of the keyword SET! might be locally redefined in the
location where the PUSH-expression was used, because he uses a known syntax
table to preprocess the SET! expression he constructs. In this modified
proposal, he needn't worry about any local rebindings of CAR either,
because the mapping from the identifier named "CAR" found in
SCHEME-SYNTAX-TABLE will be the global variable named "CAR", rather than
any local variables that happen to have the same name.
Thus we don't need to introduce a new ABSOLUTE special form to allow macro
writers to make references to known variables. Syntax tables can be used
to resolve identifiers into the particular variables whose values are to be
accessed. (There might, of course, be -other- reasons for wanting ABSOLUTE.)
To illustrate how another kind of capture is avoided, here is a definition
of a simple two-operand version of OR:
(DEFINE OR2-SYNTAX-TABLE
(ADD-KEYWORD SCHEME-SYNTAX-TABLE 'OR2
(LAMBDA (SYNTAX-TABLE EXPR) ; (OR2 op1 op2)
(LET ((OP1 (PREPROCESS SYNTAX-TABLE '() (CADR EXPR)))
(OP2 (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR))))
(PREPROCESS SCHEME-SYNTAX-TABLE '()
`((LAMBDA (TEMP)
(IF TEMP TEMP ,OP2))
,OP1))))))
As usual the writer doesn't need to worry about local redefinitions of the
keywords LAMBDA and IF, but notice that he doesn't have to worry that his
use of a variable named "TEMP" will accidentally capture any variables of
the same name in the second operand. This is because the second operand is
first preprocessed in the syntax table that was current where the
OR2-expression occurred, and thus any identifiers it may have contained
named "TEMP" have already been resolved to the correct variable named
"TEMP".
Thus there is no need to introduce "Gensyms" into macroexpansions in order
to avoid inadvertent capture.
Finally, there are situations where the programmer -wants- a capture to
occur. For example it writing the LET macro, he wants certain variables in
the body of the LET-expression to be captured. Here is where the new
argument to PREPROCESS comes in; it gives the user control over the context
sensitivity of preprocessed expressions. Specifically, it is a list of
identifiers (and keywords) which are to be left syntactically free in the
resulting preprocessed expression.
To illustrate, here is a simple single variable version of LET:
(DEFINE LET1-SYNTAX-TABLE
(ADD-KEYWORD SCHEME-SYNTAX-TABLE 'LET1
(LAMBDA (SYNTAX-TABLE EXPR) ; (LET1 <id> <val> <expr>)
(LET ((ID (CADR EXPR))
(VAL (PREPROCESS SYNTAX-TABLE '() (CADDR EXPR))))
(PREPROCESS SCHEME-SYNTAX-TABLE '()
`((LAMBDA (,ID)
,(PREPROCESS SYNTAX-TABLE (LIST ID) (CADDDR EXPR)))
,VAL))))))
Here the expression in the body of a LET1 is preprocessed using the syntax
table current where the LET1-expression occurred, with the
identifier-to-be-bound excepted. Thus the static meaning of all the
identifiers and keywords in the expression will be correctly determined,
while the identifier in question will be left free to be captured by the
LAMBDA-expression it is embedded in.
Now the way this new argument to PREPROCESS works may strike you as a
little odd at first. I used to agree with you. However, the more I work
with it, the better I like it.
Perhaps the reason it works so well can been seen by thinking of the thing
returned by PREPROCESS as a "syntactic closure", similar in nature to the
closures returned by LAMBDA-expressions. In both cases you have an
environment of some kind, a list of identifiers, and an expression. In
both cases all identifiers in the expression are to be taken relative to
the environment, -except- those in the given list. The identifiers in the
list are to have their meanings determined later. In both cases it is a
way of "parameterizing" the expression.
The difference is that the LAMBDA-expression closure is invoked with
positional arguments, while the syntactic closure is invoked in a kind of
"call-by-context" fashion. But even that seems natural in a situation
where you are constructing expressions out of other expressions; such
context-dependence is just the normal way expressions are combigned!
[ I can't resist pointing out that John Lamping is working on something
that looks very much like this call-by-context stuff, except for ordinary
closures. Anyone who doesn't know about his ideas should look into
it, its definitely interesting. ]
An implementation of all of this follows.
!
; A grammar for the core language used as the target of our simple little
; compiler.
;
; core-exp ::= core-var
; | (QUOTE datum)
; | (IF core-exp core-exp core-exp)
; | (SET! core-var core-exp)
; | (CALL core-exp core-exp ...)
; | (BEGIN core-exp core-exp ...)
; | (LAMBDA (bound-var ...) core-exp)
;
; core-var ::= bound-var
; | (FREE name)
; | (ABSOLUTE -path-)
;
; bound-var ::= (VARIABLE name counter)
;
; The bound-vars are all unique, and none are ultimately free.
!
; Preprocessed expressions
; Calling PREPROCESS just makes a "syntactic closure". ST is a syntax
; table, SYMS is a list of identifiers and keywords that are to remain
; syntactically free in the resulting preprocessed expression.
(define (preprocess st syms exp)
(vector 'preprocessed st syms exp))
(define (ppexp->st ppexp) (vector-ref (check-ppexp ppexp) 1))
(define (ppexp->syms ppexp) (vector-ref (check-ppexp ppexp) 2))
(define (ppexp->exp ppexp) (vector-ref (check-ppexp ppexp) 3))
(define (preprocessed? obj)
(and (vector? obj)
(= (vector-length obj) 4)
(eq? (vector-ref obj 0) 'preprocessed)))
(define (check-ppexp ppexp)
(if (preprocessed? ppexp)
ppexp
(error "not a preprocessed expression" ppexp)))
!
; Primitive Syntax table manipulation
; ->CORE is used to compile an expression into the core language.
; Syntax tables are just procedures. Note that a syntax table now returns
; a core language expression. (Previously, a preprocessed expression was
; returned.)
(define (->core st exp)
(st st exp))
; Keywords
(define (add-keyword st0 keyword proc)
(lambda (st exp)
(if (and (pair? exp) (eq? (car exp) keyword))
;; Macros must return context-insensitive expressions:
;; (We -could- decide that it would be convenient to use
;; scheme-syntax-table here; as long as it is a documented
;; context.)
(->core empty-syntax-table (proc st exp))
(st0 st exp))))
; Identifiers
(define *counter* 0)
(define (add-identifier st0 id)
(set! *counter* (+ *counter* 1))
(let ((var `(variable ,id ,*counter*)))
(lambda (st exp)
(if (eq? id exp)
var
(st0 st exp)))))
(define (add-identifiers st ids)
(if (null? ids)
st
(add-identifier (add-identifiers st (cdr ids))
(car ids))))
; Make a new syntax table in which the identifiers and keywords in SYMS are
; found in SYMS-ST, and all others are found in ELSE-ST.
(define (filter-syntax-table syms syms-st else-st)
(lambda (st exp)
(if (if (pair? exp)
(memq (car exp) syms)
(memq exp syms))
(syms-st st exp)
(else-st st exp))))
!
; Syntax tables
; An empty syntax table; defines no keywords or identifiers.
(define (empty-syntax-table st exp)
(cond ((preprocessed? exp)
(->core (filter-syntax-table (ppexp->syms exp) st (ppexp->st exp))
(ppexp->exp exp)))
((or (boolean? exp) (number? exp) (char? exp) (string? exp))
`(quote ,exp))
((pair? exp)
`(call ,@(map (lambda (arg) (->core st arg)) exp)))
(else
(error "not a syntactically valid expression" exp))))
; Core syntax table. Understands the primitive expression types, but
; not the derived ones.
(define (core-syntax-table st exp)
(if (symbol? exp)
`(free ,exp) ; or `(absolute ,exp) ?
(case (and (pair? exp) (car exp))
((quote absolute) exp)
((lambda)
(let ((st (add-identifiers st (cadr exp))))
`(lambda ,(map (lambda (var) (->core st var))
(cadr exp))
,(->core st (caddr exp)))))
((set!)
`(set! ,(->core st (cadr exp))
,(->core st (caddr exp))))
((if)
`(if ,(->core st (cadr exp))
,(->core st (caddr exp))
,(->core st (cadddr exp))))
((begin)
`(begin ,@(map (lambda (exp) (->core st exp)) (cdr exp))))
(else
(empty-syntax-table st exp)))))
!
; The scheme syntax table defines the derived expression types.
(define scheme-syntax-table
(do ((st core-syntax-table
(add-keyword st (caar z) (cadar z)))
(z `((and
,(lambda (st exp)
(let ((forms (cdr exp))
(j (lambda (exp) (preprocess st '() exp))))
(cond ((null? forms) `#t)
((null? (cdr forms)) (j (car forms)))
(else
(preprocess scheme-syntax-table '()
`((lambda (p)
(if p (and ,@(map j (cdr forms))) p))
,(j (car forms)))))))))
;; ...
(lambda
,(lambda (st exp)
(preprocess core-syntax-table '()
`(lambda ,(cadr exp)
,(preprocess-body st (cadr exp) (cddr exp))))))
;; (letrec ,...)
;; ...
;; (quasiquote ,... (absolute scheme-env cons) ...)
)
(cdr z)))
((null? z) st)))
!
; Implements implicit begin and internal defines for lambda bodies.
(define (preprocess-body st ids body)
(let ((definition? (lambda (exp)
(and (pair? exp) (eq? (car exp) 'define))))
(definition-lhs cadr)
(definition-rhs caddr))
(let loop ((l body)
(lhss '())
(rhss '()))
(if (null? l)
(error (if (null? lhss)
"empty body"
"no non-definitions in body")
body)
(let ((exp (car l)))
(if (not (definition? exp))
(let ((all-ids (append lhss ids)))
(let ((body (map (lambda (exp)
(preprocess st all-ids exp))
l)))
(preprocess scheme-syntax-table ids
(if (null? lhss)
`(begin ,@body)
`(letrec ,(map (lambda (lhs rhs)
`(,lhs
,(preprocess st all-ids rhs)))
(reverse lhss)
(reverse rhss))
,@body)))))
(loop (cdr l)
(cons (definition-lhs exp) lhss)
(cons (definition-rhs exp) rhss))))))))
!
(define test-syntax-table
(do ((st scheme-syntax-table
(add-keyword st (caar z) (cadar z)))
(z `((push
,(lambda (st exp)
(let ((var (preprocess st '() (caddr exp)))
(val (preprocess st '() (cadr exp))))
(preprocess test-syntax-table '()
`(set! ,var (cons ,val ,var))))))
;; Your macros here!
)
(cdr z)))
((null? z) st)))
∂09-Jun-87 1603 @MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU Scheme Source
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jun 87 16:03:20 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 9 Jun 87 18:43:48 EDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA17803; Tue, 9 Jun 87 15:41:23 PDT
Received: by ucdavis.ucdavis.edu (5.51/UCD1.38)
id AA11202; Tue, 9 Jun 87 15:05:01 PDT
Received: by clover.ucdavis.edu.ucdavis.edu (5.51/4.7)
id AA06925; Tue, 9 Jun 87 15:02:22 PDT
Return-Path: <windley@iris>
Received: by iris.ucdavis.edu (4.12/3.14)
id AA29091; Tue, 9 Jun 87 15:04:15 pdt
Date: Tue, 9 Jun 87 15:04:15 pdt
From: ucdavis!iris!windley@ucbvax.Berkeley.EDU (Phil Windley)
Message-Id: <8706092204.AA29091@iris.ucdavis.edu>
Qotw: To iterate is human, to recurse devine.
To: scheme@mc.lcs.mit.edu
Subject: Scheme Source
I'm trying to get ahold of Scheme for a VAX for use at UC Davis.
We want to use Sussman and Abelson in an introductory CS class,
but the version of scheme we have (scheme.84.7) doesn't seem to
be compatible with the examples in the book. How can I get
a tape?
Phillip Windley
Robotic Research Lab
University of California, Davis
∂10-Jun-87 1945 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET Agenda
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 19:45:44 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Jun 87 19:40:51 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab13143; 10 Jun 87 19:21 EDT
Received: from ti-csl by RELAY.CS.NET id ag09642; 10 Jun 87 19:18 EDT
Received: by tilde id AA16222; Wed, 10 Jun 87 17:54:33 CDT
Received: by home id AA01217; Wed, 10 Jun 87 17:53:41 cdt
Date: Wed, 10 Jun 87 17:53:41 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8706102253.AA01217@home>
To: RRRS-Authors@mc.lcs.mit.edu
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: Agenda
Here's my stab at a tentative agenda for the meeting. Jonathan has
arranged for facilities from approximately 9:30am to 5:00pm on both
Saturday and Sunday, June 27 and 28. An early action item will be to
come up with the actual agenda; but don't wait until then to flame
about this one!
I. Amenities
-- introductions, etc.
II. Expectations for the meeting/procedure
-- rules of the game (consensus, majority rule?) (who votes?)
-- selection/assignment of secretary and chairperson
-- discussion of the agenda -- priorities and scope, order, champions
-- discussion of the documentary outcome
III. Meta-language issues
-- formal/informal standardization (IEEE, ACM, ANSI???)
-- yeller pages
-- a standardized way to enforce/ensure conformance with the
standard [Jim Miller]
IV. Language issues
-- multiple returned values [Clinger]
-- customizable reader [Clinger]
-- number syntax and exactness [Bartley]
-- macros [Rees]
-- optional arguments [Bartley]
-- pattern matching [Haynes]
-- structures and opaque objects [ ? ]
-- environments and modules [ ? ]
-- error handling [ ? ]
-- miscellaneous
... `:' in symbols [Bartley]
... `integrable' declarations
I have no experience with the formalities of chairing meetings like
this, but I'm willing to open the meeting, present my agenda, and see
where we go from there.
Jonathan suggests that we allot each group 10 minutes or so at the
beginning for a brief presentation of their R&D efforts and goals,
implementations, user profiles, etc. This might include some
philosophy on how Scheme fits their needs, where Scheme might evolve
to, and so forth. Short presentations like this should serve to
introduce both the players and their philosophies.
This should lead naturally into a session for determining our
expectations for the meeting and the procedures to be followed. It
would help if someone could explain the informal rules we've been
playing by since Brandeis. After establishing ground rules, I think
we should determine the scope of the issues to be debated and their
relative priorities so that we can reorder the agenda as needed. We
also should identify `champions' or proposers for each topic.
I thought we might want to discuss meta-language topics next, since
these may help shape the debate on the language issues themselves.
Two evident meta-issues are the `yellow pages' concept and the
question of formal standardization of the language.
My list of language issues follows Will's. I've spawned `pattern
matching' from `optional arguments,' combined `environments' with
`modules', added `error handling' for Hal, and thrown a couple of
recent topics under the umbrella of `miscellaneous.'
It would help if people would announce in advance whether they are
prepared to make proposals or otherwise lead the discussion on a given
topic, particularly if more than one proposal is to be made on a topic.
I would also appreciate some indication of who plans to attend, and
which groups would like to make introductory presentations. Please
post to this mailing list.
Regards,
David Bartley
∂10-Jun-87 2055 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU attending
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 20:55:38 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jun 87 23:56:30 EDT
Date: Wed, 10 Jun 87 23:54:17 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: attending
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU, spols%oz.ai.mit.edu@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 10 Jun 87 17:53:41 cdt from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <212790.870610.JAR@AI.AI.MIT.EDU>
Here is my current list of attendees. I count 29 so far, although two
or three are dubious. I'm keeping track so that we will know how much
food to order. I will send out a request shortly for money to pay for
lunch and other munchies.
If anyone has special audiovisual requests, let me know. I'll get the
usual projectors, and I'll try to talk GJS into bringing his amazing
projectable PC screen.
Hal Abelson
Norman Adams Tektronix
David Bartley TI (may miss Saturday?)
Alan Bawden
Michael Blair
Will Clinger Tektronix/Semantic Microsystems
Olivier Danvy Copenhagen U.
Kent Dybvig
Bruce Duba Indiana
Matthias Felleisen Indiana
Dick Gabriel Lucid (may miss some)
Ken Haase
Bert Halstead
Chris Hanson
Anne Hartheimer Semantic Microsystems
Chris Haynes Indiana
Bob Hieb Indiana
Richard Kelsey Yale (not verified)
Eugene Kohlbecker URI
David Kranz Yale
Jim Miller
Richard Mlynarik
Jim Philbin Yale
Kent Pitman Symbolics
John Ramsdell MITRE
Jonathan Rees
Bill Rozas
G J Sussman
Mitch Wand Northeastern
(The absence of an indicated affiliation means that the affiliation is
MIT.)
∂11-Jun-87 1013 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU on-campus accommodations
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 10:13:10 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Jun 87 13:00:01 EDT
Date: Thu, 11 Jun 87 12:58:07 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: on-campus accommodations
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <212975.870611.JAR@AI.AI.MIT.EDU>
If anyone is interesting in staying in an MIT dorm room (cheap) during
the workshop, please send me mail.
∂11-Jun-87 1755 @MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU Compiling Scheme on a hp200
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 17:54:54 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Jun 87 20:52:32 EDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA06798; Thu, 11 Jun 87 17:49:42 PDT
Received: by ucdavis.ucdavis.edu (5.51/UCD1.38)
id AA28247; Thu, 11 Jun 87 17:05:24 PDT
Received: by clover.ucdavis.edu.ucdavis.edu (5.51/4.7)
id AA04759; Thu, 11 Jun 87 17:02:42 PDT
Return-Path: <windley@iris>
Received: by iris.ucdavis.edu (4.12/3.14)
id AA22532; Thu, 11 Jun 87 17:04:49 pdt
Date: Thu, 11 Jun 87 17:04:49 pdt
From: ucdavis!iris!windley@ucbvax.Berkeley.EDU (Phil Windley)
Message-Id: <8706120004.AA22532@iris.ucdavis.edu>
Qotw: To iterate is human, to recurse devine.
To: scheme@mc.lcs.mit.edu
Subject: Compiling Scheme on a hp200
I ftp'd dist.tar yesterday and it compiled fine for a vax, but on the
hp200, it has a few problems. It seems that it wants to assemble a file
called cmp68020.s, the hp200 has a 68010. I changed the switch in the
make file, but it still wants that code. What is it supposed to do?
It chokes when it starts to assemble the 68020 code.
Phillip J. Windley
Robotics Research Laboratory
University of California, Davis
∂11-Jun-87 2347 @MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Re: number syntax and exactness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87 23:46:54 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUN 87 02:47:24 EDT
Date: Fri 12 Jun 87 02:45:08-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: number syntax and exactness
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: <8706052216.AA18999@home>
Message-ID: <12309831704.6.GJS@OZ.AI.MIT.EDU>
Let's look through your points one-by-one.
B: (1) Complex numbers in Scheme look like 3+4i; in Common Lisp they
look like #c(3 4).
And I'm persuaded that 3+4i is a worthwhile improvement over #c(3 4).
Actually, I am no longer so persuaded myself. The problem is that 3+4i
indicates to the reader that we are adding a real 3 to an imaginary 4.
Thus it is not obvious why the syntax will not accept 4i, but requires
0+4i. I still like 5@.927 for polar numbers, but I would rather have
something like 3&4 for the rectangular variety than 3+4i. On the other
hand I think that the #C syntax is quite ugly. I see no reason why we
shouldn't accept it, for compatability reasons, in addition to something
more pretty.
B: (2) The + or - sign in Scheme precedes everything else in a real
number; in Common Lisp the sign may be preceded by a radix indicator.
Common Lisp does not have the #D (decimal) indicator but has a
general purpose #nnR indicator.
Allowing the radix indicator and sign to appear in either order seems
to be a reasonable extension for both languages.
I agree.
B: (3) Scheme separates the concept of exactness from type; Common
Lisp does not.
No... Exactness is intended to be a statement about the mathematical
type of a quantity. Scheme tries to separate the mathematical type from
the implementation representation. This is not a complete separation, but
it is important to make it as separate as possible.
B: I don't understand how to make exactness
orthogonal to precision, however (see point 4). What does
#e#s123456789 mean if an implementation can't represent the value
123456789 exactly in a short FLONUM?
Your problem here is that you have conflated the size of the flonum,
a property of the representation, not the mathematical type, with a
mathematical exactness property. It seems to me that the example you
show is just an error -- to be caught by the reader -- as it would
complain about #d() or 3.4e5.6.
B: (4) Scheme specifies the precision of a real number using #S(short)
or #L (long); Common Lisp specifies the precision of a
floating point number with an <exponent-marker> of S, F, D, or
L (for Short, Single, Double, and Long). The Scheme syntax in
7.1.1 allows a precision specification for rational numbers;
Common Lisp does not.
I see nothing wrong with the Scheme specification. The Common Lisp one
is an extension of an ancient Fortran kludge. I would not be adverse to
accepting the Common Lisp syntax for compatability, in addition to our
(preferred) syntax.
B: In Common Lisp, precision is an attribute of (inexact) FLONUMs only.
The last paragraph of 6.5.3 of R3RS says essentially the same thing,
clarifying the syntax in 7.1.1. This seems inconsistent to me,
though, since it relates "precision" to the FLONUM representation type
whereas I see "precision" as an attribute of "inexactness." If we can
speak of inexact integers, then we should perhaps be able to speak of
short or long ones without requiring that they be implemented as
FLONUMs.
Again, David, I think that you are confusing representation type with
the mathematical status of a quantity. In fact, the shortness or longness
of a flonum says nothing about the precision of a numeric quantity so
represented. For example, 3.14159232145678 is a rather imprecise value
for pi, but it is represented in a medium of potentially large precision.
Exactness is intended to be a property of the precision of a quantity, not a
property of the potential precision of a representation.
I don't think that there is any good reason to mix up such ideas as
SHORT, LONG, FLONUM, FIXNUM, etc. with ideas such as INTEGER, REAL,
EXACT, INEXACT, RATIONAL. It is to be expected that these ideas are
not orthogonal. Surely the mathematical type constrains the
applicable representations -- it is hard to argue for stuffing a
complex number into a FIXNUM.
B: I see two alternatives. We could tie the specification of precision
to FLONUMs only, as we do now, or we could relate precision to exactness.
I prefer the latter.
I do not think that this is a matter of preference... (potential) precision
is indeed only a property of the representation -- FLONUMs -- you may extend
the idea to FIXNUMs/BIGNUMs, if it appears to be useful, but do not confuse
the potential precision of a representation with the actual precision of
a particular number.
-------
∂12-Jun-87 1204 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU Compiling Scheme on a hp200
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 12:04:18 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 13:35:43 EDT
Date: Fri, 12 Jun 87 13:32:18 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: Compiling Scheme on a hp200
To: ucdavis!iris!windley@UCBVAX.BERKELEY.EDU
cc: scheme@MC.LCS.MIT.EDU, bug-cscheme@OZ.AI.MIT.EDU
In-reply-to: Msg of Thu 11 Jun 87 17:04:49 pdt from ucdavis!iris!windley at ucbvax.Berkeley.EDU (Phil Windley)
Message-ID: <213574.870612.CPH@AI.AI.MIT.EDU>
Date: Thu, 11 Jun 87 17:04:49 pdt
From: ucdavis!iris!windley at ucbvax.Berkeley.EDU (Phil Windley)
I ftp'd dist.tar yesterday and it compiled fine for a vax, but on the
hp200, it has a few problems. It seems that it wants to assemble a file
called cmp68020.s, the hp200 has a 68010. I changed the switch in the
make file, but it still wants that code. What is it supposed to do?
It chokes when it starts to assemble the 68020 code.
Phillip J. Windley
Robotics Research Laboratory
University of California, Davis
Please do not send bug messages about MIT CScheme to this mailing
list. As we specify in the file README in the distribution, such
messages should be sent to "bug-cscheme%oz@mc.lcs.mit.edu". The
"scheme" mailing list is a general discussion list for all issues
about Scheme.
In reply to your bug report, please delete the various "Compiled code
interface files" in "Makefile.200" and replace them with the
commented-out information ("compiler.c", "compiler.oo", etc). This
code is not 68020-specific and should work fine for you.
∂12-Jun-87 1501 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU no free lunch
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 15:01:23 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 17:56:39 EDT
Date: Fri, 12 Jun 87 17:54:55 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: no free lunch
To: rrrs-authors@MC.LCS.MIT.EDU
cc: spols@OZ.AI.MIT.EDU
Message-ID: <213724.870612.JAR@AI.AI.MIT.EDU>
Lunch and 2 coffee breaks each day of the workshop will be catered by
one of the MIT dining halls and will be adequate but not elaborate:
cold cuts, pasta salad, cake, fruit, etc.
So if you plan to attend the workshop, please send a check for $14,
payable to the Massachusetts Institute of Technology, to
Mary Spollen
MIT Laboratory for Computer Science
545 Technology Square
Cambridge MA 02139
Send only $7 if you'll only be there one of the two days.
If you are vegetarian or have other requirements and the menu doesn't
sound adequate, contact me or Mary and we'll see if anything can be done
for you.
∂12-Jun-87 1513 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU directions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 15:13:43 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 18:13:26 EDT
Date: Fri, 12 Jun 87 18:11:50 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: directions
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <213728.870612.JAR@AI.AI.MIT.EDU>
One more item of business from the local-arrangements-coordinator...
(Sorry to dribble them out like this, but I'm not paid to be organized)
If you want to have a map of MIT with directions to the workshop mailed
to you, send me your postal address. Also let me know if you need
directions from the airport.
∂12-Jun-87 2016 @MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU no free lunch
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87 20:16:10 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Jun 87 23:17:37 EDT
Date: Fri, 12 Jun 87 23:15:55 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject: no free lunch
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU, spols@OZ.AI.MIT.EDU
In-reply-to: Msg of Fri 12 Jun 87 17:54:55 EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <213825.870612.CPH@AI.AI.MIT.EDU>
I'm vegetarian. I don't know what is in pasta salad but I think
sometimes it has some meat in it. If it's much trouble it is easy
for me to bring my own food.
∂14-Jun-87 0942 @MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu SCOOPS bug-fixes
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Jun 87 09:42:22 PDT
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 14 Jun 87 12:40:30 EDT
Received: by linc.cis.upenn.edu
id AA11801; Sun, 14 Jun 87 12:37:00 EDT
Date: Sun, 14 Jun 87 12:37:00 EDT
From: sherin@linc.cis.upenn.edu (Steve Sherin)
Posted-Date: Sun, 14 Jun 87 12:37:00 EDT
Message-Id: <8706141637.AA11801@linc.cis.upenn.edu>
To: scheme@mc.lcs.mit.edu
Subject: SCOOPS bug-fixes
5/24/87--METHODS.SCM:
In the define-methods macro
> ,formal-list <
was changed to > ',formal-list <
to enable methods with parameters.
>>Steve Sherin
5/25/87
In the file INSTANCE.SCM:
(define-macro (%sc-compile-class class) ... )
has been changed to
(define (%sc-compile-class class)
(begin
(%inherit-method-vars class)
(eval (%make-template (%sc-name class) class)
user-initial-environment)))
This made sure classes always compile in the user-initial-environment.
>>Steve Sherin
5/25/87
=======
In methods.scm:
(syntax-table-define ... 'define-macro ...)
was modified to
(syntax-table-define system-global-syntax-table 'define-method (macro e
(let ((class-name (caar e))
(method-name (cadar e))
(formal-list (cadr e))
(body (cddr e)))
`(%sc-class-add-method
',class-name
',method-name
',class-name
',class-name
(append (list 'lambda ',formal-list) ',body)
(lambda (env quoted-val)
(let* ((method-name ',method-name)
(temp `(in-package ,env (define ,method-name
,quoted-val))))
(eval temp (the-environment)))
)))))
Change enabled methods with multiple expressions within the main
lambda.
>>Steve Sherin
6/6/87
In INTERF.SCM:
changed
(empty-slot?
(lambda (form)
(not (eval form (the-environment)))))
to
(empty-slot?
(lambda (form)
(cond
((symbol? form) #f)
((eq? form #f) #t)
(else #f))))
Hence, "no more functions" for an active-value set- or get-
method is specified by a CONSTANT value for the false value.
The change provides the ability to use forward references
to methods as yet undefined when active values are declared.
(Thanks Eric.)
NB This code does NOT check for the symbol >> false <<
as it is not used in r3rs and can be modified as any other
variable.
>> Steve Sherin
6/13/87
Send.scm was rewritten, correcting the following:
Errors during the use of send, send-if-handles now do not
mess up the interpreter. Circularly sent messages are now
allowed.
>> Steve Sherin
-----------------------------------------------------------------
Here's the new version of send.scm:
----------------Cut here.----------------------------------------
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; ;;;
;;; S c o o p s ;;;
;;; ;;;
;;; ;;;
;;; Rewritten 5/20/87 for cscheme ;;;
;;; by Steve Sherin--U of P ;;;
;;; File : send.scm ;;;
;;; ;;;
;;; Amitabh Srivastava ;;;
;;; ;;;
;;;-----------------------------------------------------------------;;;
;;; One does not have to use the SEND form to invoke methods ;;;
;;; in the same class; they can be invoked as Scheme functions. ;;;
;;; ;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; send
(syntax-table-define system-global-syntax-table 'send
(macro e
(let ((args (cddr e))
(msg (cadr e))
(obj (car e)))
`(let* ((set-parent! (access system-environment-set-parent!
environment-package))
(ep environment-parent)
(ibot ,obj)
(itop (ep (ep ibot)))
(ipar (ep itop))
(class (access %sc-class ibot))
(ctop (%sc-class-env class))
(cpar (ep ctop))
(cbot (%sc-method-env class))
(instance-safe? (eq? ipar cbot)))
(without-interrupts
(lambda ()
(dynamic-wind
(lambda ()
(set-parent! ctop ibot)
(if instance-safe?
(set-parent! itop cpar)))
(lambda ()
(in-package cbot (,msg ,@args)))
(lambda ()
(set-parent! ctop cpar)
(set-parent! itop cbot))
)))))))
;;; send-if-handles
(syntax-table-define system-global-syntax-table 'send-if-handles (macro e
(let ((obj (car e))
(msg (cadr e))
(args (cddr e)))
`(let
((self ,obj))
(if (assq ',msg (%sc-method-structure (access %sc-class self)))
(send self ,msg ,@args)
#!false)))))
∂15-Jun-87 1132 @MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU Books on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jun 87 11:32:23 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 15 Jun 87 12:52:29 EDT
Received: from FRSAC11(NETWORK) by MITVMA (Mailer X1.23) id 3420;
Mon, 15 Jun 87 12:06:35 EDT
Date: Mon, 15 Jun 87 10:55:03 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK@FRSAC11.BITNET
Subject: Books on Scheme
Date: 15 June 1987, 10:50:42 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
I have heard lately about a book by Kent Dybvig, called "The scheme programming
language".
Anybody on the net can give me exact references ? (I need the editor, and may
be the price to order it.)
Any other book on Scheme ?
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@wiscvm.wisc.edu (arpanet)
..!ihnp4!frsac11.bitnet!network (usenet ?)
dumas@sumex-aim.stanford.edu (arpanet)
∂15-Jun-87 1437 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Session chair
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jun 87 14:37:23 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Jun 87 17:29:31 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ag01996; 15 Jun 87 15:53 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ar11342; 15 Jun 87 15:47 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA08034; Mon, 15 Jun 87 11:47:20 PDT
Received: by tekchips.TEK.COM (5.51/6.22)
id AA05321; Mon, 15 Jun 87 11:49:50 PDT
Message-Id: <8706151849.AA05321@tekchips.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Session chair
In-Reply-To: Your message of Fri, 12 Jun 87 17:54:55 EDT.
<213724.870612.JAR@AI.AI.MIT.EDU>
Date: 15 Jun 87 11:49:49 PDT (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mitch Wand, who moderated the successful meeting at Brandeis in 1984, has
agreed to chair our sessions again in Cambridge. His net mail address is
wand@corwin.ccs.northeastern.edu.
Thanks, Mitch.
Will Clinger
∂18-Jun-87 0452 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCOOPS newsgroup? RSVP
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 04:52:24 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 18 Jun 87 07:49:08 EDT
Received: by ucbvax.Berkeley.EDU (5.57/1.26)
id AA13845; Thu, 18 Jun 87 04:23:44 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 18 Jun 87 03:03:11 GMT
From: super.upenn.edu!linc.cis.upenn.edu!sherin@RUTGERS.EDU (Steve Sherin)
Organization: University of Pennsylvania
Subject: SCOOPS newsgroup? RSVP
Message-Id: <1363@super.upenn.edu.upenn.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
It has been suggested that there is enough interest
(and postings) to have an autonomous SCOOPS newgroup.
I would like to here from those who want sucha b-board.
I'll gladly moderate it and post various fixes/programs
to go along with SCOOPS. I have spoken with the creator
of SCOOPS, and he has said that he also will particpate
in some of the discussions. Please mail directly to
me at sherin@linc.cis.upenn.edu. I apologize to those
of you who have been bothered in any way by these postings,
but I ahd no other reasonable way of reaching everyone
concerned (as requests are still coming in from people
who've just heard about the availability of the sources).
Thank you.
∂18-Jun-87 1908 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET number syntax and exactness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jun 87 19:08:16 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Jun 87 21:58:48 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13647; 18 Jun 87 21:20 EDT
Received: from ti-csl by RELAY.CS.NET id aa04204; 18 Jun 87 21:15 EDT
Received: by tilde id AA24906; Thu, 18 Jun 87 19:00:48 CDT
Received: by home id AA09063; Thu, 18 Jun 87 18:59:25 cdt
Date: Thu, 18 Jun 87 18:59:25 cdt
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8706182359.AA09063@home>
To: GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: bartley%home%ti-csl.csnet@RELAY.CS.NET, RRRS-Authors@mc.lcs.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Fri 12 Jun 87 02:45:08-EDT <12309831704.6.GJS@OZ.AI.MIT.EDU>
Subject: number syntax and exactness
> Let's look through your points one-by-one. [...]
>
> B: (3) Scheme separates the concept of exactness from type; Common
> Lisp does not.
>
> No... Exactness is intended to be a statement about the mathematical
> type of a quantity. Scheme tries to separate the mathematical type from
> the implementation representation. This is not a complete separation, but
> it is important to make it as separate as possible.
I meant that Scheme separated exactness from type in the sense that
"exactness is independent of the position of the number on the tower
[of numeric types]" (6.5.2). Isn't this also what you are saying?
I agree that it certainly is easy to get confused about whether we're
talking about mathematic types, "types" in the language, or
representational "types."
> B: I don't understand how to make exactness
> orthogonal to precision, however (see point 4). What does
> #e#s123456789 mean if an implementation can't represent the value
> 123456789 exactly in a short FLONUM?
>
> Your problem here is that you have conflated the size of the flonum,
> a property of the representation, not the mathematical type, with a
> mathematical exactness property. It seems to me that the example you
> show is just an error -- to be caught by the reader -- as it would
> complain about #d() or 3.4e5.6.
Although the notation #e3 means that we are talking about exactly the
abstract number 3, our purpose in using the notation is to communicate
that to a program. Thus, we must consider whether our representation
"types" suffice to do so. Of course this is conflating a property of
the representation with a mathematical property---that's what I/O of
numbers has to deal with.
From 6.5.2: "Some operations, such as the square root (of non-square
numbers), must be inexact because of the finite precision of our
representations." I'm saying that another such operation is input,
when obeying a precision specification prevents the reader from
correctly representing an exact number. Is this an error, as you
suggest, or no worse than having (SQRT #e3) return an inexact result?
> B: In Common Lisp, precision is an attribute of (inexact) FLONUMs only.
> The last paragraph of 6.5.3 of R3RS says essentially the same thing,
> clarifying the syntax in 7.1.1. This seems inconsistent to me,
> though, since it relates "precision" to the FLONUM representation type
> whereas I see "precision" as an attribute of "inexactness." If we can
> speak of inexact integers, then we should perhaps be able to speak of
> short or long ones without requiring that they be implemented as
> FLONUMs.
>
> Again, David, I think that you are confusing representation type with
> the mathematical status of a quantity. In fact, the shortness or longness
> of a flonum says nothing about the precision of a numeric quantity so
> represented. For example, 3.14159232145678 is a rather imprecise value
> for pi, but it is represented in a medium of potentially large precision.
> Exactness is intended to be a property of the precision of a quantity, not a
> property of the potential precision of a representation.
I shouldn't have said that I see "precision" as an ++attribute++ of
"inexactness," as that is an overstatement. I'm trying to say that
fixed precision can impair our ability to represent some exact numbers
correctly. The shortness or longness of a flonum DOES say something
about the likelihood of being able to represent an exact value
(consisting of many digits) correctly, because #e1.5 can probably be
represented exactly as either a short or long flonum, but
#e1.000000000000000000000005 may fit correctly only in a long [I'm
assuming a decimal flonum here]. Thus, #e#s1.000000000000000000000005
involves a contradiction.
Part of my discussion following my point (4) was in error because I
didn't notice this sentence in the last paragraph of 6.5.3: "In either
case, we are specifying an explicit way to represent an inexact
number." This tells me that #e#s123456789 is incorrect because the #S
directly contradicts the #E.
However, I still would like some clarification on whether a number
like #e1.000000000000000000000005 (no #S) is an error or is quietly
represented as an inexact number because READ is sometimes an inexact
operation.
----------
I can see that there are enough flaws in my presentation that I need
to start over on it. However, I will be on vacation from this
Saturday until I show up at the Scheme meeting next Saturday, so I'll
just wait and see if there is any interest when I get there.
--db--
∂23-Jun-87 1955 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU sundry
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 19:55:19 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Jun 87 22:22:37 EDT
Date: Tue, 23 Jun 87 22:24:48 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: sundry
To: rrrs-authors@MC.LCS.MIT.EDU
cc: spols%oz@MC.LCS.MIT.EDU
Message-ID: <218731.870623.JAR@AI.AI.MIT.EDU>
A recapitulation of the details of the workshop, with some directions for
the minority (!) of you not familiar with the area:
We meet Saturday and Sunday starting at 9:30 a.m. Tentative finishing
time is 5 p.m. but we can stay longer or shorter if we like. The
current head count is 33.
The Grier Room is also known as room 34-401. The entrance to buildings
34, 36, and 38 is on Vassar Street about halfway between Main Street and
Massachusetts Avenue. At the entrance there is a big new glass atrium,
several stories high, that's hard to miss, and a revolving door.
Building 34 nestles in between buildings 36 and 38 and away from the
street, opposite the main entrance. Go to the left (building 36) and
take the stairs or elevator up to the fourth floor. 401 is the only
room on the fourth floor of building 34; it has two halves (A and B) with
separate doors, and we'll be meeting in one half and lunching in the other.
There is a parking lot across the street; if I'm not mistaken, weekend
parking there is unrestricted. Street parking may also be available.
Building 34 is only about 2.5 blocks from the Marriott. Take Main St
away from the river and hang an obtuse left onto Vassar just before the
railroad tracks.
I started writing out directions for how to drive to the Marriott from
the airport; it's easy if you know what you're doing, but a missed exit
can, for example, put you on a toll bridge headed to distant
Charlestown. So I'll take the coward's way out and suggest that it's
probably best to get directions and a map from your car rental agency;
they're probably better at giving directions than I am (I have no car).
Better yet, take the subway (shuttle bus to blue line to green line (or
orange line) to red line to Kendall) -- very easy, you ascend from the
subway directly into the hotel complex. If anyone so requests, however,
I'd be happy to try to write up directions.
If you have questions or get into trouble, my phone number at MIT is
(617) 253-8581, home 423-3953. Mary Spollen's phone number is 253-5855.
If you haven't sent your payment yet then please bring a check ($14,
payable to MIT) on Saturday.
- Jonathan
∂30-Jun-87 1800 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jun 87 18:00:05 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 30 Jun 87 20:59:30 EDT
Date: Tue, 30 Jun 87 18:37:18 est
From: Matthias Felleisen <matthias@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Macros
Here is a final attempt to explain my position on macros and related matters.
I perceive two major purposes for macros:
1. extending the set of available syntactic facilities
2. manipulating an s-expression in an arbitrary way and interpreting the
result as program text at compile time.
I shall call the first kind of facility "extend-syntax", the second kind
"sep" (for s-expression processing).
1. When we extend syntax, we manipulate s-expressions that coincide with
abstract syntax trees. Since these are trees, not graphs, there is NO NEED
WHATSOEVER to use any kind of assignment: assignments exist for creating
circularities and for modeling state (in the sense of objects and state
variables). Therefore, a functional specification of these extensions is
sufficient. Furthermore, the extension of language syntax should be as far
as possible separated from ordinary evaluations although this is subject to
research and compromise. This is---in my eyes, perhaps not Eugene's---the
essence of Eugene's dissertation on extend-syntax. His choice of using
pattern-matching for the specification of extensions is---for many people---
convenient, but not inherent.
2. The arbitrary manipulation of s-expressions at compile time can mean two
things:
a: obtaining a value that we cannot write down in Scheme and including it
in expansions, e.g. closures. This is actually
a problem of Scheme and can be fixed in various ways. A weak solution is
Eugene's with-construct in extend-syntax which accomplishes this, but
unfortunately also does other things. (Another solution is to work with a
stronger language.)
b: performing arbitrary and possibly infinite computations. This is the point
of contention and the Indiana school of thought rejects this possibility.
We feel the interaction between compile time and run time (or anytime
computations) is not understood well enough to justify an inclusion
in RRRS. Just as there is a better way for expressing extend-syntax
the community should look for better ways for dealing with these problems.
Old-style macros with no global side-effects can stillbe implemented with
extend-syntax:
(extend-syntax
(define-macro Macro TransForm)
(extend-syntax (Macro exp ...) (eval (Transform '(exp ...))))
[This requires eval and possibly a split of eval into several pahses together with
Dan's favorite (and (in)famous) extend-syntax macro eval-once.]
Because extend-syntax (in whatever form) is simpler and demonstrates to the
world that the Scheme-designers understand the problem and because it can
implement conservative sep-macros, I opt for an extend-syntax-like mechanism
as a primitive tool.
-- Matthias & Bruce.
∂01-Jul-87 0728 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87 07:27:58 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 1 Jul 87 09:56:18 EDT
Date: Wed, 1 Jul 87 08:54:27 est
From: Matthias Felleisen <matthias@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Macros
Here is a final attempt to explain my position on macros and related matters.
I perceive two major purposes for macros:
1. extending the set of available syntactic facilities
2. manipulating an s-expression in an arbitrary way and interpreting the
result as program text at compile time.
I shall call the first kind of facility "extend-syntax", the second kind
"sep" (for s-expression processing).
1. When we extend syntax, we manipulate s-expressions that coincide with
abstract syntax trees. Since these are trees, not graphs, there is NO NEED
WHATSOEVER to use any kind of assignment: assignments exist for creating
circularities and for modeling state (in the sense of objects and state
variables). Therefore, a functional specification of these extensions is
sufficient. Furthermore, the extension of language syntax should be as far
as possible separated from ordinary evaluations although this is subject to
research and compromise. This is---in my eyes, perhaps not Eugene's---the
essence of Eugene's dissertation on extend-syntax. His choice of using
pattern-matching for the specification of extensions is---for many people---
convenient, but not inherent.
2. The arbitrary manipulation of s-expressions at compile time can mean two
things:
a: obtaining a value that we cannot write down in Scheme and including it
in expansions, e.g. closures. This is actually
a problem of Scheme and can be fixed in various ways. A weak solution is
Eugene's with-construct in extend-syntax which accomplishes this, but
unfortunately also does other things. (Another solution is to work with a
stronger language.)
b: performing arbitrary and possibly infinite computations. This is the point
of contention and the Indiana school of thought rejects this possibility.
We feel the interaction between compile time and run time (or anytime
computations) is not understood well enough to justify an inclusion
in RRRS. Just as there is a better way for expressing extend-syntax
the community should look for better ways for dealing with these problems.
Old-style macros with no global side-effects can stillbe implemented with
extend-syntax:
(extend-syntax
(define-macro Macro TransForm)
(extend-syntax (Macro exp ...) (eval (Transform '(exp ...))))
[This requires eval and possibly a split of eval into several pahses together with
Dan's favorite (and (in)famous) extend-syntax macro eval-once.]
Because extend-syntax (in whatever form) is simpler and demonstrates to the
world that the Scheme-designers understand the problem and because it can
implement conservative sep-macros, I opt for an extend-syntax-like mechanism
as a primitive tool.
-- Matthias & Bruce.
∂01-Jul-87 0836 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Macros
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87 08:36:03 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Jul 87 11:36:19 EDT
Date: Wed, 1 Jul 87 11:38:11 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Macros
To: matthias@IUCS.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 1 Jul 87 08:54:27 est from Matthias Felleisen <matthias at iucs.cs.indiana.edu>
Message-ID: <222081.870701.JAR@AI.AI.MIT.EDU>
Date: Wed, 1 Jul 87 08:54:27 est
From: Matthias Felleisen <matthias at iucs.cs.indiana.edu>
b: performing arbitrary and possibly infinite computations. This is the
point of contention and the Indiana school of thought rejects this
possibility.
Old-style macros with no global side-effects can still be implemented with
extend-syntax: ...
... I opt for an extend-syntax-like mechanism as a primitive tool.
I must be missing something. This sounds like a gross contradiction to
me.
Could you be clearer, perhaps even concrete, about what you mean by
"extend-syntax-like"?
∂01-Jul-87 1046 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message, ignore
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87 10:46:44 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Jul 87 13:25:23 EDT
Date: Wed, 1 Jul 87 13:28:04 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: test message, ignore
To: scheme@MC.LCS.MIT.EDU
Reply-to: scheme-request@mc.lcs.mit.edu
Message-ID: <222143.870701.JAR@AI.AI.MIT.EDU>
I periodically send out a test message to the list, for two purposes:
(a) it verifies to new arrivals that they have been added, (b) it helps
weed out bad addresses, since copies sent to such bounce back to me.
There are about 200 entries on my list, many of which are redistribution
lists, so I'd estimate the readership to be about 400-600 (probably a
low estimate since I think it goes out to uucp netnews, and Allah knows
what happens to it then).
∂03-Jul-87 0737 @MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu Macros again: read first
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jul 87 07:37:33 PDT
Received: from iucs.cs.indiana.edu (TCP 30003147315) by MC.LCS.MIT.EDU 3 Jul 87 10:37:58 EDT
Date: Fri, 3 Jul 87 09:35:49 est
From: Matthias Felleisen <matthias@iucs.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Macros again: read first
I have tried to reformulate my original message to answer some of JAR's
questions (there have been several exchanges between the two of us). This is
not a complete counterproposal and I don't have the time to come up with a
complete counterproposal. The purpose of this note (and its predecessor) is
to stimulate the committee to think in different ways about the issue of
macros and related matters.
1. Old-style macros have two purposes. First, they are used to extend
the set of available syntactic facilities. Second, they also have the
power of performing arbitrary computations on their input expressions
and the existing environment at compile time.
2. From my point of view, the extension of syntax is the addition of
syntactic forms to (a possibly extended) RRRS and the definition
of their semantics via an equivalence with already available facilities.
It follows that an extension of syntax is a map from (abstract syntax) trees
to (abstract syntax) trees. These tree domains are only a subset of the
domain of S-expressions and that is the important point.
Because the input/output domains are tree domains, i.e., they neither
posses state nor are they circular (this does not mean that they cannot
contain closures that are circular or have state), there is no need to use
side-effects for the manipulation of the input/output structures.
Assignments exist for the sole purpose of creating circularities and of
modeling state [NOTE: People use assignments for other purposes as well, but
these (first-order) uses can be eliminated without restructuring the entire
program (as in store-passing and continuation-passing style programming for
the general solution].
In the same vein I can argue against call/cc the second, non-functional
computational primitive (the uses for expansion time can be anticipated by
the expander as opposed to the transform function). In short, the
manipulation of abstract syntax trees requires nothing but the purely
functional subset of Scheme and this should be accounted for.
3. According to the preceding explanation, I call "macros" the set of
unrestricted transformation functions, which possibly use side-effects,
jumps (i.e. call/cc) etc.; "extend-syntax" is the facility which implements
functional transform functions.
4. Would Eugene's extend-syntax do it?
No, it is too powerful. It provides a WITH-construct for arbitrary
manipulations. [I believe the facility was added for macro-lovers
but Eugene can answer this better.] The WITH must be restricted so
that it conforms with the functional spirit. For inserting circular closures
or closures with state in the output tree I perceive the need for a more
expressive target language for the expander, i.e. a language where such
things can be written down. [I personally see a need for this and have used
this quite often, but as I said it suffices to extend the target language
or to accept a restricted with.]
The pattern language of Eugene's extend-syntax is not essential. A
restriction of MacroScheme to cons, car, cdr, map etc and and exclusion of
set!, set-car!, set-cdr!, eq?, etc. should do it although I believe that
the pattern language is in most instances more convenient. [Hundreds of
students at Indiana get along with it and encounter very few problems so
I also think that it is not difficult to learn.]
Side-effects for debugging. I have had to debug hundreds of extend-syntax
macros in the past 2 or 3 years (and several of the transformers). I have
practically never used side-effects in the WITH-clauses but always in the
expansion part of the macros. Perhaps the pattern languages has helped,
perhaps I am too optimistic. On the other hand, I could also imagine that
we add debugging aids to the functional MacroScheme language. I can see
that this point deserves discussion.
-- Matthias
[JAR was disturbed by the rhetoric of this note. If there is any, I ask you
to overlook it.]
∂06-Jul-87 0517 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 05:17:17 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 6 Jul 87 08:17:50 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA14560; Mon, 6 Jul 87 08:15:26 EDT
Posted-Date: Mon, 6 Jul 87 08:15:09 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA06553; Mon, 6 Jul 87 08:15:09 EDT
Date: Mon, 6 Jul 87 08:15:09 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8707061215.AA06553@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Tigger on Scheme
------------ Forwarded from the MilneNet -------------
Posted-Date: Mon, 6 Jul 87 07:46:39 EDT
Date: Mon, 6 Jul 87 07:46:39 EDT
From: Tigger@Hundred-Acre-Woods.Milne
To: ramsdell@linus.uucp
Subject: Scheme
The wonderful thing about Scheme is:
Scheme is a wonderful thing.
Complex procedural ideas
Are expressed via simple strings.
It's clear semantics, and lack of pedantics,
Help make programs run, run, RUN!
But the most wonderful thing about Scheme is:
Programming in it is fun,
Programming in it is FUN!
------------------------------------------------------
Gerry started the last Scheme meeting with a stated desire that it be
fun. I have to observe that laudable goal was lost by the end of the
meeting. I enjoyed most of the meeting, and I am enthusiastic about
the prospect of agreement on the most important issue in my opinion:
the issue of macros. I enjoyed talking with you all. Let's not get
too serious about Scheme.
John
∂06-Jul-87 0530 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 05:30:44 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 6 Jul 87 08:18:34 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA14571; Mon, 6 Jul 87 08:16:05 EDT
Posted-Date: Mon, 6 Jul 87 08:15:48 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA06559; Mon, 6 Jul 87 08:15:48 EDT
Date: Mon, 6 Jul 87 08:15:48 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8707061215.AA06559@darwin.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: Tigger on Scheme
------------ Forwarded from the MilneNet -------------
Posted-Date: Mon, 6 Jul 87 07:46:39 EDT
Date: Mon, 6 Jul 87 07:46:39 EDT
From: Tigger@Hundred-Acre-Woods.Milne
To: ramsdell@linus.uucp
Subject: Scheme
The wonderful thing about Scheme is:
Scheme is a wonderful thing.
Complex procedural ideas
Are expressed via simple strings.
It's clear semantics, and lack of pedantics,
Help make programs run, run, RUN!
But the most wonderful thing about Scheme is:
Programming in it is fun,
Programming in it is FUN!
∂06-Jul-87 0845 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Macros again: read first
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 08:44:58 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 6 Jul 87 11:01:24 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA20362; Mon, 6 Jul 87 10:55:59 EDT
Posted-Date: Mon, 6 Jul 87 09:36:27 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA06667; Mon, 6 Jul 87 09:36:27 EDT
Date: Mon, 6 Jul 87 09:36:27 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8707061336.AA06667@darwin.sun.uucp>
To: matthias@iucs.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Matthias Felleisen's message of Fri, 3 Jul 87 09:35:49 est <8707031439.AA00576@mitre-bedford.ARPA>
Subject: Macros again: read first
Please clarify one issue: Is your "counterproposal" at odds with the
PREPROCESS three-quarter macro proposal? That is, are you arguing for
restricting the proceedures given to ADD-KEYWORD, the restriction
being that the procedures are functional? Or are you arguing against
what was decided last weeks Scheme meeting?
Please don't make me take back my words:
..... I enjoyed most of the meeting, and I am enthusiastic about
the prospect of agreement on the most important issue in my opinion:
the issue of macros.
John
∂06-Jul-87 1147 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Tigger on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 11:47:40 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 6 Jul 87 14:34:28 EDT
Received: by ZOHAR.AI.MIT.EDU; Mon, 6 Jul 87 14:28:44 edt
Date: Mon, 6 Jul 87 14:28:44 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8707061828.AA07651@zohar>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Mon, 6 Jul 87 08:15:09 EDT <8707061215.AA06553@darwin.sun.uucp>
Subject: Tigger on Scheme
thank you for the neat poem.
∂08-Jul-87 1607 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com structures
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87 16:07:17 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Jul 87 19:08:20 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa01544; 8 Jul 87 18:53 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ak05511; 8 Jul 87 18:43 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA26009; Wed, 8 Jul 87 14:19:52 PDT
Received: by tekchips.TEK.COM (5.51/6.23)
id AA01100; Wed, 8 Jul 87 14:22:40 PDT
Date: Wed, 8 Jul 87 14:22:40 PDT
From: Norman Adams <adams%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8707082122.AA01100@tekchips.TEK.COM>
Subject: structures
To: rrrs-authors@mc.lcs.mit.edu
The following outlines a facility for defining new record types. Such a
facility could be implemented using whatever we come up with for macros,
and PROJECT/INJECT/IN? as described in Will's minutes from the lunch
meeting at the '86 Lisp conference. I am proposing the functionality
described (and implied), not the particular names.
Related issues are modules, types, and object-oriented programming.
This proposal may be premature if we haven't addressed these,
or it may be a stop-gap until we do.
DEFINE-RECORD-TYPE defines a new disjoint record type which has a fixed set
of named fields. DEFINE-RECORD-TYPE defines procedures for making
instances of the type, and accesssing and assigning the fields of the
instances. DEFINE-RECORD-TYPE also defines a predicate which returns
true only for instances of the type defined.
The simplest syntax for DEFINE-RECORD-TYPE is
(DEFINE-RECORD-TYPE typeName fieldName ...)
This would define the procedures
MAKE-<typeName>
<typeName>?
<typeName>-<fieldName> (for each field)
SET-<typeName>-<fieldName>! (for each field)
---------------- Locality of names
Given that DEFINE-RECORD-TYPE is making definitions, where are these
definitions allowed, and what is the scope of these names?
Here are two possibilities. Sketchy implementations illustrate.
1) Use syntactic extension and internal defines to provide local names.
(define-record-type emp name age) ==
(begin (define make-emp (lambda () ...))
(define emp? (lambda (x) ...))
(define emp-name (lambda (emp) ...))
(define emp-age (lambda (emp) ...))
(define set-emp-name! (lambda (emp name) ...))
(define set-emp-age! (lambda (emp age) ...))
)
DEFINE-RECORD-TYPE form at top level would define the procedures globally;
but at the beginning of a <body> would define the procedures locally. This
assumes that code generated by macros works the same way as "source" code.
2) Provide a procedural interface to make new record types, don't depend
on internal define. DEFINE-RECORD-TYPE is one possible syntactic
extension which uses MAKE-RECORD-TYPE, a procedure. This approach could be
combined with the first.
(define-record-type emp name age) ==
(begin
(define make-emp '#!unspecified)
(define emp? '#!unspecified)
(define emp-name '#!unspecified)
...
(let ((new-record-type-frob (make-record-type 'emp '(name age))))
(set! make-emp (record-type-constructor new-record-type-frob))
(set! emp? (record-type-predicator new-record-type-frob))
(let ((selectors (record-type-selectors new-record-type-frob))
(assigners (record-type-assigners new-record-type-frob)))
(set! emp-name (record-type-selector selectors 0))
(set! emp-age (record-type-selector selectors 1))
(set! set-emp-name! (record-type-assigner assigners 0))
(set! set-emp-age! (record-type-assigner assigners 1))
))))
This approach provides an interface which does not force particular names
on the client.
---------------- Initializers
There are many possible enhancements that can be made to this
simple form of DEFINE-RECORD-TYPE. Record facilities often provide
some way to do some form of initialization.
Some possibilities:
- Fields are initialized to values passed to the constructor.
Either require that a value be passed for each field, or have
some indication for each field in the DEFINE-RECORD-TYPE form
that the constructor will or will not be passed a value with which
to initialize the field.
- An initial value for each or any field may given in the
DEFINE-RECORD-TYPE form. The expression for an initial value might be
evaluated one time, or once per call to the constructor. If not the
latter, when is the expression evaluated?
What is the syntax for any of this?
---------------- Other issues
What is the name? DEFINE-STRUCTURE, DEFINE-STRUCTURE-TYPE, DEFSTRUCT
READ and WRITE syntax.
Unitialized fields - it "is an error" to access an uninitialized field?
Do we want to say anything about redefinition? If you load a file
containing a DEFINE-RECORD-TYPE, say for EMPLOYEE, are existing instances of
EMPLOYEE still going to answer true to EMPLOYEE? after you reload
the file?
Do we want to support variant records in any way?
I think there is a temptation to featurize a record package to compensate
for the lack of strong types.
-- Norman
-------
∂09-Jul-87 0853 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU re: structures
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 08:51:40 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 9 Jul 87 11:52:03 EDT
Date: 9 Jul 1987 11:45:15 EDT
Subject: re: structures
From: Morris Katz <MKATZ@A.ISI.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
Stewart Clamen built a structures packages for MIT CScheme which is almost
identical to the one proposed by Norman Adams. It however contained a few
additional ideas which I believe are worth considering. These all take the
form of options at strucutre declaration time. The first is an option as to
whether a structure should carry along its type and be runtime type checked
each time an accessor or mutator utilizes it. This allows the user
a trade-off between type security and execution efficiency. The second option
is the ability to specify whether accessors, mutators, etc should be built as
procedures, macros, or both. In order to efficiently manipulate structures
it may be desirable to have accessors and mutators be macros to avaoid the
extra function call overhead.
Morry Katz
-------
∂09-Jul-87 1935 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU structures
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 19:34:59 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 9 Jul 87 22:32:53 EDT
Received: by ZOHAR.AI.MIT.EDU; Thu, 9 Jul 87 22:33:22 edt
Date: Thu, 9 Jul 87 22:33:22 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8707100233.AA08839@zohar>
To: MKATZ@A.ISI.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Morris Katz's message of 9 Jul 1987 11:45:15 EDT <8707091602.AA08685@zohar>
Subject: structures
Actually, I think that such worrying about function-call overhead is
the problem of a compiler, not of a user. The compiler should be
willing to integrate procedures, when it is advantageous. Such
optimizations may require compiler declarations, but I don't think
that they belong in the language at this point.
∂09-Jul-87 2321 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU re: structures
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 23:21:26 PDT
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 10 Jul 87 02:19:53 EDT
Date: Thu 9 Jul 87 23:13:27-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: re: structures
To: MKATZ@A.ISI.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Message from "Morris Katz <MKATZ@A.ISI.EDU>" of Thu 9 Jul 87 11:45:15-PDT
Message-ID: <12317165967.21.ANDY@Sushi.Stanford.EDU>
Morris Katz <MKATZ@A.ISI.EDU> wrote:
[He discussed a structures package written by Steware Clamen that is
similar to Norman Adams' proposal. He mentioned some of its
additional properties.]
The first is an option as to whether a structure should carry along
its type and be runtime type checked each time an accessor or mutator
utilizes it. This allows the user a trade-off between type security
and execution efficiency.
If this trade-off is controlled by options in the structure
definition, I sure hope the sense of the option is "right". The
default should be as type secure as possible.
The context where accessors and mutators are used should determine
whether or not run-time type-checking is performed. If implicit and
explicit type-checking is never used at run-time, the type information
may be optimized away. (That may not be possible for top-level
definitions in an interactive system, but ....) T (and MacLisp) had a
primitive version of this for predefined structures (cons' and vectors
are the ones I remember); if a procedure is compiled with the
appropriate options, the compiled code does not include type-checks.
#include {standard args for incomplete type-inference systems}
I realize that Adams' proposal does not have the hooks for a useful
type-inference system, but that is a good direction to leave open.
-andy
-------
∂10-Jul-87 2311 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Minutes of the Scheme meeting etc.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 23:11:18 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Jul 87 02:08:00 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ae28446; 11 Jul 87 1:54 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id be00569; 11 Jul 87 1:48 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA22718; Fri, 10 Jul 87 17:58:59 PDT
Received: by tekchips.TEK.COM (5.51/6.23)
id AA15349; Fri, 10 Jul 87 17:57:31 PDT
Message-Id: <8707110057.AA15349@tekchips.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Minutes of the Scheme meeting etc.
Date: 10 Jul 87 17:57:29 PDT (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Minutes of the Scheme meeting at MIT on Saturday, 27 June 1987
Attendees included:
Hal Abelson (MIT)
Norman Adams (Tektronix)
David Bartley (Texas Instruments)
Alan Bawden (MIT)
Gary Brooks (Indiana U)
Terry Caudill (Texas Instruments)
Stewart Clamen (BBN/CMU)
Will Clinger (Tektronix)
Olivier Danvy (Copenhagen U)
Bruce Duba (Indiana U)
Kent Dybvig (Indiana U)
Matthias Felleisen (Indiana U)
Anne Hartheimer (Semantic Microsystems)
Chris Haynes (Indiana U)
Bob Hieb (Indiana U)
Morry Katz (Rockwell/MITRE)
Richard Kelsey (Yale)
David Kranz (Yale)
Eugene Kohlbecker (U Rhode Island)
Jim Miller (MIT/Brandeis)
Jim Philbin (Yale)
Kent Pitman (Symbolics)
Eric Ost (Indiana U)
John Ramsdell (MITRE)
Jonathan Rees (MIT/DEC)
Bill Rozas (MIT)
Gerry Sussman (MIT)
Mitch Wand (Northeastern U)
Peter Williams (U Illinois)
After much rearrangement of chairs and table, Mitch Wand opened the meeting
around nine-thirty. The participants introduced themselves and, if they
wished, explained what they use Scheme for and what they want for and from
Scheme.
ENVIRONMENTS
Then Hal Abelson instigated "a sample foray into content" by asking
whether anyone was so absurd as to think that pattern matching is good
or first class environments are bad. Gerry Sussman said that first class
environments as in MIT Scheme are a disaster but that another kind
was useful. Bill Rozas elaborated by saying that (THE-ENVIRONMENT)
is too powerful; experience at MIT showed that it was primarily used
in situations where
(build-environment <base-environment>
(define ...)
(define ...)
...)
would suffice. The environment resulting from BUILD-ENVIRONMENT could
then be used as an argument to EVAL. The effect of top-level definitions,
as in (EVAL '(DEFINE ...) ENV), is still a thorny question. MIT's view
is that its incremental definition semantics is just a debugging tool.
Gerry suggested that if you don't specify a base environment to
BUILD-ENVIRONMENT then you should get an empty one.
Jonathan Rees pointed out that ML-style modules need to be studied as an
alternative. Norman Adams observed that he saw environments being used
in two different ways: (1) programming in the large (modules); (2) tables
indexed by symbols; he stated that the first was a good use but the second
was bad. Jonathan contrasted environments with modules, saying that the
module problem was to hook files together without having to use a gigantic
LETREC, while environments and EVAL were useful mainly for performing a
kind of reflection in the sense of Brian Smith's thesis.
Gerry explained his derivation of a sine routine without using magic
constants as an example of a legitimate use of EVAL. Against complaints
from Will Clinger that people needed to be discouraged from using EVAL,
he said "Our job is not to protect losers from themselves, but to
provide winners with what they need to win."
Kent Pitman then presented T's original approach of breaking EVAL into
smaller pieces that might reflect the stages of compilation and linking
that are involved in separate compilation.
A committee was formed to think about EVAL and environments and to
report back. It was suggested that the members should be Kent Pitman,
Kent Dybvig, Alan Bawden, Jonathan Rees, and one of Bill Rozas and
Chris Hanson.
YELLOW PAGES (LIBRARY)
Bill Rozas was appointed as the first librarian, or keeper of unsupported,
user-contributed software. Anne Hartheimer will provide some assistance
at first. Contributions to the library should be sent to
scheme-librarian@mc.lcs.mit.edu.
MULTIPLE RETURN VALUES
Multiple return values were tabled after much discussion, little
agreement.
SHOULD COLON REALLY BE AN EXTENDED ALPHABETIC CHARACTER
Yes.
PATTERN MATCHING
No change, to be left to the library.
NUMBER SYNTAX
Students find it confusing that 0+3i works but 3i doesn't. Alternative
syntaxes were discussed briefly.
Questions were raised about the semantics of exactness and inexactness.
Concerning input syntax: Is 12.5 exact? What to make of #e#s12345?
It was suggested that (> #i5 #i4) should cause smoke to come out of the
machine.
This discussion was continued on the afternoon of the second day.
The meeting adjourned about five o'clock.
================================================================
Minutes of the Scheme meeting at MIT on Sunday, 28 June 1987
[Attendance was not noted the second day, but Julian Padget (U Bath) was
one addition to the first day's roster.]
Mitch Wand called the meeting to order around nine o'clock.
Alan Bawden explained the macro proposal that he had posted to RRRS-AUTHORS.
It seemed to be pretty much the right thing, but a number of questions
remain:
What is its relationship to expansion-passing style?
Where do you get the expand-time environment? Can you change it?
Can macros return DEFINE forms?
How do "top level" macro definitions work?
Should free variables in a file be resolved as absolute or as
relative to a LOAD-environment?
Should atomic, e.g. PI, macro forms be supported?
Does anyone have a nice user interface for the macro machinery?
Can a symbol be an identifier (variable) and a macro keyword at
the same time?
Which of EVAL, COMPILE, EXPRESSION->VALUE, etc, takes a syntax
table argument?
Matthias Felleison complained that the proposal was too powerful and/or
concrete. Mitch Wand characterized Matthias's concerns as:
What is the nature of the input language? It was agreed that it
consist of lists and preprocessed expressions.
What is the nature of the output language? It was agreed that it
would be abstract, and didn't matter.
Should there be restrictions on the possible transformations?
This seemed to be the essence of Matthias's objections.
Matthias agreed to post a more formal statement of his concerns to
RRRS-AUTHORS.
A straw poll indicated that nearly all were in favor of moving forward
from Alan's report.
CUSTOMIZABLE READER
Will Clinger solicited comments about a customizable reader he was
proposing for the yellow pages. The proposed reader did not solve
the main problem that people seemed to want customizable readers
for, namely the need to load code that was written with different
lexical conventions.
NUMBER PROPOSAL
Gerry Sussman and Will Clinger then presented a revised number syntax
and semantics they and David Bartley had worked on the previous evening.
Probing questions revealed that the semantics of inexact numbers were
still unclear, and the matter was tabled after much argument.
EuLISP
Julian Padget presented a summary of generic procedures in EuLisp.
EQV?
Bill Rozas requested that the R3RS be changed to permit (EQV? "" "")
to be false, because empty strings are extensible in MIT Scheme. This
was opposed by Will Clinger, on the grounds that extensions were
permissible only insofar as they were not in conflict with the language
specification. Much irrelevant discussion ensued concerning English
descriptions versus formal semantics, the social value of lawyers, and
the lessons of history concerning the decline and fall of programming
languages. When discussion returned to the technical issue, the
participants were in no mood to agree.
OPTIONAL PROCEDURES
It was suggested that optional procedures should either be made essential
or moved to the yellow pages. The general feeling, however, was that
the non-essential procedures helped to define a layered language, which
was good. Bill Rozas suggested that the "yellow pages" library could
contain a supported section containing implementations of the standard
but non-essential procedures.
A committee was appointed to think about language stratification: David
Bartley, Bruce Duba, Jim Miller, Bill Rozas, and Gerry Sussman.
NEXT MEETING
People from Indiana University offered to host the next meeting, in the
fall. [My notes do not show the year; I assume the next meeting would
be in the fall of 1988. Question: Why not have it at the ACM Conference
on Lisp and Functional Programming?]
The meeting adjourned about five o'clock.
================================================================
Feeling that the weekend meeting had not accomplished all that needed
to be accomplished, a small group of implementors met on Tuesday evening
around six o'clock. Present were David Bartley (TI), Will Clinger
(Tektronix), Chris Hanson (MIT), Jonathan Rees (MIT), and Bill Rozas (MIT).
It was noted that Chez Scheme was not represented at all, and that T was
represented only by Jonathan. Agreements made by this small group are
certainly not official or binding on anyone (as indeed is true of decisions
made by the larger group), but they may be of interest as an indication of
the direction certain implementations are going.
[My notes record the topics in the order in which they were proposed for
the agenda, not the order in which they were discussed.]
MACROS
The situation is pretty much ok. It looks like most of the work is going
to have to be done by people at MIT, because that's where the largest
concentration of macrologists seems to lie.
ENVIRONMENTS & MODULES
Let's get some serious discussion going on RRRS-AUTHORS. This is important.
STRUCTURES & OPAQUE OPBJECTS
We didn't even touch on this over the weekend, though Norman Adams had
prepared a list of issues. Norman should post to RRRS-AUTHORS in order
to get something going. This is also important.
OPTIONAL ARGUMENTS
We agreed to use the #!OPTIONAL syntax as in MIT Scheme. For example,
(lambda (x #!optional y z . w) ...)
evaluates to a procedure with one required argument, two optional arguments,
and a rest argument. How do you tell if an optional argument is supplied?
It is not supplied if its value satisfies the DEFAULT-OBJECT? predicate.
For example, the WRITE procedure might be written
(define (write x #!optional p)
(let ((p (if (default-object? p) (current-output-port) p)))
...))
A feature of this approach is that the caller can pass a default object
as an argument, thereby faking an unsupplied argument. This is nice
when you want to supply a value for one optional argument without
supplying for any other optional arguments that precede it in the
argument list.
We did not decide on a syntax for default objects. This may have been
an oversight. You can get a default object by writing
((lambda (#!optional x) x)).
MULTIPLE RETURN VALUES
We agreed on the names VALUES and WITH-VALUES for the procedures that
return and accept multiple values, respectively. VALUES takes any
number of arguments and returns them as multiple values. WITH-VALUES
takes two arguments, of which the first is a thunk that may return
multiple values and the second is a procedure to be called on the
values returned by the thunk.
Since the five or six alternative semantics that people are considering
are linearly ordered by upward compatibility, it doesn't matter too
much what particular implementations do in the short term. Texas
Instruments will probably implement a semantics in which a continuation
that expects a single return value will accept any number of return
values, ignoring extra return values and seeing #F as the return value
if there are actually no return values.
EQUIVALENCE PREDICATES
The section on equivalence predicates in R3RS was a noble try, but it
satisfied neither those who wanted an abstract, portable definition of
EQV? nor those who wanted EQ? to be an thoroughly implementation-dependent
notion of object identity. Will Clinger volunteered to rewrite the
section, basing it on a notion of object identity implemented by EQ?
that is specified partially in an implementation-independent way, allowing
unspecified behavior to vary at the whim of implementations. EQV? would
then be a less implementation-dependent abstraction of EQ?. The description
of EQUAL? also needs to be tightened up.
The behavior of EQV? on empty strings and empty vectors would be left
implementation-dependent. The behavior of EQ? and EQV? on procedures
would be left as in R3RS; that is, EQ? and EQV? would have to return
true of procedures created by the same evaluation of a lambda expression,
would have to return false of procedures that behave differently (for
example because their local state is different), and would be
implementation-dependent on procedures that behave identically even
though they might have been created by different evaluations of a lambda
expression or lambda expressions.
One effect of these changes will be to make EQV? more like Common Lisp's
EQL procedure.
TOP LEVEL DEFINE SYNTAX
We considered whether the change in the 1986 Scheme standard that made
(define (foo ...) ...) equivalent to (define foo (lambda (...) ...))
instead of (define foo (rec foo (lambda (...) ...))) might have been
a mistake because of the efficiency issue. We decided that we liked
the way it was done in the 1986 standard, but that it was ok for
implementations to default to a "benchmark mode" that treats such
definitions as in the 1985 standard, provided there is a way to
disable benchmark mode.
CONDITION HANDLING
We cannot consider a standard condition (exception) handler until we
have a standard list of exceptions, interrupts, i/o errors, and syntax
errors. We also need some way to associate handlers with conditions
dynamically; fluid variables would be one possibility but are more
general than necessary for this use.
INTEGRABLE DECLARATIONS, CONSTANT DECLARATIONS, AND BLOCK COMPILATION
Most of the perceived need for these would go away if we had a good
enough module facility. Implementations can in the meantime experiment
with block compilation, knowing that most of the work should be
salvageable when modules arrive.
Insight: To declare that something is integrable not only declares it
a constant, but also advises the compiler that constant folding is
worth attempting.
INPUT EDITOR
Jonathan Rees proposed a procedure to make it possible to write a
portable reader that supports editing of input in the native style
on machines whose native style is to evaluate expressions immediately
when the closing parenthesis is typed. He was encouraged to submit
implementations to the yellow pages library. This seems to be a case
where non-portable implementations of a portable concept is appropriate
for the library.
PEEK-CHAR
Jonathan pointed out that the standard input procedures documented
in R3RS are not powerful enough to write a portable reader, because
Scheme lacks PEEK-CHAR and equivalents. We know that all major
implementations except possibly Chez Scheme have a PEEK-CHAR
procedure. We'd like to add PEEK-CHAR to the R3RS if there are no
major objections.
FLUID VARIABLES
We felt that MIT has the best semantics for fluid variables. Its
greatest weakness is its possible inefficiency on multi-tasking
and multiprocessor implementations, but the implementors of MIT
Scheme have some ideas that may solve that problem.
The meeting adjourned around midnight.
================================================================
End of minutes.
∂12-Jul-87 1702 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU (DELAYED? <obj>) predicate
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jul 87 17:01:50 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUL 87 20:00:46 EDT
Received: by VX.LCS.MIT.EDU (4.12/4.8) id AA22868; Sun, 12 Jul 87 20:00:20 edt
Date: Sun, 12 Jul 87 20:00:20 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: (DELAYED? <obj>) predicate
∂12-Jul-87 1711 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU DELAYED? predicate
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Jul 87 17:11:23 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 JUL 87 20:02:23 EDT
Received: by VX.LCS.MIT.EDU (4.12/4.8) id AA22882; Sun, 12 Jul 87 20:01:55 edt
Date: Sun, 12 Jul 87 20:01:55 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: DELAYED? predicate
...sorry, the body of my previous message was delayed. It follows:
PROPOSAL FOR A NEW PREDICATE:
----------------------------
(DELAYED? <object>) ==> #T iff <object> is an unforced PROMISE
created via the DELAY procedure.
#F otherwise
RATIONALE:
---------
Insofar as it is possible to create a PROMISE (using DELAY), it
is desireable to detect if an object is in fact an unforced PROMISE.
To point, I find it occasionally desirable to check if a particular
PROMISE has ever been FORCEd soas to glean some information about the
dynamic behavior of a piece of code (such as, ``has this node in a tree
ever been visited (FORCEd)?''). To my knowledge, PROMISEs are the only
instance of a data-type in Scheme that may be created but not detected.
This makes them somewhat less than first-class in my mind.
SAMPLE IMPLEMENTATION: -- based on RRRS p.27
---------------------
(delay <expression>) --> (make-promise (lambda () <expression>))
(define (make-promise
(lambda (proc)
(let ((already-run? #F) (result #F))
(lambda (message) ; Add a message parameter
(case message ; Dispatch on message
((:FORCE) (cond ((not already-run?) ; Old code for FORCE
(set! result (proc))
(set! already-run? #T) ))
result)
((:DELAYED?) (not already-run?)) )))))) ; Expose the toggle
(define (force
(lambda (object) (object ':FORCE)) ))
(define (delayed?
(lambda (object) (object ':DELAYED?)) ))
CONSIDERATIONS:
--------------
Noting that some implementations may chose to make PROMISEs operationally
indistinguishable from their FORCEd value (e.g. implicit forcing), DELAYED?
may have to be a special form soas NOT to implicitly FORCE its argument.
Finally, I was very careful NOT to propose a predicate PROMISE?, noting
that some implementations may opt to make FORCE actually alter its argument
soas to henceforth be replaced (in the store) by the computed value. I
was likewise careful not to request (FORCED? <object>) which in some
implementations would NOT neccessarily be the logical inverse of
DELAYED? (e.g. may always return #F in implementations that modify the
store as noted above).
~Ziggy
∂15-Jul-87 1303 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu optional arguments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jul 87 13:02:42 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 15 Jul 87 15:38:14 EDT
Date: Wed, 15 Jul 87 14:36:15 est
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: optional arguments
From the minutes of the Scheme implementors meeting:
-------------------------------------------------------------------------------
OPTIONAL ARGUMENTS
We agreed to use the #!OPTIONAL syntax as in MIT Scheme. For example,
(lambda (x #!optional y z . w) ...)
evaluates to a procedure with one required argument, two optional arguments,
and a rest argument. How do you tell if an optional argument is supplied?
It is not supplied if its value satisfies the DEFAULT-OBJECT? predicate.
For example, the WRITE procedure might be written
(define (write x #!optional p)
(let ((p (if (default-object? p) (current-output-port) p)))
...))
A feature of this approach is that the caller can pass a default object
as an argument, thereby faking an unsupplied argument. This is nice
when you want to supply a value for one optional argument without
supplying for any other optional arguments that precede it in the
argument list.
We did not decide on a syntax for default objects. This may have been
an oversight. You can get a default object by writing
((lambda (#!optional x) x)).
-------------------------------------------------------------------------------
This optional feature seems to be useful mainly for efficiency, in that it
makes it possible to avoid the allocation involved in the following:
(define (write x . l)
(let ([p (if (null? l) (current-output-port) (car l))])
...))
where a list would have to be allocated for the optional port.
However not much functionality is gained here, except for the error
checking on the supplied argument count (the second version would swallow
|(write x y z)|, while hopefully the #!opt interface would choke on it),
and a somewhat more convenient access to supplied optional arguments.
The price paid is a more complicated lambda-list interface, and a
rather homely one at that. It is also questionable whether we want to
introduce another special object, the default object. Apparently it is
to be a first class object, which can be referenced and passed around.
I agree that some sort of improved optional argument interface is needed
if Scheme is to continue to support optional arguments to rrrs-specified
procedures. A valid criticism of the present Scheme specification is that
it allows optional arguments without providing a reasonable user interface.
Efficiency is certainly a consideration--many users would like to be able
to write procedures with optional arguments without taking a big efficiency
hit (even worse is the necessity of educating users who need to be concerned
about efficiency of such tradeoffs between functionality and efficiency).
However the issue of usability should also be addressed. The rest-interface
is most useful for procedures that take an indefinite number of arguments,
and its use is strained at best when used to implement restricted optional
arguments. Error checking for excess arguments is messy, and usually
ignored (as in my above example). The process of determining whether
an argument has been supplied, and setting up the correct binding is also
tedious and not very transparent. What is needed is an interface that makes
the whole process safe and transparent, and at the same time allows efficient
implementation. The interface should be attractive enough that users aren't
tempted to use the rest-interface unnecessarily. Of course the usability
problem can be solved by macros, but as long as we are considering moving
something new into the language, it makes sense to provide it at as close
to desired final form as possible, so as to prevent the explosion of
incompatible macro interfaces that try to provide convenient access to an
excessively primitive feature.
Looking at the |#!optional| proposal, it is clear that it solves the problem of
error checking for excessive arguments. It also simplifies checking for the
presence of supplied values and accessing those values for rebinding, since
they may be accessed by name rather than by position in a list. However the
actual checking and rebinding must still be explicitly carried out, and the
process of rebinding is not very transparent, since it is buried inside of
|let|s and |if|s. The introduction of a default value is also questionable,
since its main use is to be looked at and thrown away. The burden of making
sure that it does get checked and replaced is left to the user, and if he fails
to handle it correctly the default value remains to slosh around and cause mysterious errors. (It could get passed along to another procedure with default
arguments!) The cases where the default value is used other than by
|default-object?| are probably (hopefully?) few and arcane, and thus of
questionable significance.
I suspect most users, and systems, would want to build some cleaner interface
on top of the primitive |#!optional| one, so we should investigate such
interfaces with the goal of finding one that can be supported directly by
the Scheme community, keeping optional arguments simple and contained.
One such optional argument interface which has useful features both in terms
of efficient implementation and in terms of a useful user interface is
|case-lambda|, which dispatches on the number of arguments received.
For instance:
(define write
(rec write
(case-lambda
[(x p) ...]
[(x) (write x (current-output-port))])))
Each branch of a |case-lambda| statement is equivalent to a similarly structured
|lambda| statement, except which branch is applied depends upon how many
arguments are supplied. Thus the above is semantically equivalent to:
(define write
(rec write
(lambda l
(apply (case (length l)
[2 (lambda (x p) ...)]
[1 (lambda (x) (write x (current-output-port)))]
[else (error 'write "wrong number of arguments")])
l))))
However in practice the code can be highly optimized, and the list |l| need
never be created. Since the internal |write| has lexical scoping, the call to
it in the second case should be just a jump. The actual dispatching on
the argument count can also optimized by the compiler, probably resulting
in better performance than that provided by checks against a default
value, even if the |default-object?| predicate is recognized by the compiler.
So, provided that one is willing to let the compiler recognize
one more special form, the performance for |case-lambda| should be excellent.
|case-lambda| also provides a simple user interface. The default value
problem goes away. The status and intent of procedure parameters is
signaled immediately--one needn't look at the code body to determine where
the real value is available and where it isn't. If an argument is visible
in a piece of code, it has a 'real' value. The number of new identifiers and
forms is also minimized. While the #!proposal introduces |#!optional|
and |default-object?|, and probably something like |#!optional-default-object|,
|case-lambda| needs only its own name, and for those who like to keep
core special forms to an absolute minimum, |lambda| can clearly be defined
as a special case of |case-lambda|. One argument for the naturalness of the
|case-lambda| specification of procedures that take optional arguments is that
it is very similar to the specification patterns used in the rrrs for
procedures that accept optional arguments. It seems to be a natural way
to think and write about them.
Another useful feature of |case-lambda| is that it makes it simple to
treat any of the arguments to a procedure as optional, not just those
on the tail of the argument list. For instance if one thought the port
should come first (but still be defaulted) in |write|:
(define backwards-write
(case-lambda
[(p x) (write x p)]
[(x) (write x (current-output-port))]))
A more realistic example is |-|, in which it IS the first argument that
is missing when only one is provided:
(define -
(case-lambda
[(x y) (minus x y)]
[(x) (minus 0 y)]
[(x . l) (let loop ([total x] [rest l])
(if (null? l)
total
(loop (minus total (car l)) (cdr l))))]))
This points out a drawback to all the optional argument interfaces
presented so far--none supply a simple way to avoid the allocation
involved when indefinitely many arguments are allowed. Often one ends
up with the above situation, in which the list is used as a stack and
never escapes, but still must be allocated. Note that the following simpler
definition would be incorrect since the list is reallocated on the recursive
calls to |-| in the third case:
(define -
(rec -
(case-lambda
[(x y) (minus x y)]
[(x) (minus 0 y)]
[(x y . l) (apply - (minus x y) l)])))
The problem is that the allocation involved in creating the lists will
be quadratic in relation to the number of arguments, when the algorithm
should of course be linear. (Perhaps this really points out a problem in
the interaction between |apply| and the rest-interface.)
Either the |#!optional| and |case-lambda| technique can be implemented with
macros in systems that don't wish to provide the interface as a primitive.
There is a problem in implementing the |#!optional| interace as a macro
though--what is to be the special optional-default-value? Clearly it
should be unique--not |eq?| to anything else in the system. However it is
also desirable that no primitive type predicates other than |default-value?|
answer yes to it, and it should be atomic--consequently it should not be
just a unique structured object obtained by something like:
(define *optional-default-value* '(*optional-default-value*))
The one feature that |#!optional| provides that |case-lambda| doesn't is the
ability to sneak around the normal interface by providing the optional-
default-value in the middle of an argument list--perhaps as an argument
to something like
(define (substring s #!optional start end)
(let ([start (if (default-object? start) 0 start)]
[end (if (default-object? end) (string-length s) end)])
...)
which could then be called with something like
(substring some-string (default-optional-object) some-end)
instead of
(substring some-string 0 some-end)
which of course is a straw-man argument, but I suspect it might be hard
to come up with many good examples where that feature would be useful.
It would almost have to be a case where one couldn't know or access the
default. And of course once such an object "gets loose" it becomes tempting
to use it in other similar contexts. For instance |(assq x al)| might return
it if |x| isn't found, otherwise it could return the value associated with |x|--
arguably a more useful and natural interface, but as the special optional-
default-value floats around it will become as useful as |#f|, and eventually as
useless. Perhaps |(values)| should return it to a continuation expecting one
value? It is worth considering just why |#f| isn't usable as the special
optional-default-value, and wondering whether a new optional-default-value
would eventually suffer a similar fate. One way to preserve the "odv" for
its original intended use is to forbid its use as a value. Referencing
a defaulted identifier then forces an error similar to referencing an
unbound symbol. But then |default-object?| (which should then be renamed
something like |supplied?|) becomes yet another special form, and the above
trick goes away (as perhaps it should), and of course implementors have yet
another error to trap, users have yet another error to stumble over, and
the optional-interface becomes even more difficult (if not impossible) to
implement correctly as a macro.
Revising the |#!optional| syntax so that default values are specified
overcomes most of its problems, but is still not useful as |case-lambda|
in many common situations. One might have
(lambda (x ... #!optional [y v] ... . z) e ...)
or something similar, in which the |v|s are the default values for the
optional |y|s. For instance:
(define (write x #!optional [p (current-output-port)])) ...))
One new question this raises is the scoping of the |v|s--which of the
identifiers in the parameter list should they be allowed to see?
The simplest answer is none, but that makes it difficult to write
procedures like |substring| from above, where the defaults depend on
the supplied values. So perhaps they should be able to see the
required arguments--or even the supplied optionals--or perhaps all the
identifiers to each value's left, with a |let*| semantics...
Unlike |case-lambda|, the scoping is not obvious. It is also hard
to use it to define certain classes of procedures with optional arguments.
For instance try using this syntax on |-|.
(define -
(let ([flag '(flag)])
(lambda (x #!optional [y flag] . l)
(if (eq? y flag)
(minus 0 x)
(let loop ([total (minus x y)] [rest l])
(if (null? l)
total
(loop (minus total (car l)) (cdr l))))))))
is the best I can do, and I don't much care for the way it looks, nor
does it look like it is going to be easy to optimize.
The comparison procedures like |<| lead to equally murky results using
this version of |#!optional|, but are relatively clean using |case-lambda.|
In conclusion, |case-lambda| provides a pretty and simple high-level
optional interface that can be efficiently implemented without further
overloading of the identifier-list and without requiring the introduction
of new special objects.
∂21-Jul-87 1512 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jul 87 15:12:36 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Jul 87 17:44:14 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA12424; Tue, 21 Jul 87 12:48:01 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Jul 87 09:45:43 GMT
From: mcvax!inria!crcge1!adams@seismo.css.gov (Drew Adams)
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
Message-Id: <2698@crcge1.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
WARNING: This is a bit long
In article 444 of comp.lang.misc Robert Firth writes:
... In applicative languages, repeated evaluations of an
expression always yield the same result, so we can replace
delayed evaluation by true lazy evaluation, ie evaluate
once only when first referenced. ...
SUMMARY:
I agree, but argue that this is not true of all applicative
languages; in particular, it's not true of pure LISP, due to its
treatment of quotation.
The meaning of the term "lazy evaluation" is not universally agreed
upon. Some use it to mean "call-by-need", i.e. the one-shot
evaluation referred to above. Others identify it with "call-by-name"
(or "normal order reduction" in the context of the lambda calculus
and combinatory logic.) "True" call-by-need is now more commonly
termed "fully lazy reduction" in functional programming circles.
Henderson & Morris and Friedman & Wise are usually credited with the
introduction of "lazy evaluation". I believe Wadsworth was the first
to speak of "call-by-need" and in any case he was the first to point
out the delicacies of "full laziness", although I believe the latter
term is due to Hughes. The concepts of different evaluation orders
are of course much older than these terms, predating the electronic
computer age [Church, Curry, Rosser].
The simple argument given above by Firth bears repeating and is the
basis for the assertion that "lazy evaluation and side effects don't
mix" (cf. Abelson & Sussman).
I would only add one change to the argument: full laziness lends
itself most naturally not to applicative (functional) languages in
general but, more precisely, to those respecting "*reduction*
semantics". In particular, the purely functional language "pure
LISP" (without side effects but with built-in quotation) does *not*
respect such semantics and is thus not easily made (fully) lazy. The
issue is quotation. Without its built-in recognition of quotation
LISP otherwise has reduction as its operational semantics.
To be "applicative" or "purely" functional a language must be
"referentially transparent", meaning that the same expression, in the
same definitional context, is always evaluated to the same result.
Pure LISP has this property.
"Reduction semantics" refers to the property of always being able to
replace an expression by its result, in the same definitional
context, without altering the result of the overall computation.
Because of this property, an expression and its reduction may thus be
said to "*denote* equivalent values". The property which Mr. Firth
referred to above, of obtaining the same result no matter how many
times an expression is evaluated, is implied by reduction semantics,
but not, I believe, by the semantics of pure LISP.
Of course, due to the possibility of side effects, in *impure* LISP,
re-interpretation of even the *same* code may produce different
results. Here, however, the issue is *repeated* interpretation of
code -- not that original source code is interpreted more than once,
but that the *result* of interpretation is then interpreted and
possibly re-interpreted ....
Once *reduction* of an expression is started we can assume that it
proceeds all the way to some kind of an irreducible (normal) form, so
that further attempts at reduction have no effect. In lazy
functional languages this final form is not usually "*the* normal
form" of the lambda calculus in which no redexes (reducible
subexpressions) appear, but the so-called "weak head", or "lazy"
normal form, in which only the outermost function application need be
irreducible. In reduction-based languages intermediate forms aren't
normally even available to the programmer. This is not a problem
semantically; one never need worry about reduction having "gone too
far", because the intermediate, as well as initial and normal forms,
may all be seen as equivalent.
I don't know what (pure) LISP's operational semantics should be
called. If it weren't already in use we might consider the term
"denotational" to characterise its *operational* semantics, since the
built-in recognition of quotation provides the ability to distinguish
*different levels* of representation of meaning.
The LISP expression (QUOTE FOO) might be said in a sense to denote
the expression (value) FOO to which it evaluates, but the two aren't
equivalent; i.e. there are many contexts in which one can't be
replaced by the other without changing the overall meaning and
result. For example, if the value of FOO is defined to be 2 then
(NUMBERP FOO) is true (T), whereas (NUMBERP (QUOTE FOO)) is false
(NIL). (For simplicity, let's assume denoted values are always
expressions; values of the function represented by the functor QUOTE
are necessarily so.)
In a reduction-based language, if A is defined as B, and B as C,
reducing A gives C, and all three may be said to have equivalent
meaning, as determined, or shown, by the operation of the language's
equality predicate. In LISP on the other hand, if A is defined to
have the value B, and B to have the value C, evaluating A gives B,
not C. This behavior is due to the recognition of QUOTE. The
meaning of A isn't necessarily the same as that of B, let alone that
of C, as determined by LISP predicates such as EQ and EQUAL.
Denotation, unlike reduction, is leveled: A may denote B which
denotes C..., but we need not (indeed had better not) assume this
means, e.g., that A denotes C. Thus, if A (LISP-) evaluates to B,
and (independently) B evaluates to C, we can assume neither that A is
equivalent to C, nor that A denotes C. (In this case, the fact that
evaluation of A stops at B means that (QUOTE B) was necessarily
encountered during the evaluation of A.)
Having such a denotation mechanism available in a language
facilitates a leveled view of things. However, it would seem that
most programmer use of quotation in LISP doesn't really involve
intentional semantic leveling. The most frequent uses of quotation
in LISP would appear to be:
* to prevent the attempted evaluation of something which is
undefined, together with the ensuing error treatment
* to prevent the immediate evaluation of a defined expression
because the moment isn't right.
The first of these is by definition unnecessary in a language
"tolerant of the undefined". By this I mean that undefined
expressions are simply regarded as irreducible (in normal form) and
provoke no error treatment. (By "undefined expression" I mean an
expression matching no definition left hand side.) Most "rewriting
systems" are so tolerant; most functional languages are not, although
many permit the declaration of constructions.
The second common use of LISP quotation may be motivated by concerns
of correctness, as well as efficiency. The correctness concern is
due to the fact that replacing an expression by its value doesn't, in
general, preserve semantic equivalence, as was indicated above.
Besides the special treatment of quotations, this is due to the
non-declarative nature of (impure) LISP. The efficiency concern is
due to the "eager" (non-lazy) nature of LISP. Even if it would not
be incorrect in a given situation to evaluate certain expressions, it
may be advisable on efficiency grounds to postpone their evaluation,
perhaps indefinitely.
Reduction semantics dispense with the first of these concerns, and
lazy interpretation (*normal order* reduction) may be used to
alleviate the second: subexpressions of an interpreted expression
are not necessarily reduced. In LISP, for example, one often places
oneself at a meta-level to construct some code which is passed around
and manipulated, and then at an opportune moment is executed. In a
lazy language such code need not be treated as quotation: as long as
its interpretation isn't needed by the functions which pass it around
it won't be reduced. Even without laziness, as long as the code is
underdefined little or no reduction can take place, so that code may
be constructed directly without it needing to pass through a phase
where it takes on the form of a construction such as a list. (A
function application may be underdefined either because all its
arguments are not yet present ("partial parameterization") or because
no definition for it has yet been interpreted.)
In other words, QUOTE is mainly used by LISP programmers to offset
the eagerness of EVAL. If one weren't afraid of throwing oil on
forscoming lithpian flames (this one can feel the heat already) one
*might* argue that, as all computation in LISP is evaluation (in a
denotational sense), the programmer is obliged to conceptually move
up and down between semantic levels that are essentially artificial
in a purely declarative setting. They don't correspond to her
conception of the meaning of the program but rather function as an ad
hoc mechanism to keep the eagerness of EVAL at bay. She in fact
eventually learns to ignore or abstract from them when mentally
interpreting code. LISP requires programmers to employ quotation
even when it serves no apparent semantic purpose. (Such overuse
would of course be greatly reduced were programmers not obliged to
consider also the side effects and referential opacity of (impure)
LISP.) (Cf. Wadler)
Likewise, it would seem that in our daily reasoning we are rarely
conscious of using more than few semantic levels at once.
Nevertheless, there *are* times when a device for manipulating
programmer-defined levels of denotation is useful. Implementation/
manipulation of languages is a typical example where quotation is
appropriate. As such leveling is a very powerful abstraction
construct, it would be desirable not to have to do without denotation
in opting for reduction semantics. One would like to be able to
define meta-meta-levels, and so on. Fortunately it's easy to have
our cake and eat it too in a reduction-only setting by simply
programming quotation/denotation *explicitly* for use just where we
need it.
Consider the hypothetical question
"What is the denotation of ((3 - 7) + (4 / 2)) * 6 ?".
A reduction interpreter is only in effect able to respond
"It's the denotation of -12, whatever that may be".
But suppose now that for a given application a programmer wants to
consider that the true meaning of -12 is, say, the object represented
by the expression OVERDRAWN. It's straightforward to define a
function MEANING which will perform such an EVALuation. (Function
application is represented here by juxtaposition: Sin 3.14159, not
sin(3.14159)):
Meaning -12 = Overdrawn
Suppose now that OVERDRAWN in turn is defined (though its *meaning*
is not):
Overdrawn = More-debits-than-credits
where the right hand side is simply an undefined term. If this is
the case then the original request is reduced as follows:
Meaning (((3 - 7) + (4 / 2)) * 6)
==> Meaning -12 ==> Overdrawn ==> More-debits-than-credits
Of course, this result has nothing to do, a priori, with the
*meaning* of the expression OVERDRAWN. The latter (which is the same
as the *meaning of the meaning* of the expression -12) might be
defined:
Meaning More-debits-than-credits = Spendthrift
Assuming, again, that the right hand side is undefined, we have:
Meaning Overdrawn
==> Meaning More-debits-than-credits ==> Spendthrift
Such a simple denotational mechanism makes no assumption about the
meanings of constructions (undefined terms) such as, e.g., that they
denote themselves. In this it is a more flexible device than that
provided by LISP's EVAL. If 5 is a construction, then, although 5
*reduces* to itself (i.e. is irreducible), the MEANING of 5 is not 5
(or anything else) by default, nor are we prohibited from defining it
to be 6. This is a good reminder that denotational evaluation need
not be equivalence-preserving. For, while in our own eyes and the
eyes of a function such as MEANING we may identify, say, 2 and 3 by
defining their MEANINGs to both be, say, 7, or RHUBARB, or whatever,
this equivalence is fictive as far as the interpreter is concerned.
Then:
((Meaning 2) = (Meaning 3)) ==> True,
whereas
(2 = 3) ==> False.
More importantly, it is not even operationally possible for us to
assign two expressions which have the same normal form, such as
(2 + 2) and 4, different meanings.
The quotation mechanism itself may of course be provided quite simply
by the general rule:
Meaning (Quote x) = x
where QUOTE is simply a constructor (undefined symbol). Then:
Meaning (Quote -12) ==> -12
Note incidentally that we are of course in no way limited to a single
MEANING function, but may easily define as many different denotations
as we like. Likewise it might sometimes be useful to have various
quoting constructors. Such constructors are in effect used to
establish different denotational levels (meta, meta-meta, etc.), and
having different such quoting devices would allow different meaning
functions to move differently among the various levels, even with
respect to the same argument expression.
Similarly, a given meaning function might recognize more than one form
of quotation. E.g.,
My-meaning (My-quote x) = x
Your-meaning (Your-quote x) = x
Your-meaning (My-quote x) = Nonsense!
Then, for example:
My-meaning (My-quote Foo) ==> Foo
Your-meaning (My-quote Foo) ==> Nonsense!
My-meaning (Your-quote Foo) ==> My-meaning (Your-quote Foo)
[already in normal form]
To recapitulate, the argument I have with (pure) LISP's EVAL (leaving
aside side effects and eagerness) is not that it is denotational, but
that it's recognition of quotation is omnipresent. It is as though
LISP were a reduction interpreter that automatically provided a
function such as MEANING, respecting quotation, with every prompt.
That is, one might say that every expression FOO evaluated by LISP is
first regarded as (MEANING FOO), and is then reduced. It is
difficult in general to ask LISP for a simpler version of the same
expression; EVAL looks for meaning behind each input. In a reduction
setting on the other hand, denotational evaluation is still
available, using only the mechanism of reduction, just by defining
explicit denotation functions such as MEANING.
References:
==========
Laziness:
--------
%T A Lazy Evaluator
%A Peter HENDERSON
%A James H. MORRIS, Jr.
%B Third Annual ACM Symposium on Principles of Programming Languages (POPL)
%P 95-103
%I ACM
%D January 1976
%T CONS Should Not Evaluate its Arguments
%A Daniel P. FRIEDMAN
%A David S. WISE
%J Automata, Languages and Programming: Third Int'l Coll.
%P 257-284
%E S. MICHAELSON and R. MILNER
%I Edinburgh University Press
%D July 1976
%T Structure and Interpretation of Computer Programs
%A Harold ABELSON
%A Gerald Jay SUSSMAN
%A Julie SUSSMAN
%I The MIT Press and McGraw-Hill
%C Cambridge, Massachusetts, and New York
%D 1985
"Full" laziness:
---------------
%T Semantics and Pragmatics of the Lambda-calculus
%A Christopher Peter WADSWORTH
%I Oxford University
%D September 1971
%O Ph.D. Thesis
%T Design and Implementation of Programming Languages
%A Robert John Muir HUGHES
%R Technical Monograph PRG-40
%I Oxford University Computing Laboratory, Programming Research Group
%C Oxford
%D July 1983, as monograph September 1984
%O Ph.D. Thesis
Reduction:
---------
%T The Calculi of Lambda-Conversion
%A Alonzo CHURCH
%J Annals Math. Studies
%V 6
%I Princeton University Press
%C Princeton, New Jersey
%D 1941
%T Combinatory Logic
%A Haskell B. CURRY
%A Robert FEYS
%A William CRAIG
%V 1
%I North-Holland
%C Amsterdam
%D 1968
%T Highlights of the History of the Lambda Calculus
%A J. Barkley ROSSER
%J Annals of the History of Computing
%V 6
%N 4
%P 337-349
%I American Federation of Information Processing Societies
%D October 1984
Quotation:
---------
%T A Critique of Abelson and Sussman - or - Why Calculating is
Better Than Scheming
%A Philip WADLER
%J SIGPLAN Notices
%V 22
%N 3
%P 83-94
%I ACM
%D March 1987
--
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, adams@crcge1.cge.fr
∂21-Jul-87 1956 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Jul 87 19:56:34 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Jul 87 22:47:43 EDT
Date: Tue, 21 Jul 87 22:48:18 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
To: mcvax!inria!crcge1!adams@SEISMO.CSS.GOV
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 21 Jul 87 09:45:43 GMT from mcvax!inria!crcge1!adams at seismo.css.gov (Drew Adams)
Message-ID: <230562.870721.JAR@AI.AI.MIT.EDU>
I don't quite see what the big deal is. I agree that reduction is a
somewhat nicer but it doesn't seem to be a very deep question. Consider
a language which is identical to Lisp (or Scheme) with the following
exceptions:
- There is no EVAL.
Instead, there is a procedure NORMALIZE which could be defined as
(define (normalize x environment)
(object->expression (eval x environment)))
(define (object->expression x)
(cond ((or (number? x) (char? x) (string? x) (boolean? x))
x)
(else `',x)))
- The "datum" in (QUOTE datum) must not be "self-evaluating".
(I.e. reserve ' for use by things which don't need it. You don't
write numbers in Pascal using "...", do you? Why do the analogous
thing in Lisp?)
- PRINT writes out an expression that evaluates to the object, if
possible. E.g. (PRINT 'FOO) would write the characters 'FOO.
There's no semantic difference between this language and Lisp, only
trivial differences in the runtime library. But it would appear to have
so-called "reduction semantics", wouldn't it? So what's the big deal?
The nature of the runtime library (EVAL, PRINT, etc.) is orthogonal to
the question of laziness; a lazy Lisp would work just fine.
What is the relevance to Scheme (which has no EVAL), by the way?
[Please note: Drew Adams' message, to which this is a reply, contains
the line "Sender: scheme-request at mc.lcs.mit.edu" in its header. The
header lies; the message was NOT sent by scheme-request. I think this
is some kind of Unixoid kludge inserted automatically by a mail
system somewhere between inria and MC.]
∂22-Jul-87 0919 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA modules
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 09:19:09 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 87 12:12:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA05335; Wed, 22 Jul 87 12:11:20 EDT
Posted-Date: Wed, 22 Jul 87 12:10:25 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA06942; Wed, 22 Jul 87 12:10:25 EDT
Date: Wed, 22 Jul 87 12:10:25 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8707221610.AA06942@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: modules
Thanks to Will for his fine summary of the Scheme meeting. My highest
priority item for changes to Scheme is the inclusion of macros. I was
quite happy when Will reported:
------------
MACROS
The situation is pretty much ok. It looks like most of the work is
going to have to be done by people at MIT, because that's where the
largest concentration of macrologists seems to lie.
-------------------
I have directed my attention to my second highest priority: modules.
I decided to start by surveying modules in existing languages. I
ignored COBOL, FORTRAN, Pascal, C, PL/1 (Hmm... aren't they the most
used languages?), and Prolog, as those languages have little to say on
the subject of modules. I looked closely at ML, Modula-2, Ada, CLU
and Common Lisp. While the solutions these languages and their
environments present to the problem of organizing and structuring
large programs suggest many possibilities for Scheme, I in no way
would like to preclude a novel approach.
I've noticed three broad goals of module systems:
1. Logical separation of information -- in which information
describing an interface is shared, but information describing an
implementation is hidden (All). Multiple implementations of the same
interface is often also sometimes goal.
2. Physical separation of information -- in which compilation of
modules can proceed the compilation of the entire program with out
greatly affecting the quality of code produced (ML, Modula-2, Ada).
Compilations are performed with knowledge of all relevant interfaces,
so that inter-module type checking can be performed, and the compiler
can use the type information. Usually, the subject of precompiled
libraries and recompilation control, like Unix make, are also
addressed.
3. Object-oriented programming support -- in which instances of
modules are *interpreted types*, wherein the data object and its
operations are considered as a generalized form of type (ML, CLU).
I know that some Scheme people are interested in supporting block
compilation, so physical separation of information should be a goal.
I'm sure all would like a module system to support logical separation
of information, but I think using modules to support object-oriented
programming is debatable. Of course, my characterization of the goals
of modules in other systems is debatable, a debate I welcome.
Common Lisp's view of logical separation consists of limiting the
access of some symbols, and I suspect it can quickly be dismissed.
One difference between modules in CLU and in Modula-2, ML, and Ada, is
the latter languages have separate constructs that declare an
interface and an implementation. This separation is strongly
supported by users, and I hope a Scheme module system allow the same
separation. Furthermore, ML and Ada allow parameterized
implementations which are instantiated. This also seems to be a win.
It seems that ML's module system is a better than Ada's as a base from
which a Scheme module system may evolve. For one reason, ML shares
the goal of supporting interactive program development unlike Ada.
However, the following changes to Ada suggested by some Ada people
here at MITRE may be useful.
1. Implementations (package bodies in Ada) should be first-class so
that object-oriented programming is better supported.
2. Explicit control of what is imported should be added. This can be
used to insure code remains valid even when interfaces change.
3. Multiple levels of hiding should be added. In Ada (and the other
languages as well), you either have access to all an interface
exports, or you have access to nothing. They want the use of an
interface to determine what is exported.
Then again, maybe these suggestions won't be useful. I encourage all
to look at David MacQueen's article in the 1984 LISP and Functional
Programming Conference called "Modules for Standard ML".
John
∂22-Jul-87 1259 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 12:58:48 PDT
Received: from b.cs.uiuc.edu (TCP 30001242402) by MC.LCS.MIT.EDU 22 Jul 87 15:36:39 EDT
Received: by b.cs.uiuc.edu (UIUC-5.52/9.7)
id AA05068; Wed, 22 Jul 87 13:51:44 CDT
Date: Wed, 22 Jul 87 13:51:44 CDT
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8707221851.AA05068@b.cs.uiuc.edu>
To: mcvax!inria!crcge1!adams@seismo.css.gov
Cc: scheme@mc.lcs.mit.edu, fp@yale.arpa
In-Reply-To: (Drew Adams's message of 21 Jul 87 09:45:43 GMT <2698@crcge1.UUCP>
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
I too am quite perplexed by Drew's essay.
I would only add one change to the argument: full laziness lends
itself most naturally not to applicative (functional) languages in
general but, more precisely, to those respecting "*reduction*
semantics". In particular, the purely functional language "pure
LISP" (without side effects but with built-in quotation) does *not*
respect such semantics and is thus not easily made (fully) lazy. The
issue is quotation. Without its built-in recognition of quotation
LISP otherwise has reduction as its operational semantics.
To be "applicative" or "purely" functional a language must be
"referentially transparent", meaning that the same expression, in the
same definitional context, is always evaluated to the same result.
Pure LISP has this property.
I don't see how. A counterexample, assuming FOO is bound to 2 in the
context:
(QUOTE FOO) -> (QUOTE 2) by innermost reduction
But (QUOTE FOO) and (QUOTE 2) are different objects. Indeed, the term
"referential transparency" was coined by logicians precisely to
distinguish between things like (QUOTE FOO) and FOO. (QUOTE FOO)
"mentions" FOO, whereas FOO (or (+ FOO 1)) "uses" it. Referential
opacity is not necessarily bad. It is bad only if it is ambiguous
whether a particular occurrence of a symbol denotes a "mention" of it,
or a "use" of it. The point of QUOTE is precisely to eliminate any
such ambiguity, by distinguishing mentions from uses. The reduction I
showed above is thus invalid, because (QUOTE FOO) clearly means a
mention of FOO, so I can't replace FOO by something equivalent to it.
The LISP expression (QUOTE FOO) might be said in a sense to denote
the expression (value) FOO to which it evaluates, but the two aren't
equivalent;
Precisely. They aren't equivalent. So, why say that (QUOTE FOO)
denotes FOO? The confusion is probably caused by the fact that a Lisp
interpreter prints FOO rather than (QUOTE FOO) when we type in
(QUOTE FOO). I do wish Lisp interpreters didn't do that. They should
print (QUOTE FOO) to be precise. But, they print FOO for the sake of
convenience, I presume. Since FOO can never be the normal form value
of any expression (if FOO is bound, then its binding is the normal
form and, if it is unbound, then it is an error) they print FOO and
expect the user to understand it as (QUOTE FOO).
Having such a denotation mechanism available in a language
facilitates a leveled view of things. However, it would seem that
most programmer use of quotation in LISP doesn't really involve
intentional semantic leveling. The most frequent uses of quotation
in LISP would appear to be:
* to prevent the attempted evaluation of something which is
undefined, together with the ensuing error treatment
* to prevent the immediate evaluation of a defined expression
because the moment isn't right.
The most common use of quotation is merely to denote data objects.
Since Lisp does not have a separate syntax for data objects and
programs (which many Lispers consider to be an asset), data objects
are treated as "mentions" of S-expressions and programs are treated as
"uses" of them. This is one way of doing it. There are other ways,
of course. Prolog uses different syntax for atoms and variables.
Pascal and ML use declarations for atoms and constructors. Using a
normalizer instead of an evaluator (which Drew mentions later) is
another way. But, there are strong arguments against normalizers.
Firstly, they are inefficient compared to evaluators. Secondly, when
there is an error it is better to tell the user about it immediately
rather than printing a large expression and expecting the user to
search for the erroneous application in it.
The use of quotation for delayed evaluation is now widely recognized
to be misguided. Modern Lisps, such as Scheme, have constructs like
"delay" to achieve lazy evaluation.
Likewise, it would seem that in our daily reasoning we are rarely
conscious of using more than few semantic levels at once.
Nevertheless, there *are* times when a device for manipulating
programmer-defined levels of denotation is useful. Implementation/
manipulation of languages is a typical example where quotation is
appropriate. As such leveling is a very powerful abstraction
construct, it would be desirable not to have to do without denotation
in opting for reduction semantics. One would like to be able to
define meta-meta-levels, and so on. Fortunately it's easy to have
our cake and eat it too in a reduction-only setting by simply
programming quotation/denotation *explicitly* for use just where we
need it.
But suppose now that for a given application a programmer wants to
consider that the true meaning of -12 is, say, the object represented
by the expression OVERDRAWN. It's straightforward to define a
function MEANING which will perform such an EVALuation.
Such a MEANING function can be defined in any Lisp as well. (It is no
different from any other function). If such a MEANING function
differes from the standard meaning in minor ways, then Lisp allows you
to share it by calling EVAL from your MEANING function. If you indeed
want to use the standard meaning it should not be necessary to write a
brand new interpreter.
The quotation mechanism itself may of course be provided quite simply
by the general rule:
Meaning (Quote x) = x
where QUOTE is simply a constructor (undefined symbol). Then:
Meaning (Quote -12) ==> -12
This works only if outermost evaluation is the default (standard)
evaluation of the language. All Lisps use innermost evaluation
(though other modes of evaluation are provided by constructs like
"delay", "freeze" and "future"), so this trick does not work. It is
by no means universally accepted that outermost evaluation as the
default is "good", and many people who work with outermost evaluation
have reservations about using it as the default.
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, adams@crcge1.cge.fr
In summary, I can see no difference between "applicative semantics"
and "reduction semantics". The question of referential transparency
is orthogonal to applicative semantics. I believe Drew's comments are
largely motivated by the minor misuse of notation by Lisp interpreters
in not printing the outermost QUOTE.
Uday Reddy
reddy@a.cs.uiuc.edu
∂23-Jul-87 0018 @MC.LCS.MIT.EDU,@RELAY.CS.NET:stevev@tekchips.tek.com
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 00:18:18 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 Jul 87 03:01:09 EDT
Received: from relay2.cs.net by RELAY.CS.NET id af05018; 23 Jul 87 2:51 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ao19444; 23 Jul 87 2:44 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
id AA07882; Wed, 22 Jul 87 14:17:32 PDT
Received: by tekchips.TEK.COM (5.51/6.23)
id AA12230; Wed, 22 Jul 87 14:16:14 PDT
Message-Id: <8707222116.AA12230@tekchips.TEK.COM>
To: rrrs-authors%tekchips.tek.com@RELAY.CS.NET
Subject:
Date: 22 Jul 87 14:16:12 PDT (Wed)
From: Steve Vegdahl <stevev%tekchips.tek.com@RELAY.CS.NET>
I have a question about Scheme about which I am unclear after reading
R3RS. Consider the following procedure definitions
(define foo
(lambda () '(x y z)))
(define baz
(lambda () `(x y z)))
(define grump
(lambda (k) `(x y z ,k)))
Are the following expressions true, false, or implementation-dependent?
1: (eq? (foo) (foo))
2: (eq? (baz) (baz))
3: (eq? (grump 'w) (grump 'w))
It is hard to imagine that implementation would require 1 to be false or
3 to be true. But I could imagine, for example implementations being
allowed to transform:
'(x y z)
into
(list 'x 'y 'z)
thereby creating a distinct list each time the expression is evaluated.
Steve Vegdahl
Computer Research Lab
Tektronix Labs
Beaverton, Oregon
∂23-Jul-87 0905 @MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 09:05:10 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUL 87 11:50:26 EDT
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 52718; 23 Jul 87 11:43:28-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 76014; Thu 23-Jul-87 10:44:26-EDT
Date: Thu, 23 Jul 87 10:49 est
From: mike%acorn@oak.lcs.mit.edu
To: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
Reply-to: mike%acorn@oak.lcs.mit.edu
Cc: scheme@mc.lcs.mit.edu,
Date: Wed, 22 Jul 87 13:51:44 CDT
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
I too am quite perplexed by Drew's essay............
Amen.
.................... Since FOO can never be the normal form value
of any expression (if FOO is bound, then its binding is the normal
form and, if it is unbound, then it is an error) they print FOO and
expect the user to understand it as (QUOTE FOO).
I mostly agree with Uday's point. I'd like only to comment on the use of
the term "normal form" in programming language analysis.
In Scheme or Lisp, you need a more powerful notion of Normal Form
than in a language without meta-language operations. Vanilla
expression rewriting cannot handle languages where the space of
values which cannot be rewritten by any rules (call them denotations,
values, etc) overlaps with those that can be. (call them expressions,
programs, etc.) Context is needed to distinguish when rewriting
should continue and when it should halt. Lisp-like languages with
quote have this property, in that an expression can evaluate or be
reduced to a value which is indistinguishable from an expression,
except that in context, it is not intended for re-evaluation, but as
an "answer".
(QUOTE FOO) denotes the value FOO, a symbol, not the expression FOO a
variable. No further evaluation is done on this value, no matter what
the context is. Hence, (QUOTE FOO) never has anything to do with any
value that the expression FOO (a variable) may have. In Scheme or
Lisp interpreters, this distinction between a symbol or S-expression
as a value, and as an expression is maintained by using applicative
(inner most) evaluation order. This avoids the problem of reexamining
expressions and thereby confusing a symbolic value with an expression
in the language.
Of course all this goes out the window if you allow a program to
call the interpreter,... i.e., EVAL.
...mike beckerle
∂23-Jul-87 1017 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 10:17:06 PDT
Received: from b.cs.uiuc.edu (TCP 30001242402) by MC.LCS.MIT.EDU 23 Jul 87 12:40:50 EDT
Received: by b.cs.uiuc.edu (UIUC-5.52/9.7)
id AA19593; Thu, 23 Jul 87 11:38:42 CDT
Date: Thu, 23 Jul 87 11:38:42 CDT
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8707231638.AA19593@b.cs.uiuc.edu>
To: mike%acorn@oak.lcs.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: mike%acorn@oak.lcs.mit.edu's message of Thu, 23 Jul 87 10:49 est <8707231551.AA18446@b.cs.uiuc.edu>
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
In Scheme or Lisp, you need a more powerful notion of Normal Form
than in a language without meta-language operations. .....
........ . This avoids the problem of reexamining
expressions and thereby confusing a symbolic value with an expression
in the language.
Of course all this goes out the window if you allow a program to
call the interpreter,... i.e., EVAL.
...mike beckerle
Precisely. Expressions ARE "symbolic values" (though not all symbolic
values are well-formed expressions). I don't see this as a "confusion".
It is quite legitimate use of a language.
I can't think of any consistent interpretation of "normal form" by
which you can say that (QUOTE FOO) normalizes to FOO. FOO is a
symbolic value, and (QUOTE FOO) is the way you express it in the
language. When Lisp prints answers, it prints the symbolic values
rather than the way they should be expressed in the language. Hence,
the outermost QUOTE gets eaten.
Uday Reddy
reddy@a.cs.uiuc.edu
∂23-Jul-87 1207 @MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu futures in cscheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 12:07:34 PDT
Received: from a.cs.uiuc.edu (TCP 1200600045) by MC.LCS.MIT.EDU 23 Jul 87 15:02:02 EDT
Received: from kaplan.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA03824; Thu, 23 Jul 87 14:02:15 CDT
Received: by kaplan.cs.uiuc.edu (7.1/9.7)
id AA11840; Thu, 23 Jul 87 14:01:08 mdt
Date: Thu, 23 Jul 87 14:01:08 mdt
From: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu
Message-Id: <8707232001.AA11840@kaplan.cs.uiuc.edu>
To: scheme@mc.lcs.mit.edu
Subject: futures in cscheme
I have decided to play with the experimental futures system that comes
along with mit scheme. Unfortunately there is no documentation and the
various primitives do not seem to behave the way the are described in
Halstead's Multilisp paper (they are also named differently which I
guess means they are meant to be different!!). There seem to be
two primitives that do stuff to make processes, MAKE-INITIAL-PROCESS and
MAKE-CHEAP-FUTURE. I can pass make-initial-process a thunk and make that
run, which works as the comments in future.c seem to imply (I have only
tried this with simple thunks like (lambda () (display 'fish)))
Make-cheap-future requires 3 arguments, "orig" "user-code" and "name".
I guess that the second is a thunk for the code of the future but cannot
figure out the other 2. I have tried silly values like 0 and 'a and that
seems to allow make-cheap-future to return a thing which returns TRUE
in response to the (future?) operator. But now i dont know how to use
this future at all.
Help!! can anyone help me??? Has anyone got some documentation on
futures or some sample code I could look at?
Thanks,
Simon Kaplan
(kaplan@a.cs.uiuc.edu)
ps: If it makes a difference I am running an hp9000/s320.
∂23-Jul-87 1420 @MC.LCS.MIT.EDU:pierson@multimax.ARPA futures in cscheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 14:20:06 PDT
Received: from multimax.ARPA (TCP 30001237416) by MC.LCS.MIT.EDU 23 Jul 87 16:46:09 EDT
Received: by multimax.ARPA (4.12/25-eef)
id AA06525; Thu, 23 Jul 87 16:38:04 edt
Date: Thu, 23 Jul 87 16:38:04 edt
From: Dan Pierson <pierson@multimax.ARPA>
Message-Id: <8707232038.AA06525@multimax.ARPA>
To: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu's message of Thu, 23 Jul 87 14:01:08 mdt <8707232001.AA11840@kaplan.cs.uiuc.edu>
Subject: futures in cscheme
You need the runtime file "future.scm". A version from an earlier
CScheme follows -- I've partially munged it to work with the 5.1 beta
release but there appear to be some remaining problems. Please send
me back a copy if you get it to work better; I don't have time to work
on it right now. I suspect that make-future needs to be changed to
use make-cheap-future but I'm not sure...
======================================================================
; This is -*- SCHEME -*- code
(declare (usual-integrations)
(compilable-primitive-functions
vector-set!
get-external-number
within-control-point))
(define put-work (make-primitive-procedure 'PUT-WORK))
(define global-interrupt (make-primitive-procedure 'GLOBAL-INTERRUPT))
(define touch (make-primitive-procedure 'TOUCH))
(define set-car-if-eq?! (make-primitive-procedure 'SET-CAR-IF-EQ?!))
(define set-cdr-if-eq?! (make-primitive-procedure 'SET-CDR-IF-EQ?!))
(define vector-set-if-eq?! (make-primitive-procedure 'VECTOR-SET-IF-EQ?!))
(define set-cxr-if-eq?! (make-primitive-procedure 'SET-CXR-IF-EQ?!))
(define future-ref (make-primitive-procedure 'FUTURE-REF))
(define future-set! (make-primitive-procedure 'FUTURE-SET!))
(define future-size (make-primitive-procedure 'FUTURE-SIZE))
(define lock-future! (make-primitive-procedure 'LOCK-FUTURE!))
(define unlock-future! (make-primitive-procedure 'UNLOCK-FUTURE!))
(define non-touching-eq? (make-primitive-procedure 'NON-TOUCHING-EQ?))
(define n-interpreters (make-primitive-procedure 'N-INTERPRETERS))
(define my-processor-number (make-primitive-procedure 'MY-PROCESSOR-NUMBER))
(define my-interpreter-number (make-primitive-procedure 'MY-INTERPRETER-NUMBER))
!
;; This is the stuff Anthony put here.
;; (define statistics-package
;; (make-environment
;; (define get-statistics
;; (make-primitive-procedure 'get-statistics #!true))
;; (define stat-names '((CONTENTION-COUNT . 0)
;; (GC-MASTER-IDLE-TIME . 1)
;; (GC-SLAVE-IDLE-TIME . 2)
;; (GC-LOOP-TIME . 3)
;; (GC-DAEMON-TIME . 4)))
;; (define This-load '())
;;
;; (define (load-statistics)
;; (set! this-load (get-statistics)))
;;
;; (define (get-statistic name)
;; (if (unassigned? this-load)
;; (load-statistics))
;; (vector-ref this-load (cdr (assq name stat-names))))
;;
;; (define (clear-statistics)
;; (set! this-load))))
;;
;; (define load-statistics (access load-statistics statistics-package))
;; (define get-statistic (access get-statistic statistics-package))
;; (define clear-statistics (access clear-statistics statistics-package))
!
;; Slots in a future
;; MICROCODE KNOWS ABOUT THESE
;; FUTURE-DETERMINED-SLOT is #!TRUE if the value is known and immutable
;; #!FALSE if not yet know, else known but mutable (i.e. KEEP-SLOT)
(define FUTURE-DETERMINED-SLOT 0)
;; FUTURE-LOCK-SLOT is #!TRUE if the future is locked by a process
(define FUTURE-LOCK-SLOT 1)
;; The next two are mutually exclusive. The VALUE is used if
;; DETERMINED is not #!FALSE. The QUEUE contains a WEAK queue of
;; processes waiting for a value to appear if DETERMINED is #!FALSE.
(define FUTURE-VALUE-SLOT 2)
(define FUTURE-QUEUE-SLOT 2)
; REFERENCED ONLY BY THE RUNTIME SYSTEM
;; Code to run to re-activate this process
(define FUTURE-PROCESS-SLOT 3)
;; The FUTURE-STATUS-SLOT contains one of:
;; RUNNING: Actually in possession of a processor
;; WAITING: Stopped waiting for the value of a future
;; PAUSED: Stopped by PAUSE-EVERYTHING
;; DELAYED: Created by delay scheduler and not yet run
;; RUNNABLE: Available for execution
;; DETERMINED: Value has been set and process is finished
;; CREATED: Future newly created
(define FUTURE-STATUS-SLOT 4)
;; For debugging purposes, the original thunk to be executed.
(define FUTURE-ORIG-CODE-SLOT 5)
(define FUTURE-PROCESS-PRIVATE-SLOT 6)
;; If this process has status WAITING this is a (strong) list of the
;; futures on which it is waiting.
(define FUTURE-WAITING-ON-SLOT 7)
;; For GC metering (not used by simulator)
(define FUTURE-METER-SLOT 8)
;; For users:
(define FUTURE-USER-SLOT 9)
!
; Some useful macros for dealing with atomicity. Notice that
;;DEFINE-MACRO happens when the text is turned into code (i.e.
;;at syntax time), while ADD-SYNTAX! happens only when the program
;;is actually executed. So both are used when this file uses the
;;macro, but only ADD-SYNTAX! is used for user macros which
;;are not referenced here.
(define-macro (add-syntax! name expander)
`(SYNTAX-TABLE-DEFINE SYSTEM-GLOBAL-SYNTAX-TABLE ,name ,expander))
; ATOMIC takes a list of expression and guarantees that they
;;are done without interrupts.
(define-macro (atomic . expressions)
`(WITHOUT-INTERRUPTS
(LAMBDA () . ,expressions)))
(add-syntax! 'ATOMIC
(macro expressions
`(WITHOUT-INTERRUPTS
(LAMBDA () . ,expressions))))
;; PROG1 is like the MACLISP macro of the same name
(define-macro (PROG1 . exprs)
`(LET ((FIRST ,(CAR exprs)))
,@(CDR exprs)
FIRST))
; DEFINE-ATOMIC is like the procedural version of DEFINE, except
;;that the body is wrapped in WITHOUT-INTERRUPTS.
(define-macro (define-atomic arg-template . body)
`(DEFINE ,arg-template (ATOMIC . ,body)))
(add-syntax! 'DEFINE-ATOMIC
(macro (arg-template . body)
`(DEFINE ,arg-template (ATOMIC . ,body))))
!
; LOCKING-FUTURE is the same as ATOMIC except that it also wraps
;;a LOCK-FUTURE! and UNLOCK-FUTURE! around the expression(s).
;;LOCKED? is a flag which can be used in BODY -- it will be #!true
;;if the future is still valid (you hang until you can lock it),
;;or #!false if it has been spliced out.
(define-macro (LOCKING-FUTURE FUTURE LOCKED? . BODY)
`(WITH-FUTURE-LOCKED ,future
(LAMBDA (,locked?) . ,body)))
(add-syntax! 'LOCKING-FUTURE
(macro (FUTURE LOCKED? . BODY)
`(WITH-FUTURE-LOCKED ,future
(LAMBDA (,locked?) . ,body))))
(define-macro (WITH-STATE STATE . BODY)
`(NON-REENTRANT-TASK-CATCH (LAMBDA (,state) . ,body)))
(DEFINE-ATOMIC (with-future-locked future thunk)
(if (lock-future! future)
(let ((result (thunk #!true)))
(unlock-future! future)
result)
(thunk #!false)))
!
(define scheduler
(make-environment
(declare (usual-integrations)
(compilable-primitive-functions
(weak-car system-pair-car)
(weak-cdr system-pair-cdr)
(weak-set-car! system-pair-set-car!)
(weak-set-cdr! system-pair-set-cdr!)))
(define control-point-type
(microcode-type 'CONTROL-POINT))
(define sti
(make-primitive-procedure 'setup-timer-interrupt #!true))
(define drain-work-queue!
(make-primitive-procedure 'drain-work-queue!))
(define weak-cons-type
(microcode-type 'WEAK-CONS))
(define non-reentrant-task-catch)
(define task-catch)
(define non-reentrant-call/cc
(make-primitive-procedure 'non-reentrant-call-with-current-continuation))
(define call/cc
(make-primitive-procedure 'call-with-current-continuation))
(define set-current-dynamic-state!
(make-primitive-procedure 'set-current-dynamic-state!))
(define catch-maker
(access catch-maker continuation-package))
(define current-Future-Vector) ; Process currently running
(define the-paused-tasks) ; Tasks being suspended temporarily
(define Start-Process) ; Default scheduler for FUTURE creation
(define Idle-Future) ; Future to wait until idle on
(define discard-the-paused-tasks? #!false) ; Throw away tasks?
(define preempting? #!false) ; No timer currently set
(define Delta '()) ; Scheduling frequency, centi-seconds
!
(set! non-reentrant-task-catch
(catch-maker non-reentrant-call/cc set-current-dynamic-state! #!true))
(set! task-catch
(catch-maker call/cc set-current-dynamic-state! #!false))
(define (legitimate-process? object)
(or (procedure? object) (primitive-type? control-point-type object)))
(DEFINE-ATOMIC (start-preempting interval)
(if (not preempting?)
(begin
(set! timer-interrupt
(lambda ()
(let ((My-Task (Current-Future)))
(WITH-STATE me
(LOCKING-FUTURE My-Task I-am-running?
(if I-am-running?
(begin
(future-set! My-Task FUTURE-PROCESS-SLOT me)
(more-work My-Task))
(begin
(stop-preempting)
(bkpt "TIMER: Existential crisis!"))))
(next)))))
(set! preempting? #!true)
(set! delta interval)
(sti 0 interval))
(display "Already preempting when START-PREEMPTING called")))
(DEFINE-ATOMIC (stop-preempting)
(sti '() '())
(set! preempting? #!false))
!
(define make-future
(let ((future-type (microcode-type 'FUTURE)))
(named-lambda (make-future orig-code user-procedure name)
(primitive-set-type
future-type
(vector #!false ; DETERMINED: No value yet
#!false ; LOCK: Not locked
(make-empty-queue)
; VALUE/QUEUE:No waiters
orig-code ; PROCESS: How to resume
'CREATED ; STATUS: Ready to go
user-procedure ; ORIG_CODE: For debugging
(if (unbound? open-console-channel)
name
(vector
(open-console-channel name)))
; PROCESS-PRIVATE: Butterfly??
'() ; WAITING-ON: Not waiting
0 ; METER: Ignored by simulator
'()))))) ; USER-SLOT
(define (more-work work)
(future-set! work FUTURE-STATUS-SLOT 'RUNNABLE)
(put-work work)
(if (and delta (not preempting?))
(start-preempting delta)))
(define spawn-process
(let ((make-initial-process
(make-primitive-procedure 'make-initial-process)))
(named-lambda (spawn-process thunk doc #!optional start)
(let ((object)
(dynamic-state (current-dynamic-state)))
(set! object
(make-future
(make-initial-process
(lambda ()
(set-current-dynamic-state! dynamic-state)
(thunk)))
thunk doc))
((if (unassigned? start) start-process start) object)
object))))
(DEFINE-ATOMIC (end-of-computation-handler expression environment value)
(let ((me (current-future)))
(determine! me value #!false))
(next))
!
(define (determine! future value #!optional keep-slot?)
;; AWAKEN! is called with a queue (of processes waiting
;; for a future) and promotes them all to runnable status.
(define (awaken! queue)
(let loop ()
(if (empty-queue? queue)
'DONE
(let ((next-item (dequeue! queue)))
(LOCKING-FUTURE next-item item-runnable?
(if (and
item-runnable?
(eq? (future-ref next-item FUTURE-STATUS-SLOT) 'WAITING)
(non-touching-memq future (future-ref next-item FUTURE-WAITING-ON-SLOT)))
(begin
(future-set! next-item FUTURE-WAITING-ON-SLOT future)
(more-work next-item))))
(loop)))))
(LOCKING-FUTURE future was-still-a-future?
(if was-still-a-future?
(let ((known? (future-ref future FUTURE-DETERMINED-SLOT))
(waiters (future-ref future FUTURE-QUEUE-SLOT)))
(if (eq? known? #!true)
(error "Future cannot be determined twice." future))
(future-set! future FUTURE-VALUE-SLOT value)
(future-set! future FUTURE-STATUS-SLOT 'DETERMINED)
(if (unassigned? keep-slot?)
(if (eq? known? #!false)
(future-set! future FUTURE-DETERMINED-SLOT #!true))
(future-set! future FUTURE-DETERMINED-SLOT
(if keep-slot? 'KEEP-SLOT #!true)))
(if (not known?) (awaken! waiters)))
(error "Future cannot be determined twice." future)))
value)
!
(define (Futures-On?) (not (unassigned? Current-Future-Vector)))
(define (Futures-Off)
(pause-everything)
(set! Current-Future-Vector)
'FUTURES-TURNED-OFF)
(define (Current-Future)
(if (Futures-On?)
(vector-ref Current-Future-Vector (My-Interpreter-Number))
'()))
(define (Set-Current-Future! Future)
(vector-set! Current-Future-Vector (My-Interpreter-Number)
Future))
(define (initialize-scheduler!
#!optional interval default-scheduler non-aborting?)
(let ((set-fixed-objects-vector!
(make-primitive-procedure 'set-fixed-objects-vector!)))
(pause-everything) ; Stop all processors & drain queue
(let ((termination-handlers
(vector-ref (get-fixed-objects-vector)
(fixed-objects-vector-slot
'MICROCODE-TERMINATIONS-PROCEDURES))))
(if (= (vector-length termination-handlers) 0)
(begin
(set! termination-handlers
(vector-cons number-of-microcode-terminations '()))
(vector-set! (get-fixed-objects-vector)
(fixed-objects-vector-slot
'MICROCODE-TERMINATIONS-PROCEDURES)
termination-handlers)
(set-fixed-objects-vector! (get-fixed-objects-vector))))
(vector-set! termination-handlers
(microcode-termination 'END-OF-CONTINUATION)
end-of-computation-handler))
(set! Start-Process
(if (unassigned? default-scheduler)
dfuture-scheduler
default-scheduler))
(set! Current-Future-Vector
(vector-cons (N-Interpreters) 'NO-FUTURE-YET))
(set! Idle-Future (make-future 'NO-PROCESS 'NO-PROCESS "Idle-Loop"))
;; INITIALIZE-SCHEDULER (futures-on) continues on the next page
!
;; INITIALIZE-SCHEDULER (futures-on), continued
(if (not (unassigned? interval)) (set! delta interval))
(let ((fobj (get-fixed-objects-vector)))
(vector-set! fobj (fixed-objects-vector-slot 'SCHEDULER)
await-future)
(set-fixed-objects-vector! fobj))
(Set-Current-Future!
(make-future 'INITIAL-PROCESS 'INITIAL-PROCESS "The Initial Process"))
(future-set! (current-future) FUTURE-STATUS-SLOT 'RUNNING)
(global-interrupt
1
(lambda (IntCode IntEnb)
(set-interrupt-enables! IntEnb)
(next))
(lambda () #!true))
(if (or (unbound? abort-to-top-level-driver)
(and (not (unassigned? non-aborting?))
non-aborting?))
(or Delta 'NOT-PREEMPTIVE-SCHEDULING)
(abort-to-top-level-driver
(cond ((unbound? format) "↑G to restart the futures")
((not Delta) "↑G: no preemptive scheduling")
((negative? Delta)
(format () "↑G: scheduling ~o.~o~o (real) secs."
(quotient (abs Delta) 100)
(remainder (quotient (abs Delta) 10) 10)
(remainder (remainder (abs Delta) 10) 10)))
(else
(format () "↑G: scheduling ~o.~o~o (runtime) secs."
(quotient Delta 100)
(remainder (quotient Delta 10) 10)
(remainder (remainder Delta 10) 10))))))))
!
; Scheduling support
(define (next)
(let ((get-work (make-primitive-procedure 'get-work)))
(Set-Current-Future! 'WAITING-FOR-WORK)
(run (get-work
(named-lambda (loop)
(stop-preempting)
(determine! Idle-Future 'DONE)
(set! Idle-Future
(make-future 'NO-PROCESS 'NO-PROCESS "Idle Loop"))
(run (get-work
(lambda ()
(error "No Work Available")
(loop)))))))))
;; RUN starts a process running
(define (run future)
((LOCKING-FUTURE future Still-A-Future?
(if Still-A-Future?
(let ((new-process
(future-set! future
FUTURE-PROCESS-SLOT (My-Interpreter-Number)))
(old-status (future-set! future FUTURE-STATUS-SLOT 'RUNNING)))
(if (and (legitimate-process? new-process)
(eq? old-status 'RUNNABLE))
(begin
(Set-Current-Future! future)
(if (and delta preempting?)
(sti 0 delta)) ; Full time interval
(lambda () (new-process 'YOUR-TURN)))
(begin
(future-set! future FUTURE-STATUS-SLOT old-status)
(future-set! future FUTURE-PROCESS-SLOT new-process)
next)))
next))))
!
;; AWAIT-FUTURE suspends the current process and adds it to the
;; queue waiting for the specified future to get a value. The
;; thunk, if specified, is executed immediately before going off for
;; more work to do (i.e. after all of the enqueuing work, etc. is done).
(DEFINE-ATOMIC (await-future future #!optional thunk)
(WITH-STATE me
(let
((perform-normal-return?
(LOCKING-FUTURE future waiting-for-a-future?
(if (or (not waiting-for-a-future?) ; Already determined
(future-ref future FUTURE-DETERMINED-SLOT))
#!TRUE ; Return normally
(let ((My-Task (Current-Future))
(status (future-ref future FUTURE-STATUS-SLOT)))
(if (or (eq? status 'DELAYED) (eq? status 'PAUSED))
(more-work future))
(LOCKING-FUTURE My-Task I-am-running?
(if I-am-running?
(begin
(future-set! My-Task FUTURE-PROCESS-SLOT me)
(future-set! My-Task FUTURE-STATUS-SLOT 'WAITING)
(future-set! My-Task FUTURE-WAITING-ON-SLOT
(list future))
(enqueue! (future-ref future FUTURE-QUEUE-SLOT) My-Task))
(display "AWAIT-FUTURE: Existential crisis!")))
#!FALSE))))) ; Don't return normally
(if (not (unassigned? thunk)) (thunk)) ; Do the optional work
(if perform-normal-return? ; Done or find more work
(me 'DONE)
(next)))))
!
;; AWAIT-FUTURE-AFTER-ACTION suspends the current process after
;; executing a thunk and adds it to the queue waiting for the
;; specified future to get a value. Its purpose is to ensure
;; that the process is actually on the wait queue of the future
;; when the action takes place. This prevents a race condition
;; which might cause problems if the action is intended to determine
;; the future (e.g., externally) and wake up the process. In other words,
;; if the process has not been added to the wait queue when another
;; process or an external interrupt determines the future, the event
;; would not wake up the process as intended.
;;
;; Since this is rather specialized code (it was added to support
;; the new console i/o system), many safeguards of the normal
;; AWAIT-FUTURE are removed for speed. Normally the future will
;; have been explicitly constructed by the user and is not being
;; determined by any other process.
(define (await-future-after-action future action)
(await-future future action))
!
(define await-internal
(let ((fall-through-tag (cons 'FALL-THROUGH '())))
(named-lambda (await-internal My-Task futures)
(let ((Value-Known? #!false))
(define (announce-value value)
(if (not (set! Value-Known? #!true))
(determine! My-Task value)))
(define (spawn-processes disjuncts)
(if (null? disjuncts)
'DONE
(let ((this-future (car disjuncts)))
(if (LOCKING-FUTURE this-future really-a-future?
(if (and really-a-future?
(null?
(future-ref
this-future FUTURE-DETERMINED-SLOT)))
(begin
(enqueue!
(future-ref this-future FUTURE-QUEUE-SLOT)
My-Task)
#!true)
(begin
(announce-value this-future)
#!false)))
(spawn-processes (cdr disjuncts))))))
(if (eq? fall-through-tag
(task-catch (lambda (me) ; Deliberately re-entrant
(future-set! My-Task FUTURE-PROCESS-SLOT me)
(future-set! My-Task FUTURE-STATUS-SLOT 'WAITING)
(future-set! My-Task FUTURE-WAITING-ON-SLOT futures)
(spawn-processes futures)
fall-through-tag)))
My-Task
(begin
(announce-value (future-ref My-Task FUTURE-WAITING-ON-SLOT))
(next)))))))
(define (disjoin . futures)
(await-internal (make-future 'DISJOIN 'DISJOIN "Disjoin") futures))
(define (await-first-of futures)
(await-internal (make-future 'DISJOIN 'DISJOIN "Disjoin") futures))
!
; Special scheduler operations
;; RESCHEDULE allows me to give up my processor slice and
;; wait until the scheduler gets back to me.
(define-atomic (reschedule)
(let ((my-task (current-future)))
(WITH-STATE me
(if (LOCKING-FUTURE my-task am-I-running?
(if am-I-running?
(begin
(future-set! my-task FUTURE-PROCESS-SLOT me)
(more-work my-task)))
am-I-running?)
(next)
'NOT-CURRENTLY-RUNNING-A-FUTURE))))
;; WAIT-UNTIL-IDLE causes a process to just continue
;; going to sleep until there are no other active processes.
(define (wait-until-idle) (touch idle-future))
;; DFUTURE-SCHEDULER is a future creation scheduler which
;; defers the child process and continues on with the parent.
;; Note that all creation schedulers are called as part of
;; the parent process, so this is the easy case.
(DEFINE-ATOMIC (dfuture-scheduler future)
(more-work future)
'CHILD-QUEUED-FOR-EXECUTION)
;; FUTURE-SCHEDULER is a future creation scheduler which
;; defers the parent process and continues on with the child.
;; This is a little harder than DFUTURE, since it is called
;; running as the parent.
(DEFINE-ATOMIC (future-scheduler future)
(WITH-STATE parent-process
(let ((My-Future (Current-Future)))
(LOCKING-FUTURE My-Future Still-Runnable?
(if Still-Runnable?
(begin
(future-set! My-Future FUTURE-PROCESS-SLOT parent-process)
(more-work My-Future))))))
(more-work future)
(run future))
;; DELAY-SCHEDULER is a future creation scheduler which defers
;; execution of the newly created future until it is first
;; touched.
(DEFINE-ATOMIC (delay-scheduler future)
(future-set! future FUTURE-STATUS-SLOT 'DELAYED)
'OK-I-DELAYED-IT)
!
;; Queue Abstraction
;;
;; -------------------------------
;; | Tail Pointer | Head Pointer |
;; -------------------------------
;; | |
;; | |
;; V V
;; ----- ----- -----
;; | |=|=>| |=|=>| |/| add new items by clobbering '()
;; ----- ----- -----
;; remove from start of list
;; (The list itself is made from WEAK cons cells)
;;
;; The queue is empty when Tail=Head=#!NULL
;; (thus it has one item when Tail=Head but they are not #!NULL)
;;
;; These operations assume that the caller has arranged for any
;; desired atomicity.
(define (weak-cons a b)
(system-pair-cons weak-cons-type a b))
(define weak-car system-pair-car)
(define weak-cdr system-pair-cdr)
(define weak-set-car! system-pair-set-car!)
(define weak-set-cdr! system-pair-set-cdr!)
(define (make-empty-queue) (cons '() ()))
(define queue-head-ptr car)
(define queue-tail-ptr cdr)
(define set-queue-head-ptr! set-car!)
(define set-queue-tail-ptr! set-cdr!)
(define (empty-queue? queue) (null? (queue-head-ptr queue)))
!
(define (enqueue! queue object)
(if (null? (queue-head-ptr queue))
(begin
(set-queue-head-ptr! queue (weak-cons object '()))
(set-queue-tail-ptr! queue (queue-head-ptr queue)))
(begin
(weak-set-cdr! (queue-head-ptr queue) (weak-cons object '()))
(set-queue-head-ptr! queue (weak-cdr (queue-head-ptr queue))))))
(define (dequeue! queue)
(let ((current-tail (queue-tail-ptr queue)))
(if (null? current-tail)
(error "Queue empty" queue)
(let ((result (weak-car current-tail)))
(if (null? (weak-cdr current-tail))
(begin (set-queue-head-ptr! queue '())
(set-queue-tail-ptr! queue '()))
(set-queue-tail-ptr! queue (weak-cdr current-tail)))
result))))
!
;; SAVING-STATE wraps up the current state of the system into the
;; current future and returns it to the work queue. It then executes
;; the thunk. If the current future is invoked the call to
;; SAVING-STATE is exitted; when the thunk returns, the processor will
;; wait for new work to perform.
(define (saving-state thunk)
(WITH-STATE my-state
(let ((my-future (current-future)))
(LOCKING-FUTURE my-future am-I-running?
(if am-I-running?
(begin
(future-set! my-future FUTURE-PROCESS-SLOT my-state)
(future-set! my-future FUTURE-STATUS-SLOT 'RUNNABLE)
(put-work my-future)))))
(set-current-future! 'STATE-SAVED)
(set! my-state)
(within-control-point the-error-continuation
(lambda ()
(thunk)
(next))))
'COMPLETED)
!
;; PAUSE-EVERYTHING is used to make every processor but the caller
;; save its state and go quiescent. The value returned by
;; Pause-Everything is a procedure which will put the work queue
;; back to its initial state (modulo order of futures on the queue).
(DEFINE-ATOMIC (pause-everything)
;; RELEASE-STATE! takes a list of futures and puts them
;; on the work queue.
(define (release-state! list)
(if (null? list)
'RESTARTED
(let ((work-unit (car list)))
(LOCKING-FUTURE work-unit work-to-do?
(if (and work-to-do?
(legitimate-process?
(future-ref work-unit FUTURE-PROCESS-SLOT))
(eq? (future-ref work-unit FUTURE-STATUS-SLOT)
'PAUSED))
(more-work work-unit)))
(release-state! (cdr list)))))
;; WEAK-LIST->LIST! takes a weak list of futures, as
;; returned by DRAIN-WORK-QUEUE! and converts it to a list of
;; the objects referenced. The GC code needs the weak form,
;; hence the extra work here. In the process, each future is
;; made to be PAUSED so it will automatically resume if touched
(define (weak-list->list! weak-list)
(let loop ((current weak-list)
(result '()))
(if (null? current)
result
(let ((work-unit (weak-car current)))
(LOCKING-FUTURE work-unit work-to-do?
(if work-to-do?
(begin
(future-set! work-unit FUTURE-STATUS-SLOT 'PAUSED)
(loop (weak-cdr current)
(cons work-unit result)))
(loop (weak-cdr current) result)))))))
!
(define ((returned-object the-queue) #!optional message)
(if (unassigned? message) (set! message 'Restart-tasks))
(cond ((eq? message 'Any-Tasks?)
(and (not (eq? the-queue #!true))
(not (null? the-queue))))
((eq? message 'Restart-tasks)
(if (not (eq? the-queue #!true))
(release-state! the-queue)
(error "Attempt to re-use a pause object!"))
(set! the-queue #!true))
((eq? message 'The-Tasks)
(if (eq? the-queue #!true)
'()
the-queue))
(else (error "Pause object: strange message" message))))
(if (not (Futures-On?))
(returned-object '())
(let ((save-synch (make-synchronizer))
(drain-synch (make-synchronizer))
(proceed-synch (make-synchronizer)))
(stop-preempting)
(global-interrupt
1
(lambda (int-code int-mask)
(await-synchrony save-synch)
(saving-state
(lambda ()
(set-interrupt-enables! int-mask)
(await-synchrony drain-synch)
(await-synchrony proceed-synch))))
(lambda () #!TRUE))
(await-synchrony save-synch)
(await-synchrony drain-synch)
(let ((me (current-future))
(the-queue (weak-list->list! (drain-work-queue!))))
(set! Current-Future-Vector (vector-cons (N-Interpreters) 'PAUSED))
(Set-Current-Future! me)
(await-synchrony proceed-synch)
(returned-object the-queue)))))
!
;; WITH-TASKS-SUSPENDED executes the thunk with all other processes
;; stopped. It returns the value of the thunk.
(define (with-tasks-suspended thunk)
(if (not (Futures-On?))
(thunk)
(fluid-let ((the-paused-tasks (pause-everything)))
(dynamic-wind
(lambda ()
(if (the-paused-tasks 'any-tasks?)
(begin
(newline)
(display "[Suspending tasks]"))))
thunk
(lambda ()
(cond ((not (the-paused-tasks 'any-tasks?)) '())
(discard-the-paused-tasks?
(newline) (display "[Discarding tasks]") (newline))
(else
(newline) (display "[Resuming tasks]") (newline)
(the-paused-tasks 'Restart-tasks))))))))
;; Dealing with recently suspended tasks
(define (discard-recently-suspended-tasks!)
(set! discard-the-paused-tasks? #!true))
(define (prevent-discarding-processes!)
(set! discard-the-paused-tasks? #!false))
!
;; Execution within a selected task
(define (within-process future thunk)
(define (loop noisy?)
((LOCKING-FUTURE future true-future?
(if true-future?
(let ((status (future-ref future FUTURE-STATUS-SLOT))
(process (future-ref future FUTURE-PROCESS-SLOT)))
(cond ((non-touching-eq? future (current-future))
thunk)
((eq? status 'RUNNING)
(lambda ()
(if noisy?
(bkpt "WITHIN-PROCESS: process is running"))
(loop #!false)))
(else
(future-set! future FUTURE-PROCESS-SLOT
(lambda (arg) (thunk) (process 'go)))
(more-work future)
(lambda () (run future)))))
(begin
(error "WITHIN-PROCESS: Not a process" future)
(lambda () (next)))))))
(loop #!true))
)) ; end of Make-Environment for Scheduler
!
; Export definitions to the world outside the scheduler
(define initialize-scheduler! (access initialize-scheduler! scheduler))
(define determine! (access determine! scheduler))
(define future-scheduler (access future-scheduler scheduler))
(define dfuture-scheduler (access dfuture-scheduler scheduler))
(define delay-scheduler (access delay-scheduler scheduler))
(define next (access reschedule scheduler))
(define wait-until-idle (access wait-until-idle scheduler))
(define pause-everything (access pause-everything scheduler))
(define with-tasks-suspended (access with-tasks-suspended scheduler))
(define discard-recently-suspended-tasks!
(access discard-recently-suspended-tasks! scheduler))
(define prevent-discarding-processes!
(access prevent-discarding-processes! scheduler))
(define Current-Future (access Current-Future scheduler))
(define Futures-On? (access Futures-On? scheduler))
(define Futures-Off (access Futures-Off scheduler))
(define Saving-State (access Saving-State scheduler))
(define within-process (access within-process scheduler))
(define Disjoin (access disjoin scheduler))
(define Await-First-Of (access await-first-of scheduler))
(define (futures-on #!optional slice)
(if (unassigned? slice) (set! slice '()))
(initialize-scheduler! slice dfuture-scheduler))
(define (non-touching-memq element list)
(cond ((null? list) #!false)
((non-touching-eq? element (car list)) list)
(else (non-touching-memq element (cdr list)))))
(define (non-touching-assq element list)
(cond ((null? list) #!false)
((non-touching-eq? element (caar list)) (car list))
(else (non-touching-assq element (cdr list)))))
!
(add-syntax! 'future
(macro (expression #!optional doc user-scheduler)
`((ACCESS SPAWN-PROCESS SCHEDULER)
(LAMBDA () ,expression) ; Work to do
,(if (unassigned? doc) ; Documentation
(with-output-to-string
(lambda () (display expression)))
doc)
,@(if (unassigned? user-scheduler) ; Start-up procedure
'()
`(,user-scheduler)))))
(futures-on)
∂23-Jul-87 2003 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Recognizing QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 20:03:27 PDT
Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 23 Jul 87 22:57:17 EDT
Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP
id aa21492; 23 Jul 87 22:19 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 23 Jul 87 22:18:07 -0100
Message-Id: <13530.8707232118@aiva.ed.ac.uk>
To: scheme@mc.lcs.mit.edu
Subject: Recognizing QUOTE deemed harmful to EVAL's laziness
> From: Jonathan A Rees <JAR@edu.mit.ai.ai>
> I don't quite see what the big deal is. I agree that reduction is a
> somewhat nicer but it doesn't seem to be a very deep question. [...]
Well, that depends on whether you're a "purist" or a "pragmatist"
(relatively speaking). It's like the debate over the lack of a proper
function type in Common Lisp, or the question of whether the need to
use FUNCTION around lambda-expressions is or is not a trivial matter
of syntax... Well, maybe.
∂24-Jul-87 0337 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Recognising QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 87 03:37:18 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Jul 87 06:16:36 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA15302; Fri, 24 Jul 87 02:43:28 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Jul 87 12:23:54 GMT
From: mcvax!inria!crcge1!adams@seismo.css.gov (Drew Adams)
Subject: Re: Recognising QUOTE deemed harmful to EVAL's laziness
Message-Id: <2718@crcge1.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Further References
------------------
I neglected to mention that the idea that QUOTE is properly treated
as a constructor (in a reduction setting) is due to Alan Robinson.
Thanks to Jan Prins for reminding me.
Here's the paper where he discusses denotation vs. reduction with
respect to quote. I don't know of a more recent one.
%T New Generation Knowledge Processing
%A J. A. ROBINSON
%R First Annual Progress Report
%I Syracuse University
%C Syracuse, New York
%D December 1984
That paper introduces the "unknown-tolerant" fully lazy functional
logic language SUPER being developed at Syracuse University. The
essential reference dealing with the functional basis of SUPER is:
%T A Fully Lazy Higher Order Purely Functional Programming Language
with Reduction Semantics
%A Kevin J. GREENE
%I Syracuse University
%C Syracuse, New York
%D August 1985
%O Ph.D. Thesis
Thanks also to Stan Shebs for reminding me of Brian Smith's work on
3-LISP, which (among other things) is another attempt to clean up the
semantics of quotation (and more). Here are two accessible
references.
%T The Implementation of Procedurally Reflective Languages
%A Jim des RIVIERES
%A Brian Cantwell SMITH
%B ACM Symposium on LISP and Functional Programming
%C Austin, Texas
%I ACM
%P 331-347
%D August 6-8, 1984
%T Reflection and Semantics in Lisp
%A Brian Cantwell SMITH
%B Eleventh Annual ACM Symposium on Principles
of Programming Languages (POPL)
%C Salt Lake City, Utah
%I ACM
%P 23-35
%D January 15-18, 1984
In case some who read this didn't see Stan's message, here is part:
"His basic point of view is that quoting is important to
distinguish levels of meta-ness, and so quoted objects
are promoted to first-class types known as handles.
There are operations UP and DOWN that add and remove
handles, since evaluation does not; (eval '2) => '2.
Also, (+ 2 '3) is an semantic error, like taking the car
of an number.
In other words, Smith also uses an essentially *reducing* EVAL,
separating out a separate denotation mechanism.
--
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, adams@crcge1.cge.fr
∂24-Jul-87 0415 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Recognising QUOTE deemed harmful to EVAL's laziness
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 87 04:15:30 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Jul 87 06:18:06 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA15326; Fri, 24 Jul 87 02:44:52 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Jul 87 12:26:04 GMT
From: mcvax!inria!crcge1!adams@seismo.css.gov (Drew Adams)
Subject: Re: Recognising QUOTE deemed harmful to EVAL's laziness
Message-Id: <2719@crcge1.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
WARNING: Too long (again!)
Regarding My Original Posting and Replies:
-----------------------------------------
Thanks for the commentaries. I'm sorry my posting wasn't clearer
(and shorter). I wish this reply were shorter as well.
FIRST, some general remarks aimed to clear up misunderstandings due
(I think) to terminology, etc..
1) By EVAL I mean the LISP (or SCHEME) interpreter itself, as well as
explicit calls to the procedure EVAL in the program. Some people
quite naturally assumed I mean the latter only, thus wondering about
the "relevance to SCHEME (which has no EVAL)". [J. Rees]
2) DELAY/FORCE vs. QUOTE/EVAL: The former are used in eager
implementations to simulate (program, implement, etc.) lazy
evaluation. E.g., Uday Reddy mentions that
"The use of quotation for delayed evaluation is now widely
recognized to be misguided. Modern LISPs, such as SCHEME,
have constructs like "DELAY" to achieve lazy evaluation."
DELAY and FORCE achieve "call-by-name" which is sometimes called
"laziness", but they don't usually achieve "*full* laziness", (what
Robert Firth called "true laziness" in the original posting), which
was the issue under discussion. My point has nothing to do with
whether or not people would be better off avoiding QUOTE/EVAL and
using DELAY/FORCE. My point is that implicit recognition of
quotation by the interpreter (EVAL) gets in the way of *implementing*
(in the interpreter) full laziness, as repeated evaluations of the
same (quotation) expression *don't* yield the same result.
[A. Freeman, U. Reddy]
3) I think the biggest communication problem arose from my not making
sufficiently clear that I'm not concerned with differentiating
external expressions from internal data structures etc., as well as
from the different meanings "expression", "symbol" etc. might have
in different communities. I'm ignoring what goes on inside a LISP
implementation (data structure representation, binding etc.)
completely and am referring only to externally observed behavior as
determined by input and output *expressions* (= Sexprs). Thus, when
I refer to the "result" or "value" of an expression I by definition
mean the printed result. An example of the confusion [U. Reddy]:
"Since FOO can never be the normal form value of any
expression (if FOO is bound, then its binding is the
normal form and, if it is unbound, then it is an error)
they print FOO and expect the user to understand it as
(QUOTE FOO)."
I equate the expression FOO with its binding, as the normal form. If
unbound, I consider the expression FOO itself to be the normal form.
[J. Rees, A. Freeman, U. Reddy]
4) When I speak of that which is "denoted" by an expression I mean
(in LISP) the printed result of the expression, and I equate this
with whatever the programmer might have in mind that the expression
represents *for her*. Thus, in this view everything is regarded only
in its external aspect, as an expression, and all denoted values are
themselves expressions. Hence I wrote:
"(For simplicity, let's assume denoted values are always
expressions; values of the function represented by the
functor QUOTE are necessarily so.)
An expression then *is* "use" of that expression and a quoted
expression is "mentioned" (although the entire quotation itself is
"used", the "use" of the functor QUOTE serving to "mention" its
argument.) [U. Reddy]
5) When I speak of two expressions being denotationally *equivalent*
I thus mean
a) they both mean the same thing to the programmer,
b) they have the same operational behavior; that is, the
function (EVAL, MEANING etc.) which identifies their
meanings returns the "same" result for both,
c) "same", or "equivalent" *meaning* is operationally
determined (defined) by the interpreter's equality
predicate itself (EQ, EQUAL, =, etc.)
This is why I referred to
"equivalent meaning, as determined, or shown, by the operation
of the language's equality predicate"
and
"meaning ... the same as ... as determined by LISP predicates
such as EQ and EQUAL"
[U. Reddy]
6) Of course LISP may be made lazy, the function MEANING may be
programmed in LISP, the LISP evaluator may be rendered QUOTE-less,
etc.. My point was rather that
a) it's simple to leave quotation recognition out of LISP
*to begin with*,
b) the result of doing so is a *reduction* engine, no more,
no less,
c) a function such as MEANING, to perform what I'm calling
denotation, is simple to define in a reduction setting,
so that LISP's implicit recognition of quotation *isn't
necessary* in order to have a useful denotation
mechanism,
d) without getting rid of LISP's automatic treatment of
quotation it's not *simple* (direct, straightforward,
etc.) to implement lazy interpretation.
[J. Rees, A. Freeman, U. Reddy]
!
SECOND, a few specific comments on some of the replies:
To J. REES:
----------
1) I admit I'm not sure I understand your proposal correctly.
I think you mean to
(1) keep the standard LISP (or SCHEME) interpreter but
replace explicit programmer calls to the procedure
EVAL by calls to NORMALIZE.
(2) reserve quotation for things that aren't self
evaluating (i.e. "things which don't [I assume you
mean 'do'] need it")
(3) change PRINT a bit so that the printed result of
evaluation is always a quotation or a self-evaluating
expression
I don't see how this provides reduction semantics. Let's leave aside
(1) for the moment, assuming nobody explicitly normalizes anything.
Here's the original example I gave, with some cosmetic changes to
protect the innocent:
if the value of FOO is defined to be BAR then (EQUAL 'BAR FOO)
is true (T), whereas (EQUAL 'BAR 'FOO) is false (NIL).
Thus FOO and (QUOTE FOO) *aren't* equivalent, as determined by
EQUAL, yet the former is the result of interpreting the latter.
Such an interpretation isn't, therefore, a reduction.
Now, let the value of BAR be TOTO. Then, asking for the meaning of
the meaning of FOO: (NORMALIZE FOO) gives (QUOTE TOTO). Why not
TOTO? I think that you, as well as U. Reddy (see number 3), below)
and perhaps others, were aiming at a different kind of denotation
mechanism than what I had in mind: one that, instead of just
removing a level of "mention", returns a *mention* of the denoted
value. Anyway, that's what I understand from your treatment of
PRINT, etc.. That's fine too, although in that case I would opt for
consistency in the case of numbers, strings, etc. too. Such
consistency is important, if not always for users in an interactive
setting, at least for *programs* that might manipulate or reason
about evaluation results.
!
To U. REDDY:
-----------
1) Here's your
"counterexample, assuming FOO is bound to 2 in the context:
(QUOTE FOO) -> (QUOTE 2) by innermost reduction
But (QUOTE FOO) and (QUOTE 2) are different objects"
As mentioned above, I'm using the interpreter's equality predicate
(e.g. EQUAL) to measure semantic equivalence. Assuming this, and
assuming that we're both talking expression reduction and aren't
concerned with LISP "objects" as different from their external
Sexprs, I don't agree that the values denoted by (QUOTE FOO) and
(QUOTE 2) are different. (EQUAL (QUOTE FOO) (QUOTE 2)) ==> T.
Likewise: (EQUAL FOO 2) ==> T. The two quotations "mention" the
*same* (as judged by EQUAL) value, which happens to have (at least)
two names: FOO and 2.
This of course means that reduction rules are not to be used to
establish values (in the sense of meanings), but rather equivalences.
From the moment that we equate two expressions via a reduction rule
we no longer have any external way to distinguish them; we've just
declared them to be indistinguishable. This means that if we want to
differentiate, we must do it at an external meta-level: *we* (or an
external program) can *see* a difference between (QUOTE FOO) and
(QUOTE 2). By accepting to recognize such a difference we place
ourselves at a meta-level *unknown to the interpreter*. This is not
a meta-level *defined* to the interpreter via MEANING. It is not
even definable, once we've declared FOO and 2 to be indistinguishable.
2) Regarding (QUOTE FOO) and FOO, you write:
"They aren't equivalent. So why say that (QUOTE FOO) denotes
FOO?"
Would you be happy reading "mentions" for "denotes"? Be happy then;
that's what I mean by "denotes". QUOTE mentions and EVAL (or
MEANING) returns the value mentioned by a quotation. I say "denotes"
because I want to use EVAL/MEANING for other than just quotations.
3) You write:
"Since LISP does not have a separate syntax for data objects
and programs ..., data objects are treated as "mentions" of
S-expressions and programs are treated as "uses" of them."
Exactly. This is one of my points, that LISP obliges the programmer
to use the *same* mechanism/notation when expressing data structures
etc. as when shifting semantic levels. I wrote:
"as all computation in LISP is evaluation (in a denotational
sense), the programmer is obliged to conceptually move up
and down between semantic levels that are essentially
artificial in a purely declarative setting. They don't
correspond to her conception of the meaning of the program
but rather function as an ad hoc mechanism to keep the
eagerness of EVAL at bay. She in fact eventually learns to
ignore or abstract from them when mentally interpreting code.
LISP requires programmers to employ quotation even when it
serves no apparent semantic purpose."
The last line would be better written "serves a different semantic
purpose, if any".
4) You mention that "[normalizers] are inefficient compared to
evaluators." How does taking quotation recognition out of pure LISP
leave it less efficient? The answer, I suppose, is that some other
mechanism must then be found for preventing unintended evaluation.
Normal order reduction is an obvious candidate, and is perhaps what
you had in mind. It is indeed in general less efficient. But it's
not the only mechanism possible. Wouldn't it be desirable to perform
strictness analysis to find arguments to be interpreted "by-value"?
5) I wrote:
"The quotation mechanism itself may of course be provided
quite simply by the general rule:
Meaning (Quote x) = x
where QUOTE is simply a constructor (undefined symbol).
Then:
Meaning (Quote -12) ==> -12"
You write:
"This works only if outermost evaluation is the default
(standard) evaluation of the language."
I can see why you might say this, considering the confusion over
number 1), above. Otherwise, I can't see why this would be true. As
reduction is equivalence-preserving, it can't matter where you start
reducing, inside, outside, mix and match, .... (excepting, of
course, non-terminating interpretation).
6) You write:
"It is by no means universally accepted that outermost
evaluation as the default is "good", and many people who
work with outermost evaluation have reservations about
using it as the default."
I agree. You and I are both, I believe, two such people. I mention
this so folks who aren't familiar with your work may know that
you're "lazier" than your reply might indicate. :)
-------------
As I'm going on vacation for a month I won't be around to keep up the
provocation. I look forward however to seeing how things will turn
out. Again, thanks for the comments and sorry about the confusion &
length. -- drew
--
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie
Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
Tel. 64.49.11.54, adams@crcge1.cge.fr
∂24-Jul-87 2128 @MC.LCS.MIT.EDU:narain%pluto@rand-unix.ARPA Quotation regarding QUOTE
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 87 21:28:04 PDT
Received: from rand-unix.arpa (TCP 1200600007) by MC.LCS.MIT.EDU 24 Jul 87 12:41:10 EDT
Received: by rand-unix.arpa; Fri, 24 Jul 87 08:49:49 PDT
Received: from localhost by pluto.arpa; Fri, 24 Jul 87 08:50:34 PDT
Message-Id: <8707241550.AA08641@pluto.arpa>
To: scheme@mc.lcs.mit.edu, narain%pluto@rand-unix.ARPA
Subject: Quotation regarding QUOTE
Date: Fri, 24 Jul 87 08:50:31 PDT
From: narain%pluto@rand-unix.ARPA
In the discussions of QUOTE, it would be useful to keep in mind its origins.
Consider the following:
In order that constants can always be distinguished from
variables however, they will be quoted. That is, a 2-list
will be formed whose first element is the keyword QUOTE
and whose second element is the constant. Hence the constants
127, NIL, (A B) and X will be represented by the S-expressions
(QUOTE 127), (QUOTE NIL), (QUOTE (A B)), (QUOTE X) respectively.
There is no exception to this rule: variables are *never*
quoted, constants are *always* quoted.
Peter Henderson
Functional Programming: Application & Implementation
Page 97
Note that quotation is hardly required in Prolog since it has another
convention for distinguishing variables from constants.
Sanjai Narain
Rand Corp.
∂29-Jul-87 0642 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU backquote semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 06:41:59 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 29 Jul 87 09:39:08 EDT
Date: Wed, 29 Jul 87 09:41:25 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: backquote semantics
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <234576.870729.JAR@AI.AI.MIT.EDU>
re-sending...
Date: Mon, 27 Jul 87 15:55:40 EDT
From: Jonathan A Rees <JAR@mc.lcs.mit.edu>
Subject: backquote semantics
To: stevev%tekchips.tek.com@RELAY.CS.NET
cc: rrrs-authors%tekchips.tek.com@RELAY.CS.NET
In-reply-to: Msg of 22 Jul 87 14:16:12 PDT (Wed) from Steve Vegdahl <stevev%tekchips.tek.com at RELAY.CS.NET>
Message-ID: <233499.870727.JAR@AI.AI.MIT.EDU>
Date: 22 Jul 87 14:16:12 PDT (Wed)
From: Steve Vegdahl <stevev%tekchips.tek.com at RELAY.CS.NET>
(define foo
(lambda () '(x y z)))
(define baz
(lambda () `(x y z)))
(define grump
(lambda (k) `(x y z ,k)))
Are the following expressions true, false, or implementation-dependent?
1: (eq? (foo) (foo))
2: (eq? (baz) (baz))
3: (eq? (grump 'w) (grump 'w))
This is definitely an ommission from the report; I don't think the issue
ever got much discussion. Personally I don't much care how backquote
works, although I think it would be nice if it did a minimum of consing.
Other people think differently. My advice would be to assume it's
implementation-dependent until the question gets discussed on this
mailing list, and to see Steele's book Common Lisp: The Language for a
discussion of the range of possible implementations until something
better comes along.
∂12-Aug-87 1601 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 16:01:28 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Aug 87 18:54:35 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac01166; 12 Aug 87 18:39 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aw06697; 12 Aug 87 18:28 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA19826; Wed, 12 Aug 87 14:13:49 PDT
Received: by tekchips.TEK.COM (5.51/6.24)
id AA15730; Wed, 12 Aug 87 14:11:57 PDT
Message-Id: <8708122111.AA15730@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Gabriel benchmarks in Scheme
Date: 12 Aug 87 14:11:55 PDT (Wed)
From: willc%tekchips.tek.com@RELAY.CS.NET
In the most recent issue of Lisp Pointers, Walter van Roggen asked implementors
to send in their most recent timings for the Gabriel benchmarks. I would like
to encourage implementors of Scheme to respond to this request.
I have recently finished translating the Gabriel benchmarks (except for STAK,
which is a test of fluid variables, and FRPOLY, which is written "in a somewhat
unpleasant programming style" that is hard to understand or translate) into
Scheme. Please let me know if you would like the source code.
Some of the benchmarks use property lists; I didn't try to change that, because
most implementations can mimic property lists. At least one of them (BROWSE)
also assumes that CAR and CDR of the empty list is the empty list; I didn't
try to change that either. Otherwise the benchmarks should be reasonably
portable. They have been run in MacScheme.
I changed the CTAK benchmark, which tested both fluid binding and escapes,
into a straight test of CALL-WITH-CURRENT-CONTINUATION. Otherwise the tests
measure pretty much the same things in Scheme as they do in Common Lisp.
(That's not to say I always understand what they are supposed to measure in
Common Lisp.) Because the Gabriel benchmarks do not test first class
procedures and do use much tail-recursion, I have added a continuation-passing
version of TAK to the Scheme benchmarks.
peace, William Clinger
Tektronix Computer Research Lab
willc%tekchips.tek.com@relay.cs.net
∂12-Aug-87 1648 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com MacScheme+Toolsmith Version 1.0
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 16:48:27 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Aug 87 18:55:04 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ae01166; 12 Aug 87 18:39 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id bc06697; 12 Aug 87 18:29 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA20655; Wed, 12 Aug 87 14:53:21 PDT
Received: by tekchips.TEK.COM (5.51/6.24)
id AA16770; Wed, 12 Aug 87 14:51:32 PDT
Message-Id: <8708122151.AA16770@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: MacScheme+Toolsmith Version 1.0
Date: 12 Aug 87 14:51:30 PDT (Wed)
From: willc%tekchips.tek.com@RELAY.CS.NET
Apology: While this amounts to a commercial announcement, I believe its
technical content should be of great interest to the Scheme and Lisp
communities.
MacScheme+Toolsmith Version 1.0 is being introduced this week at the
MacWorld Expo in Boston. One feature of this product is particularly
significant: The Application Builder is a selective linker that makes
it easy to construct standard, double-clickable Macintosh applications
that are practically indistinguishable from applications written in
mainstream programming languages such as Pascal and C. While applications
written in Scheme tend to be larger than if they were written in Pascal
or C, they are not so large as to be outrageous. The smallest complete
applications occupy less than 100K bytes on disk.
By a selective linker I mean that the Application Builder automatically
removes unused code and data from the Scheme library as it builds the
application. Selective linking is made possible by the clean design of
Scheme, which maintains a rigorous distinction between program and data.
It is impossible to write a reliable and effective selective linker for
other dialects of Lisp, because they do not maintain this distinction.
The Application Builder does permit the use of EVAL and LOAD in an
application, but their use defeats selective linking in most cases.
MacScheme+Toolsmith Version 1.0 also includes a native code compiler
that is almost decent. That is, it is several times faster than previous
Lisp compilers for the Macintosh, and is able to bear comparison with the
best microcomputer Lisp compilers available.
Other notable features of MacScheme+Toolsmith include support for the
Macintosh Toolbox traps, a programmable interrupt system, and multitasking.
As an author of this system, I am quite proud of it. Since it was made
possible by the high quality of the Scheme language itself, it seems only
fair that the Scheme community at large should be able to share my joy.
Peace, William Clinger
∂12-Aug-87 1853 @MC.LCS.MIT.EDU:fateman@renoir.Berkeley.EDU Re: Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 18:53:19 PDT
Received: from renoir.Berkeley.EDU (TCP 20010101004) by MC.LCS.MIT.EDU 12 Aug 87 19:38:15 EDT
Received: by renoir.Berkeley.EDU (5.58/1.25)
id AA03890; Wed, 12 Aug 87 16:36:13 PDT
Date: Wed, 12 Aug 87 16:36:13 PDT
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8708122336.AA03890@renoir.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu, willc%tekchips.tek.com@relay.cs.net
Subject: Re: Gabriel benchmarks in Scheme
Cc: rrrs-authors@mc.lcs.mit.edu
The guts of the FRPOLY benchmark was written by the late
Prof. William A. Martin, of MIT, c. 1968. That is, before
many people reading this were born, and when the Mathlab group was
concerned with other issues than those we face today in
programming and teaching programming.
I think that the part that causes
the most difficulty in understanding is in the middle
of the polynomial multiplication routine. A more straightforward
program, such as the one in Scheme given in Abelson/Sussman↑2,
can use O(n↑2) rather than O(n) conses in multiplying two degree-n
polynomials compared to Martin's program.
I find it unfortunate that people feel they have to understand code
in MacLisp in order to translate it into Scheme.
Can't this be done automatically?
∂12-Aug-87 2227 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Aug 87 22:27:06 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 13 Aug 87 00:44:07 EDT
Received: by ZOHAR.AI.MIT.EDU; Wed, 12 Aug 87 23:36:17 edt
Date: Wed, 12 Aug 87 23:36:17 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8708130336.AA08981@zohar>
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: willc%tekchips.tek.com@RELAY.CS.NET's message of 12 Aug 87 14:11:55 PDT (Wed) <8708122111.AA15730@tekchips.TEK.COM>
Subject: Gabriel benchmarks in Scheme
great.. please bring them when you come.
regards to anne
∂13-Aug-87 0900 @MC.LCS.MIT.EDU:jrl@ZERMATT.LCS.MIT.EDU Re: MacScheme+Toolsmith Version 1.0
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 87 09:00:49 PDT
Received: from RTS-10.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 AUG 87 11:55:17 EDT
Message-Id: <2764857083-3315152@RTS-10>
Sender: JRL@RTS-10
Date: Thu, 13 Aug 87 11:51:23 EDT
From: jrl@ZERMATT
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: scheme@mc.lcs.mit.edu
Subject: Re: MacScheme+Toolsmith Version 1.0
In-Reply-To: Msg of 12 Aug 87 14:51:30 PDT (Wed) from willc%tekchips.tek.com@RELAY.CS.NET
Selective linking is made possible by the clean design of
Scheme, which maintains a rigorous distinction between program and data.
It is impossible to write a reliable and effective selective linker for
other dialects of Lisp, because they do not maintain this distinction.
Peace, William Clinger
This is an intriguing statement. Can you amplify on this. Is it the use
of symbols both as first class objects and as names that causes the
problems or is it something else?
Juan
∂13-Aug-87 1041 @MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU C Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 87 10:38:18 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 13 Aug 87 13:14:10 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/13/87 at
13:11:59 EDT
Received: from SUNRISE.BITNET (KSWANSON) by MITVMA.MIT.EDU (Mailer
X1.24) with
BSMTP id 3518; Thu, 13 Aug 87 13:11:55 EDT
Date: Thu, 13 Aug 87 13:02 EST
From: <KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU>
Subject: C Scheme
To: scheme@mc.lcs.mit.edu
X-Original-To: scheme@mc.lcs.mit.edu
I'm interested in obtaining a copy of C Scheme, for VMS and UNIX. I
tried the telnet way, but wasn't able to get it to work. Is there anyone on
BITNET with a copy of either or both of theses who could send/file them to me?
Your cooperation is most appreciated,
Kurt Swanson
∂13-Aug-87 1528 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 87 15:27:49 PDT
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 13 Aug 87 18:22:36 EDT
Received: by MURREN.AI.MIT.EDU; Thu, 13 Aug 87 18:19:48 edt
Date: Thu, 13 Aug 87 18:19:48 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8708132219.AA01596@murren>
To: fateman@renoir.Berkeley.EDU, scheme@mc
In-Reply-To: Richard Fateman's message of Wed, 12 Aug 87 16:36:13 PDT <8708122336.AA03890@renoir.Berkeley.EDU>
Subject: Gabriel benchmarks in Scheme
Reply-To: hal@ai.ai.mit.edu
Rich Fateman writes:
I find it unfortunate that people feel they have to understand code
in MacLisp in order to translate it into Scheme.
Can't this be done automatically?
I don't want to disparage the Macsyma code (and I have the greatest
respect for the memory of Bill Martin), but it is not a good idea to
run benchmarks based on code that one doesn't understand, whether or
not the translation to Scheme is done automatically.
The most striking example of this is the Gabriel Boyer-Moore
benchmark, which always
(a) returns as its value the value of a PROG that falls off the end
(e.g., ALWAYS produces NIL)
(b) follows a computation path that turns out to depend upon the
default test used by MEMBER. MacLisp and ZetaLisp here use EQUAL and
CL uses EQL. Because of this, initially people at Symbolics thought
that one of their implementations ran this benchmark much faster than
the other -- it turned out that the two implementations were following
completely different execution paths.
Figuring out these bugs wasted a lot of time on the part of Sussman
and Don Allen.
Given that the Scheme community is trying to avoid the
over-complexities of Common Lisp, it is not too inappropriate for us
to give some effort to using understandable benchmarks.
∂13-Aug-87 2355 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com FRPOLY; philosophy of benchmarking
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 87 23:55:15 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Aug 87 02:52:37 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04759; 14 Aug 87 2:48 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa15182; 14 Aug 87 2:39 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA04478; Thu, 13 Aug 87 15:53:21 PDT
Received: by tekchips.TEK.COM (5.51/6.24)
id AA05333; Thu, 13 Aug 87 15:51:04 PDT
Message-Id: <8708132251.AA05333@tekchips.TEK.COM>
To: fateman@RENOIR.BERKELEY.EDU
Cc: scheme@mc.lcs.mit.edu
Subject: FRPOLY; philosophy of benchmarking
In-Reply-To: Your message of Wed, 12 Aug 87 16:36:13 PDT.
<8708122336.AA03890@renoir.Berkeley.EDU>
Date: 13 Aug 87 15:51:01 PDT (Thu)
From: willc%tekchips.tek.com@RELAY.CS.NET
Thank you for explaining the history of the FRPOLY benchmark. I was
TA for a course in which Professor Martin lectured at MIT.
I certainly believe it is possible to translate MacLisp code automatically
into Scheme, and I even suspect that it is easier than translating (e.g.)
Ada automatically into Common Lisp. But that's not a very interesting issue.
It is important for people to understand benchmarks so they can
understand what the results of the benchmark mean. Without
that understanding, benchmarking is a worse than useless exercise.
I don't understand FRPOLY well enough to convert its PROGs into
idiomatic Scheme code. Scheme doesn't support PROG. I know an
algorithm for translating any PROG into a single use of
CALL-WITH-CURRENT-CONTINUATION surrounding a LETREC, and I have
used that algorithm on occasions when my sole interest was in
getting an antique piece of code to run, but mindless application
of the algorithm makes the code even more opaque.
I might add that several other of the Gabriel benchmarks are too
large for their significance to be comprehended easily, but with
the others I was able to translate them into reasonably idiomatic
Scheme code after only a little study. I would be delighted if
someone who understood the FRPOLY benchmark were to translate it
into Scheme. I think it is far better for that to happen after
some delay than for me to do a quick but poor translation.
peace,
Will Clinger
∂14-Aug-87 0034 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com selective linking in Lisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 00:34:05 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Aug 87 03:01:08 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04851; 14 Aug 87 2:59 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id au15182; 14 Aug 87 2:49 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA08274; Thu, 13 Aug 87 16:57:04 PDT
Received: by tekchips.TEK.COM (5.51/6.24)
id AA07301; Thu, 13 Aug 87 16:55:13 PDT
Message-Id: <8708132355.AA07301@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: selective linking in Lisp
From: willc%tekchips.tek.com@RELAY.CS.NET
Date: 13 Aug 87 16:55:11 PDT (Thu)
Sender: willc%tekchips.tek.com@RELAY.CS.NET
[my attempt to reply directly to jrl@zermatt failed; he posted his
question here, so I'll reply here]
This is an intriguing statement. Can you amplify on this. Is it the use
of symbols both as first class objects and as names that causes the
problems or is it something else?
Depends on what you mean by that. You can't do reliable selective linking
on a program that calls EVAL (or its kin such as SYMBOL-VALUE,
SYMBOL-FUNCTION, etc) unless the linker can determine the arguments
that are passed to EVAL, which is impossible in general. The reason EVAL
defeats selective linking is that the argument to EVAL, being a computed
quantity, potentially refers to just about any procedure or variable.
This is true in all Lisps, including Scheme.
The problem with Lisps other than Scheme is that all sorts of standard
procedures are specified in such a way that they potentially call EVAL
(or SYMBOL-VALUE or SYMBOL-FUNCTION), so even if you scrupulously avoid
calling EVAL yourself you still lose because you call FUNCALL or APPLY
or something else that calls EVAL (or SYMBOL-VALUE or SYMBOL-FUNCTION).
I raised this with the Common Lisp cleanup subcommittee and at the last
X3J13 meeting, and was astounded to learn that the Common Lisp vendors
generally feel that selective linking isn't worth thinking about. They
may be right, in the sense that it would take a fairly drastic overhaul
of Common Lisp to make it possible to write reliable selective linkers.
I expect most vendors will eventually write unreliable selective linkers
that ignore the problems posed by EVAL and its kin, or else they will
rely on the programmer to declare all variables that might be needed by
a call to EVAL. This might well be good enough for government work.
Peace, Will Clinger
Tektronix Computer Research Lab
∂14-Aug-87 0128 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 01:28:03 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 14 Aug 87 04:17:37 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA01671; Fri, 14 Aug 87 01:14:28 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 14 Aug 87 06:52:35 GMT
From: phr@hermes.ai.mit.edu (Paul Rubin)
Organization: The MIT AI Lab, Cambridge, MA
Subject: Re: Gabriel benchmarks in Scheme
Message-Id: <2882@mit-hermes.AI.MIT.EDU>
References: <8708122336.AA03890@renoir.Berkeley.EDU>, <8708132219.AA01596@murren>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I notice that most of the Gabriel benchmarks were run under ORBIT
(the compiler for the T system (T is a Scheme dialect)). Possibly
you could get in touch with the T authors to avoid duplicating some
of the effort of benchmark conversion. See "ORBIT: An Optimizing
Compiler for Scheme" by David Kranz et al, Proc. SIGPLAN '86
Symposium on Compiler Construction. That is a good paper to read
if you are interested in Scheme compilation, too.
∂14-Aug-87 1757 @MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU Re: FRPOLY; philosophy of benchmarking
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 17:57:47 PDT
Received: from UDEL.EDU (TCP 1200000140) by MC.LCS.MIT.EDU 14 Aug 87 20:19:40 EDT
Received: from dewey.udel.edu by Louie.UDEL.EDU id aa04086; 14 Aug 87 10:40 EDT
Received: from localhost by Dewey.UDEL.EDU id aa07797; 14 Aug 87 10:40 EDT
To: willc%tekchips.tek.com@relay.cs.net
cc: fateman@renoir.berkeley.edu, scheme@mc.lcs.mit.edu
Subject: Re: FRPOLY; philosophy of benchmarking
In-reply-to: Your message of Thu, 13 Aug 87 15:51:01 -0700.
<8708132251.AA05333@tekchips.TEK.COM>
Date: Fri, 14 Aug 87 10:40:12 -0400
From: David Saunders <saunders@UDEL.EDU>
Message-ID: <8708141040.aa07797@Dewey.UDEL.EDU>
I'd like to see the FRPOLY benchmark. I might even undertake the translation
to scheme. Can you send me a copy?
Thanx, Dave Saunders
∂14-Aug-87 1847 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu Re: selective linking in Lisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87 18:47:04 PDT
Received: from bu-cs.BU.EDU (TCP 30003134401) by MC.LCS.MIT.EDU 14 Aug 87 20:21:04 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-cs.BU.EDU (3.2/4.7)
id AA01313; Fri, 14 Aug 87 16:45:44 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA15964; Fri, 14 Aug 87 07:36:46 edt
Date: Fri, 14 Aug 87 07:36:46 edt
From: gjc@bucsf.bu.edu (George J. Carrette)
Message-Id: <8708141136.AA15964@bucsf>
To: scheme@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: selective linking in Lisp
There is no problem with selective linking while using EVAL,
the problem comes up when you add to this the use of
INTERN or READ.
∂16-Aug-87 1804 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu Re: Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Aug 87 18:04:28 PDT
Received: from bu-cs.BU.EDU (TCP 30003134401) by MC.LCS.MIT.EDU 16 Aug 87 20:29:21 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-cs.BU.EDU (3.2/4.7)
id AA01328; Fri, 14 Aug 87 16:45:50 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA15933; Fri, 14 Aug 87 07:25:16 edt
Date: Fri, 14 Aug 87 07:25:16 edt
From: gjc@bucsf.bu.edu (George J. Carrette)
Message-Id: <8708141125.AA15933@bucsf>
To: scheme@mc.lcs.mit.edu, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: Gabriel benchmarks in Scheme
Cc: rrrs-authors@mc.lcs.mit.edu
There was a continuation passing version of tak I ran in VAX-NIL
and submitted a couple years ago, called TAKF. It made it into
"the book" but unfortunately was not run by many (if any) other
lisp implementors. Perhaps an interesting note, on the MIT Lispmachine
instruction set (CADR, LM-2, LMI-LAMBDA, TI-EXPLORER) the procedures
for TAK and TAKF compile into exactly the same sequence of instructions,
and TAKF is slightly faster, with one memory reference less per
procedure call (no, make that two memory reference, one for the
exit-vector and one for the function-cell).
Needless to say, in most lisps TAKF is considerably slower than TAK.
In Maclisp or Franz, with FUNCALL, quite considerably slower,
although with SUBRCALL in Maclisp there is no problem.
∂16-Aug-87 1931 @MC.LCS.MIT.EDU:masinter.pa@Xerox.COM Re: selective linking in Lisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Aug 87 19:30:56 PDT
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 16 Aug 87 21:49:38 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 AUG 87 02:37:48 PDT
Date: 16 Aug 87 02:37 PDT
From: masinter.pa@Xerox.COM
Subject: Re: selective linking in Lisp
In-reply-to: willc%tekchips.tek.com@RELAY.CS.NET's message of 13 Aug 87
16:55:11 PDT (Thu)
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: scheme@mc.lcs.mit.edu
Message-ID: <870816-023748-4773@Xerox>
Will, in regard to selective linking in Common Lisp, your
characterization of the response from the cleanup committee and X3J13 is
incorrect.
I've reviewed the mail on the topic (issue "EVAL-DEFEATS-LINKER".) None
of the responses came close to suggesting that "selective linking isn't
worth thinking about." However, a number of people responded that they
thought about it in a different way than you do. The specific issue was
discussed at length, and the discussion has not been brought to a
conclusion.
I don't think this is the appropriate forum to debate the point or to
summarize the alternatives discussed so far. If anyone is interested in
helping carry this topic further, I can make the mail archives
available.
∂17-Aug-87 0257 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Pausing garbage collection
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Aug 87 02:57:06 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 17 Aug 87 04:36:06 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA02931; Sat, 15 Aug 87 20:38:07 EDT
Posted-Date: Sat, 15 Aug 87 20:37:59 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA07174; Sat, 15 Aug 87 20:37:59 EDT
Date: Sat, 15 Aug 87 20:37:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8708160037.AA07174@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Pausing garbage collection
Sorry about using this mailing list for other than what it was
intended, but I think you are best qualified to answer my question.
Is it true that the state of the art in pausing garbage collection
algorithms is the one by Douglas Clark, "An Efficient List-Moving
Algorithm Using Constant Workspace", in CACM, June 1976, Vol. 19, No.
6, pp. 352-5? I know that T uses this algorithm.
John
∂18-Aug-87 0759 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Pausing garbage collection
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 07:52:45 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 18 Aug 87 10:50:36 EDT
Date: Tue, 18 Aug 87 10:50:12 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Pausing garbage collection
To: ramsdell%linus@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sat 15 Aug 87 20:37:59 EDT from ramsdell%linus at mitre-bedford.ARPA
Message-ID: <243369.870818.JAR@AI.AI.MIT.EDU>
The main reason T uses Clark's GC is to linearize lists and thereby
reduce paging, presumably. (Also because we had just spoken to Clark
before we wrote it.) I'm not sure it's otherwise a win; I think it may
inspect objects objects fewer times, but the constant factor might be
bad because of the way it represents its stack -- several memory
references are required to chase forwarding pointers and get the next
object to inspect. The usual scan/free pointer copying GC (I forget
what it's called) is certainly simpler and probably just as good,
especially if you have lots of physical memory. It would be nice to see
some experiments comparing the two, however.
∂19-Aug-87 1233 @MC.LCS.MIT.EDU:DOMAHONY%IRLEARN.BITNET@MITVMA.MIT.EDU Scheme Instructors Guide
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 87 12:33:23 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 19 Aug 87 14:17:34 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/19/87 at
13:34:13 EDT
Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with
BSMTP id
1255; Wed, 19 Aug 87 13:34:09 EDT
Received: by IRLEARN (Mailer X1.24) id 8040; Wed, 19 Aug 87 17:37:25 GMT
Date: Wed, 19 Aug 87 17:34:50 GMT
From: Donal O'Mahony
<DOMAHONY%IRLEARN.BITNET@MITVMA.MIT.EDU>
Subject: Scheme Instructors Guide
To: SCHEME@MC.LCS.MIT.EDU
I intend to teach a course next year based on the Structure and Interpretation
of Computer Programs Book. In the stuff that came with C-Scheme Release 4,
a mention was made of an "Instructors Guide" to accompany the book.
Does anybody know where I can order a copy?
Donal O'Mahony
Computer Science Dept,
Trinity College,
Dublin,
Ireland.
∂20-Aug-87 1019 @MC.LCS.MIT.EDU:KURT%sungod.nsc.syr.edu@amax.npac.syr.edu C Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 87 10:19:44 PDT
Received: from amax.npac.syr.edu (TCP 20071400404) by MC.LCS.MIT.EDU 20 Aug 87 12:49:19 EDT
Received: from sungod.nsc.syr.edu by amax.npac.syr.edu id aa03736;
20 Aug 87 12:47 EDT
Date: Thu, 20 Aug 87 12:16 EDT
From: Kurt Swanson <KURT%sungod.nsc.syr.edu@amax.npac.syr.edu>
Subject: C Scheme
To: scheme@mc.lcs.mit.edu
X-VMS-To: IN%"scheme@mc.lcs.mit.edu"
I'm looking for C Scheme source for both VMS and UNIX. Is there
anyone on bitnet who could possibly send/file them to me? I also have FTP
access to Internet, but my attempts to get the source have failed.
Kurt Swanson
∂22-Aug-87 2122 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme tutorial
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 87 21:21:52 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Aug 87 00:18:18 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA04673; Sat, 22 Aug 87 20:52:02 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Aug 87 01:44:56 GMT
From: xanth!kahn@mcnc.org (Gary I Kahn)
Organization: Old Dominion University, Norfolk Va.
Subject: Scheme tutorial
Message-Id: <2229@xanth.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I'm new to Scheme, but have limited experience with LISP. I bought PC Scheme,
but the manual is not a Scheme tutorial. TI's manual mentions the book by
Abelson, Sussman, and Sussman (Structure and Implementation of Computer
Programs) as a good book for learning Scheme. I'm ready to order the book
if it's good for learning Scheme. Does anyone out there have anything to
say about this book, or any other Scheme books? I'm particularly
interested in the features of Scheme which are different from LISP, such as
engines, closures, and it's treatment of everything as first-class objects.
Thanks in advance.
Gary I. Kahn
kahn@xanth.odu.edu
∂27-Aug-87 0956 @MC.LCS.MIT.EDU:JELROBN%YALEVM.BITNET@MITVMA.MIT.EDU Please remove me from the mailing list.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 87 09:56:48 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Aug 87 12:53:20 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/27/87 at
12:52:33 EDT
Received: from YALEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with
BSMTP id
3700; Thu, 27 Aug 87 12:52:29 EDT
Received: by YALEVM (Mailer X1.24) id 0211; Thu, 27 Aug 87 12:42:31 EST
Date: Thu, 27 Aug 87 12:42 EST
From: JELROBN%YALEVM.BITNET@MITVMA.MIT.EDU
Subject: Please remove me from the mailing list.
To: SCHEME@MC.LCS.MIT.EDU
Please remove me from this mailing list. Thanks.
∂27-Aug-87 2006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On-line Documentation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 87 20:06:12 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Aug 87 22:51:29 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA15025; Thu, 27 Aug 87 17:19:59 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 27 Aug 87 13:33:11 GMT
From: rich@eddie.mit.edu (Richard Caloggero)
Organization: MIT EE/CS Computer Facility, Cambridge, MA
Subject: On-line Documentation
Message-Id: <6672@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi there...
Can anyone email, or point me to any *on-line* documentation/papers on the design and implementation
of CSCHEME and/or T (Yale's production SCHEME interpeter/compiler)?
Thanx in advance!
-- Rich
∂28-Aug-87 0533 @MC.LCS.MIT.EDU:DEMOL%NUSVM.BITNET@MITVMA.MIT.EDU info file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 05:33:22 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 28 Aug 87 08:06:28 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 08/28/87 at
08:05:21 EDT
Received: from NUSVM.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with BSMTP
id
6459; Fri, 28 Aug 87 08:05:17 EDT
Received: by NUSVM (Mailer X1.23b) id 3396; Fri, 28 Aug 87 20:04:14 SST
Date: Fri, 28 Aug 87 20:04:00 SST
From: fung-chai lim <DEMOL%NUSVM.BITNET@MITVMA.MIT.EDU>
Subject: info file
To: SCHEME@MC.LCS.MIT.EDU
info file
∂28-Aug-87 1102 @MC.LCS.MIT.EDU:wtm@buengc.bu.edu Please remove me from the mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 11:02:41 PDT
Received: from bu-cs.BU.EDU (TCP 20061201001) by MC.LCS.MIT.EDU 28 Aug 87 13:06:45 EDT
Received: from buengc (BUENGC.BU.EDU) by bu-cs.BU.EDU (3.2/4.7)
id AA25423; Fri, 28 Aug 87 13:04:34 EDT
Return-Path: <wtm@buengc.bu.edu>
Received: by buengc (4.12/4.7)
id AA05619; Fri, 28 Aug 87 13:00:34 edt
Date: Fri, 28 Aug 87 13:00:34 edt
From: wtm@buengc.bu.edu (W. Thomas Meier)
Message-Id: <8708281700.AA05619@buengc>
To: scheme@mc.lcs.mit.edu
Subject: Please remove me from the mailing list
Please remove me from this mailing list, as I am reading it from another
source.
+Tom Meier
∂01-Sep-87 1825 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu getting scheme up on a 3B1
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Sep 87 18:25:00 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 Sep 87 21:20:05 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA03777; Tue, 1 Sep 87 17:47:18 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 87 23:23:17 GMT
From: super.upenn.edu!linc.cis.upenn.edu!brant@RUTGERS.EDU (Brant Cheikes)
Organization: University of Pennsylvania
Subject: getting scheme up on a 3B1
Message-Id: <1914@super.upenn.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I hope this is the right place to post this... I'm trying to get
C-Scheme running on an AT&T Unix PC (approx Unix SV.2). First Q:
what's the latest C-Scheme version and where is it available from
(FTP preferred)? (want to make sure I'm working with the latest
version).
2nd Q: on what basis does one define STACK, HEAP, and CONSTANT size
in config.h? When I use the defaults and try to run scheme, I get
a "Not enough memory for this configuration." message, and scheme
halts. If I try "scheme -heap 75 -stack 75", it comes up ok. But
I had to tweak the numbers to get it to work-- isn't there a more
principled approach?
Last Q: the runtime/ and sf/ areas have .scm, .psb, and .bin files.
I see that one can convert psb/bin easily, but is there some way
to generate psb or bin files from scm files?
ANY assistance would be appreciated! Thanks,
Brant
-----------------------------------------------------------------------------
Brant Cheikes University of Pennsylvania
ARPA: brant@linc.cis.upenn.edu Computer and Information Science
=============================================================================
∂02-Sep-87 2333 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Looking for Scheme implementation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87 23:33:43 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 3 Sep 87 02:10:52 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA03079; Wed, 2 Sep 87 22:40:04 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Sep 87 20:20:46 GMT
From: pollux.usc.edu!pgarg@OBERON.USC.EDU (Pankaj K. Garg)
Organization: University of Southern California, Los Angeles
Subject: Looking for Scheme implementation
Message-Id: <4297@oberon.USC.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can someone please point me to an implementation of Scheme, preferably
in Common Lisp?
Thanx...
...pankaj
US Mail: Computer Science Department
University of Southern California
Los Angeles, CA 90089-0782
Phone: (213)743-7995
E-mail: garg@cse.usc.edu
∂03-Sep-87 0013 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Thanks for comments about S&ICP book
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 00:13:31 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 3 Sep 87 02:11:13 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA03339; Wed, 2 Sep 87 22:53:05 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Sep 87 01:16:47 GMT
From: xanth!kahn@mcnc.org (Gary I Kahn)
Organization: Old Dominion University, Norfolk Va.
Subject: Thanks for comments about S&ICP book
Message-Id: <2347@xanth.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Thank you for the information about the various Scheme texts and tutorials.
I tried to mail individual notes, but several got returned because I don't
understand the address system well enough.
Gary I. Kahn
kahn@odu.edu
∂03-Sep-87 0409 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 04:09:15 PDT
Received: from bu-cs.BU.EDU (TCP 20061201001) by MC.LCS.MIT.EDU 3 Sep 87 07:06:52 EDT
Received: from bucsf (128.197.2.9) by bu-cs.BU.EDU (3.2/4.7)
id AA04585; Thu, 3 Sep 87 07:04:41 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA19134; Thu, 3 Sep 87 07:04:48 edt
Date: Thu, 3 Sep 87 07:04:48 edt
From: gjc@bucsf.bu.edu (George J. Carrette)
Message-Id: <8709031104.AA19134@bucsf>
To: scheme@mc.lcs.mit.edu
Whats the cheapest way to get S&ICP? The bookstores seem to have it
for around forty clams.
∂03-Sep-87 0623 @MC.LCS.MIT.EDU:alpert@bu-cs.bu.edu Please remove this address from the mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 06:19:32 PDT
Received: from bu-cs.BU.EDU (TCP 20061201001) by MC.LCS.MIT.EDU 3 Sep 87 09:16:58 EDT
Received: from bucsd.bu.edu by bu-cs.BU.EDU (3.2/4.7)
id AA05932; Thu, 3 Sep 87 09:14:58 EDT
Return-Path: <alpert@bu-cs.bu.edu>
Received: by bucsd.bu.edu (5.31/4.7)
id AA24268; Thu, 3 Sep 87 09:16:04 EDT
Date: Thu, 3 Sep 87 09:16:04 EDT
From: alpert@bu-cs.bu.edu
Message-Id: <8709031316.AA24268@bucsd.bu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Please remove this address from the mailing list
Thank you
∂03-Sep-87 0730 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Looking for Scheme implementation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 07:30:30 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Sep 87 10:13:28 EDT
Date: Thu, 3 Sep 87 10:14:48 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Looking for Scheme implementation
To: pollux.usc.edu!pgarg@OBERON.USC.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 2 Sep 87 20:20:46 GMT from pollux.usc.edu!pgarg at OBERON.USC.EDU (Pankaj K. Garg)
Message-ID: <249725.870903.JAR@AI.AI.MIT.EDU>
I have an ugly and incomplete, but effective, scheme implementation
as a bunch of Common Lisp macros. If you can't FTP it I'll mail it
to you. The files are MC.LCS.MIT.EDU: JAR; PSEUDO > and PSEUDO DOC.
∂03-Sep-87 1147 @MC.LCS.MIT.EDU:ab@bu-cs.bu.edu Please remove my address from the mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 11:47:42 PDT
Received: from bu-cs.BU.EDU (TCP 20061201001) by MC.LCS.MIT.EDU 3 Sep 87 14:15:30 EDT
Received: from bucsd.bu.edu by bu-cs.BU.EDU (3.2/4.7)
id AA19121; Thu, 3 Sep 87 14:11:21 EDT
Return-Path: <ab@bu-cs.bu.edu>
Received: by bucsd.bu.edu (5.31/4.7)
id AA06293; Thu, 3 Sep 87 14:12:26 EDT
Date: Thu, 3 Sep 87 14:12:26 EDT
From: ab@bu-cs.bu.edu
Message-Id: <8709031812.AA06293@bucsd.bu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Please remove my address from the mailing list
Thanks you.
∂08-Sep-87 0845 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Preemptive garbage collection
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 87 08:45:23 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 8 Sep 87 11:31:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA24995; Tue, 8 Sep 87 09:36:14 EDT
Posted-Date: Tue, 8 Sep 87 07:54:10 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA13386; Tue, 8 Sep 87 07:54:10 EDT
Date: Tue, 8 Sep 87 07:54:10 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8709081154.AA13386@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Cc: ramsdell%linus@mitre-bedford.ARPA
In-Reply-To: ramsdell@linus's message of Sat, 15 Aug 87 20:37:59 EDT <8708160037.AA07174@darwin.sun.uucp>
Subject: Preemptive garbage collection
To answer my own question, the state of the art in preemptive garbage
collection algorithms seems to be the one by David Ungar, "Generation
Scavenging: A Non-disruptive High Performance Storage Reclamation
Algorithm" in Proc. ACM SIGSOFT/SIGPLAN SE Symp. Practical Software
Development Environments, Pittsburg, PA, April 1984, pp. 157-167. I
say this because at least Franz Inc is going with this garbage
collector for its Sun implementation of Common Lisp and so are the
SmallTalk people. Are there any Scheme implementations going with
this garbage collector?
John
PS The last note used the confusing term "pausing GC" instead of
preemptive GC.
∂09-Sep-87 2235 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message, ignore
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 87 22:35:29 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Sep 87 22:38:24 EDT
Date: Wed, 9 Sep 87 20:00:53 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: test message, ignore
To: scheme@MC.LCS.MIT.EDU
Reply-to: Scheme-Request@MC.LCS.MIT.EDU
Message-ID: <252467.870909.JAR@AI.AI.MIT.EDU>
[I'm ruthlessly weeding out bad addresses on the list yet again.]
∂10-Sep-87 0549 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On-line documentation on T and/or CSCHEME.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87 05:49:39 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Sep 87 08:37:01 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA00901; Thu, 10 Sep 87 05:32:29 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Sep 87 11:26:33 GMT
From: rich@EDDIE.MIT.EDU (Richard Caloggero)
Organization: MIT EE/CS Computer Facility, Cambridge, MA
Subject: On-line documentation on T and/or CSCHEME.
Message-Id: <6816@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can anyone out there point me to on-line papers or other documents
on the design and implementation of T or CSCHEME?
Thanx.
-- Rich
∂10-Sep-87 1444 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: Cscheme5 (In English)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87 14:43:51 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Sep 87 14:09:33 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA03724; Thu, 10 Sep 87 09:03:18 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 Sep 87 11:23:30 GMT
From: mcvax!kddlab!titcca!secisl!tau@seismo.css.gov ("Yatchan" TAUCHI)
Organization: SECOM Intelligent Systems Laboratory, JAPAN
Subject: Wanted: Cscheme5 (In English)
Message-Id: <1126@secisl.seclab.JUNET>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I got SCOOPS (= Scheme + Object Oriented Programming) which is written
in Cscheme 5 via Network News. Unfortunately I have only old scheme of
Revised Revised Scheme report. I heard it could be got from MIT, but
not sure. If you can have any information of getting Cscheme or you
can distribute it, please send me a Email.
---
Yasuyuki Tauchi
Intelligent Systems Laboratory
SECOM Co Ltd
6-11-23 Shimo-Renjaku
Mitaka, Tokyo 181
JAPAN
JUNET: tau%seclab.junet@kddlabs.jp
UUCP: seismo!kddlab!titcca!secisl!tau
PHONE: 0422-46-5600[japan]
FAX: 0422-48-6841[japan]
∂14-Sep-87 1121 @MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU subscription
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 87 11:19:25 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Sep 87 11:37:03 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/14/87 at
11:33:56 EDT
Received: from BRANDEIS.BITNET (ADLER1) by MITVMA.MIT.EDU (Mailer
X1.25) with
BSMTP id 1897; Mon, 14 Sep 87 11:33:36 EDT
Date: Sun, 13 Sep 87 03:40 EDT
From: <ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU>
Subject: subscription
To: scheme@mc.lcs.mit.edu
X-Original-To: scheme@mc.lcs.mit.edu, ADLER1
I sent you a message a while ago requesting that I be added to your mailing
list. If you have not yet done so, please add me to your mailing list.
Thank you.
Sincerely,
ADLER1@BRANDEIS.BITNET
∂15-Sep-87 0209 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: SCHEME/COMMON-LISP compiler documentation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 02:09:42 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Sep 87 05:09:14 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA16117; Tue, 15 Sep 87 01:46:38 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 14 Sep 87 14:43:54 GMT
From: mcvax!dutrun!dutesta!brouw@seismo.css.gov (Gerard Brouwer)
Organization: Delft University of Technology, Faculty of Electrical Engineering.
Subject: Wanted: SCHEME/COMMON-LISP compiler documentation
Message-Id: <976@dutesta.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
At the Delft University of Technology we are developing an architecture
for a LISP-computer based on Eu-LISP level 0, which is related to
SCHEME. Part of the project is building a compiler for this new
architecture. To gain experience in the usage of SCHEME-based compilers
we will be studying several already existing compilers.
At this moment we are looking for documentation of the following
SCHEME- and COMMON-LISP-implementations:
- T3 (The ORBIT-compiler)
- MIT Scheme
- Scheme48
- Scheme-84
- Kyoto Common Lisp (KCL)
Our special interest is in the compilation techniques used by the various
implementations, such as used intermediate languages, code-generating,
optimization at various levels.
If you have any information and/or documentation available or know where
we can get the information/documentation, please contact us.
Thanks for your cooperation.
Gerard Brouwer UUCP: MCVAX!dutrun!dutesta!brouw
Delft University of Technology
Department of Electrical Engeneering
Section Computer Architecture
P.O. Box 5031
2600 AG Delft, The Netherlands
Phone: 015-785021
015-783644
∂15-Sep-87 2042 @MC.LCS.MIT.EDU:munnari!cidam.oz.au!mg@uunet.UU.NET prolog in scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 87 20:42:04 PDT
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 15 Sep 87 22:58:05 EDT
Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA23921; Tue, 15 Sep 87 22:46:45 EDT
Message-Id: <8709160246.AA23921@uunet.UU.NET>
Received: from cidam (via goanna) by munnari.oz with SunIII (5.5)
id AA19656; Wed, 16 Sep 87 12:18:22 EST
Received: by cidam.rmit.oz (4.3+RMIT/4.7)
id AA18688; Wed, 16 Sep 87 08:13:02 EST
Date: Wed, 16 Sep 87 08:13:02 EST
From: munnari!cidam.rmit.oz!mg@uunet.UU.NET (Mike A. Gigante)
To: scheme@mc.lcs.mit.edu
Subject: prolog in scheme
Does anyone have such a beast (that you are willing to share)? I know
you can use the query system (as in SICP) in a similar manner to prolog
but is not really enough. It would also require a *lot* of efficiency
hacking for any serious use...
Any dialect of scheme would be ok.
Mike
∂21-Sep-87 1400 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Wanted: Cscheme5 (In English)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:00:22 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 21 Sep 87 13:36:47 EDT
Received: by GENEVA.AI.MIT.EDU; Mon, 21 Sep 87 13:26:38 edt
Date: Mon, 21 Sep 87 13:26:38 edt
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8709211726.AA27744@geneva>
To: mcvax!kddlab!titcca!secisl!tau@seismo.css.gov (TAUCHI)
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: ("Yatchan" TAUCHI's message of 9 Sep 87 11:23:30 GMT <1126@secisl.seclab.JUNET>
Subject: Wanted: Cscheme5 (In English)
Reply-To: jinx@zurich.ai.mit.edu
I got SCOOPS (= Scheme + Object Oriented Programming) which is written
in Cscheme 5 via Network News. Unfortunately I have only old scheme of
Revised Revised Scheme report. I heard it could be got from MIT, but
not sure. If you can have any information of getting Cscheme or you
can distribute it, please send me a Email.
There are two main ways of obtaining CScheme
Arpanet/Internet FTP:
host prep.ai.mit.edu contains a tar file (and a compressed tar file)
of the distribution directory. You can log in as scheme, password
scheme. The files are /scheme/dist.tar and /scheme/dist.tar.Z
Tape:
We'll send you a tar tape if you send a check for US $200 to
Scheme Distribution
co Prof. Hal Abelson
545 Technology Sq.
Cambridge MA 02139
USA
∂22-Sep-87 0121 @MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU scoop wanted
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 01:20:53 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 22 Sep 87 03:51:40 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/22/87 at
03:47:22 EDT
Received: from BRANDEIS.BITNET (ADLER1) by MITVMA.MIT.EDU (Mailer
X1.25) with
BSMTP id 5870; Tue, 22 Sep 87 03:47:19 EDT
Date: Tue, 22 Sep 87 03:45 EDT
From: <ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU>
Subject: scoop wanted
To: scheme@mc.lcs.mit.edu
X-Original-To: scheme@mc.lcs.mit.edu, ADLER1
From: BINAH::ADLER1 21-SEP-1987 22:43
To: Orig_To! INFO-SCHEME@OZ.AI.MIT.EDU, ADLER1
Subj: SCOOPS WANTED
I'm new on this network. One of the first messages I received suggests that
someone recently distributed a version of SCOOP (= SCheme + Object Oriented
Programming) on the network. I'd be very interested in obtaining a copy.
I believe that the version in question was written on top of CScheme which
I have no difficulty obtaining via ftp.
If you can send me a copy of SCOOP at the following address, I would
appreciate it: ghoti@cauchy.mit.edu
Or, if you can tell me where I can ftp it and how, I'll more simply do that
and avoid possible corruption of the file by the mails. Thanks.
ghoti@cauchy.mit.edu
∂24-Sep-87 2114 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu using editors
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 87 21:14:27 PDT
Received: from clover.ucdavis.edu (TCP 20036034401) by MC.LCS.MIT.EDU 24 Sep 87 22:46:36 EDT
Received: by clover.ucdavis.edu (5.51/4.7)
id AA29007; Thu, 24 Sep 87 14:09:43 PDT
Received: from localhost.ucdavis.edu.ARPA by iris (1.2/3.14)
id AA00272; Thu, 24 Sep 87 14:10:39 pdt
Message-Id: <8709242110.AA00272@iris>
To: scheme@mc.lcs.mit.edu
Subject: using editors
Date: Thu, 24 Sep 87 14:10:37 PDT
From: windley@iris.ucdavis.edu
I'm new to scheme. Is there a way to call an editor from within
scheme (in particular the student band) like vi to edit programs for
loading and execution?
Phil Windley
Robotics Research Lab
University of California, Davis
∂25-Sep-87 2254 @MC.LCS.MIT.EDU,@RELAY.CS.NET:shneider@cui.unige.chunet Any Scheme for Atari and/or Amiga ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 87 22:54:22 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Sep 87 01:25:49 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa12673; 25 Sep 87 11:53 EDT
Received: from switzerland by RELAY.CS.NET id ab17614; 25 Sep 87 11:40 EDT
Received: from ean by SWITZERLAND.CSNET id a023748; 25 Sep 87 17:31 MET DST
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
MMDF-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <309:shneider@cui.unige.chunet>
Subject: Any Scheme for Atari and/or Amiga ?
Is there any Scheme available for the Atari or the Amiga ?
...... or does somebody plan an implementation?
(I am asking this every 6 month, so far these companies don't seem to worry
about lisp either)
-------
Daniel K.Schneider, ISSCO, University of Geneva, 54 route des Acacias,
1227 Carouge (Switzerland), Tel. (..41) (22) 20 93 33 ext. 2116
--> to EAN/X400/MHS (on Unix, (preferable :]) :
EAN/X400:shneider@cui.unige.ch | if reply does
ARPA: shneider%cui.unige.ch@csnet-relay.arpa | not work,
CSnet: shneider%cui.unige.ch@csnet-relay.csnet | keep trying:
(or:....%relay.cs.net@relay.cs.net) | mailers are
JANET: shneider%cui.unige.ch@cs.ucl.ac.uk | *great* fun!
uucp: mcvax!cernvax!cui!shneider | ;-( |+{ :=[
(note: "ch" used to be called "chunet")
--> to BITNET (on VMS, the easy solution):
BITNET: SCHNEIDE@CGEUGE51 ARPA: SCHNEIDE%CGEUGE51.BITNET@WISCVM
∂28-Sep-87 0922 @MC.LCS.MIT.EDU:EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU Scheme on Atari
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 09:22:42 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 28 Sep 87 12:14:57 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/28/87 at
12:14:20 EDT
Received: from HNYKUN52.BITNET (EDH) by MITVMA.MIT.EDU (Mailer X1.25)
with
BSMTP id 7044; Mon, 28 Sep 87 12:14:17 EDT
Date: Mon, 28 Sep 87 15:13 N
From: <EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU>
Subject: Scheme on Atari
To: SCHEME@MC.LCS.MIT.EDU
X-Original-To: SCHEME@MC.LCS.MIT.EDU, EDH
To: scheme@mc.lcs.mit.edu
Cc:
Subject: Scheme on Atari
From: Edward Hoenkamp <EDH at HNYKUN52.BITNET>
(Arpa: EDH%HNYKUN52.BITNET@WISCVM.WISC.EDU)
Date: Mon Sep 28 15:11:39 1987
---
Since there have been several requests for Scheme from people
possessing an Atari, here is a possible way out.
There are Mac emulators on the Atari. The one I am familiar with,
(the German 'Aladin') I essentially use as an application program
to run MacScheme. It does this wonderfully well, i.e. the
programs I tried (e.g. prolog and Erathosthenes' Sieve from THE book)
run somewhat FASTER emulated, plus you can use the bigger screen,
plus it supports almost 2 megabyte (e.g. for the heap).
E.
(If giving this information is illegal, realize that this text was
generated randomly).
∂28-Sep-87 1109 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Any Scheme for Atari and/or Amiga ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 87 11:09:37 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 28 Sep 87 14:03:59 EDT
Received: by GENEVA.AI.MIT.EDU; Mon, 28 Sep 87 14:08:10 edt
Date: Mon, 28 Sep 87 14:08:10 edt
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8709281808.AA02560@geneva>
To: shneider%cui.unige.chunet@RELAY.CS.NET
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: "Daniel K. Schneider"'s message of Sat, 26 Sep 87 02:32:55 edt <309:shneider@cui.unige.chunet>
Subject: Any Scheme for Atari and/or Amiga ?
Reply-To: jinx@zurich.ai.mit.edu
Is there any Scheme available for the Atari or the Amiga ?
...... or does somebody plan an implementation?
I've been told that MIT CScheme runs on the Amiga. MIT CScheme is
relatively portable, so you should be able to bring it up on any
machine with C and a reasonable amount of memory.
∂30-Sep-87 0121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted Scoops for MacSheme (or help in porting)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 87 01:21:04 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 30 Sep 87 04:18:17 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA11968; Wed, 30 Sep 87 01:16:50 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 30 Sep 87 04:10:56 GMT
From: sunybcs!boulder!halls@rutgers.edu (Andy Halls)
Organization: University of Colorado, Boulder
Subject: Wanted Scoops for MacSheme (or help in porting)
Message-Id: <2388@sigi.Colorado.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've been using MacScheme for several months now and I love it. I want to
start using the Scoops system with it. I got a copy of Scoops provided by
TI. However there are several problems that prevent it from loading into
my system. The two major ones are MacSheme has no syntax function or
define-intergrable (or something like that) I need some clues on how to
translate these guys, or better yet has someone already done it, and are
you willing to mail me a copy?
Andy Halls
mail: 2646 Stuart Street, Denver, CO 80212
phone: home (303) 455-9139 messages (303) 692-5094
uucp: {cires | hao | nbires}boulder!halls
internet: halls@boulder.colorado.edu
∂02-Oct-87 0818 @MC.LCS.MIT.EDU:STCS8004%IRUCCVAX.BITNET@MITVMA.MIT.EDU FreeWare Scheme - IBM PS/2 or AT
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 87 08:18:16 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 2 Oct 87 11:15:26 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 10/02/87 at
11:14:13 EDT
Received: from IRUCCIBM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id
5720; Fri, 02 Oct 87 11:14:09 EDT
Received: from IRUCCVAX.BITNET by IRUCCIBM.BITNET (Mailer X1.24) with
BSMTP id
2685; Fri, 02 Oct 87 16:01:54 IST
Date: Fri, 2 Oct 87 16:03 GMT
From: STCS8004%IRUCCVAX.BITNET@MITVMA.MIT.EDU
Subject: FreeWare Scheme - IBM PS/2 or AT
To: SCHEME@MC.LCS.MIT.EDU
X-VMS-To: SCHEME,STCS8004
I wish to teach Scheme to 2nd and 3rd Honours CS students and
would like to distribute a Shareware/Freeware version to them for
use on IBM PS/2 1mB+HD and Unisys Micro IT 640kB+HD. Full Scheme
is not essential - a viable subset is quite sufficient. I have a
small subset implemented as an interpreter running under PCLisp
(subset Franz) broadly modelled on Abelson and Sussman, but this is
far too slow and lacks diagnostics at the Scheme level. Information
on what is available free would be most welcome. G. Oulsnam.
∂03-Oct-87 0411 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ibm-pc compatible CScheme compiler
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 87 04:11:29 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 3 Oct 87 07:06:44 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA06342; Sat, 3 Oct 87 03:51:10 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Oct 87 07:19:42 GMT
From: sunybcs!uggorman@rutgers.edu (Jeffrey Gorman)
Organization: SUNY/Buffalo Computer Science
Subject: ibm-pc compatible CScheme compiler
Message-Id: <5637@sunybcs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi, does anyone have a CScheme compiler for the Tandy 1000? I could really use
one
Jeff
∂03-Oct-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme needed for the VAX-780
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 87 23:09:34 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Oct 87 02:06:52 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA19954; Sat, 3 Oct 87 22:54:34 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Oct 87 01:12:17 GMT
From: gumby!quale@rsch.wisc.edu (Douglas Quale)
Organization: U of Wisconsin CS Dept
Subject: Scheme needed for the VAX-780
Message-Id: <1067@gumby.wisc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Help! Desperately seeking Scheme!
I'm an undergrad at the UW-Madison, and no one here groks lisp.
The only lisp available at Madison is Franz, and frankly I'd rather have an
appendectomy. I would like to have a lexically-scoped lisp which has a
consistent treatment of procedures as objects, i.e. Scheme.
My first exposure to lisp was in an MIT AI Memo by Guy L. Steele and Gerry
Sussman, "The Art of the Interpreter, or the Modularity Complex Parts 0, 1,
2 and 3." I used to program in Pascal, but once I read Abelson and Sussman's
"The Structure and Interpretation of Computer Programs," I knew I was hooked.
(I have the Revised**3 Report on Scheme and Slade's book on the Yale T dialect
of Scheme.)
I think there was a posting (by Gerry Sussman himself?) explaining how to
obtain MIT's CScheme, but I missed it.
If anyone has any info on how I could get a Scheme system for the VAX under
UNIX, I would literally be eternally grateful. I try to watch this newsgroup
or you can e-mail me, quale@gumby.wis.edu .
Tx 1E+06 ...
D. Quale
P.S. If anyone could convince Dr. Steele or Dr. Sussman to write the promised
sequel to "The Art of the Interpreter," I'd love to see it.
∂04-Oct-87 1113 @MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU R↑3RS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 87 11:13:34 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 4 Oct 87 14:07:48 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 10/04/87 at
14:06:30 EDT
Received: from SUNRISE.BITNET (KSWANSON) by MITVMA.MIT.EDU (Mailer
X1.25) with
BSMTP id 0627; Sun, 04 Oct 87 14:06:27 EDT
Date: Sun, 4 Oct 87 13:50 EST
From: <KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU>
Subject: R↑3RS
To: scheme@mc.lcs.mit.edu
X-Original-To: scheme@mc.lcs.mit.edu
How can I get a copy of the R↑3RS definition of Scheme?
∂05-Oct-87 0936 @MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA Tex and Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 09:36:20 PDT
Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 5 Oct 87 12:32:39 EDT
Date: Mon, 5 Oct 87 10:30:48 MDT
From: Raul Machuca <RMACHUCA@SIMTEL20.ARPA>
Subject: Tex and Scheme
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12340084883.9.RMACHUCA@SIMTEL20.ARPA>
Does anyone know of some Tex ,Latex type program that can
be used to produce formatted and documented Scheme code.
-------
∂05-Oct-87 1941 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU R↑3RS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 19:41:02 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Oct 87 22:09:36 EDT
Date: Mon, 5 Oct 87 22:16:55 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: R↑3RS
To: KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 4 Oct 87 13:50 EST from <KSWANSON%SUNRISE.BITNET at MITVMA.MIT.EDU>
Message-ID: <265032.871005.JAR@AI.AI.MIT.EDU>
Date: Sun, 4 Oct 87 13:50 EST
From: <KSWANSON%SUNRISE.BITNET at MITVMA.MIT.EDU>
To: scheme at mc.lcs.mit.edu
Re: R↑3RS
How can I get a copy of the R↑3RS definition of Scheme?
It's in SIGPLAN Notices 21(12), December 1986. It can also be ordered
from:
Elizabeth Heepe
Publications, Room NE43-818
MIT Artifical Intelligence Laboratory
545 Technology Square
Cambridge MA 02139
Ask for MIT AI Memo 848a, and enclose a check for $6.00 per copy (U.S.
funds) payable to the MIT Artificial Intelligence Laboratory.
It may also be available from the Indiana University CS Department, but
I don't have information on that.
∂06-Oct-87 0753 @MC.LCS.MIT.EDU:U04Z%CBEBDA3T.BITNET@MITVMA.MIT.EDU Re: TeX and Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 87 07:53:38 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 6 Oct 87 10:49:14 EDT
Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 10/06/87 at
10:07:04 EDT
Received: from CEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
id
6697; Tue, 06 Oct 87 10:07:01 EDT
Received: from CBEBDA3T.BITNET (U04Z) by CEARN.BITNET (Mailer X1.25)
with BSMTP
id 5122; Tue, 06 Oct 87 08:36:37 GVA
Date: 06 OCT 87 08:25 GMT
To: scheme@mc.lcs.mit.edu ,
rmachuca@simtel.arpa
From: U04Z%CBEBDA3T.BITNET@MITVMA.MIT.EDU (Igor Metz, Dept. of CS,
CH-Bern)
Subject: Re: TeX and Scheme
> Does anyone know of some Tex ,Latex type program that can
> be used to produce formatted and documented Scheme code.
If you have UNIX TeX try tgrind !
Igor
∂06-Oct-87 1808 @MC.LCS.MIT.EDU:RKIRCHNE%carleton.edu@RELAY.CS.NET R↑3RS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 87 18:08:23 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Oct 87 20:56:22 EDT
Received: from [128.89.1.80] by RELAY.CS.NET id ab01321; 6 Oct 87 20:24 EDT
Received: from carleton.edu by RELAY.CS.NET id ac11776; 6 Oct 87 20:19 EDT
Date: Tue, 6 Oct 87 05:59 CST
From: RKIRCHNE%carleton.edu@RELAY.CS.NET
Subject: R↑3RS
To: scheme@mc.lcs.mit.edu
X-VMS-To: IN%"scheme@mc.lcs.mit.edu"
R↑3RS is also included with the documentation for TI's PC Scheme version 3.
I just upgraded to it. Also included as one of several sample files is
Kent Dybvig's extend-syntax, which is described in his book and included
as a standard feature in Chez Scheme v 2. extend-syntax is incredibly
powerful for defining special forms -- all one has to do is describe
patterns.
Someone was looking for Scheme for a VAX. I highly recommend Chez Scheme
by Kent Dybvig (dybvig@indiana.csnet, I think) distributed by Cadence
Associates (or something like that). Academic pricing for VMS, other
versions is very reasonable. Someone with accurate info should respond.
Someone else was looking for a Scheme compiler for a Tandy 1000. I should
think TI's PC Scheme would work. It is really excellent.
PC Scheme v 3.0 uses #T and #F instead of #!TRUE and #!FALSE, the same as
Chez Scheme. That is much cleaner.
Quasiquote expressions can be nested, and UNQUOTE, UNQUOTE-SPLICING key
words have been added.
Graphics now supports EGA 640 x 350 resolution. That is the improvement
I was looking for. New graphics functions are GET-PEN-COLOR, GET-PEN-
POSITION, POINT-COLOR, and SET-CLIPPING-RECTANGLE. EGA 640 x 200 is also
supported. Also, GRAPHICS-WINDOW for creating graphics windows is
described in the release notes, but undocumented.
Transcendental functions are computed using a new feature which allows
programs compiled from C or Turbo Pascal to be called from Scheme. An
8087 (80287) is used if present.
READ-LINE now echos to the screen when used to read from the console or
a window.
There are lots of other improvements. There is a one change from conforming
to nonconforming with the Report. The form (DEFINE ( ... ) ...) no
longer expands to a NAMED-LAMBDA. But this can still be forced by setting
PCS-INTEGRATE-DEFINE to ().
Roger Kirchner rkirchne@carleton.edu.csnet
∂07-Oct-87 0031 NET-ORIGIN@MC.LCS.MIT.EDU Re: TeX and Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Oct 87 00:30:58 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 OCT 87 03:28:11 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA28375@EDDIE.MIT.EDU>; Wed, 7 Oct 87 03:24:24 EDT
Received: by xanth.cs.odu.edu (5.51/odu-gateway)
id AA23003; Wed, 7 Oct 87 03:17:07 EDT
To: mail-scheme@xanth.cs.odu.edu
Path: xanth!uucp
From: "Igor Metz, Dept. of CS,"-a news@xanth.cs.odu.edu
Newsgroups: mail.scheme
Subject: Re: TeX and Scheme
Message-Id: <2672@xanth.UUCP>
Date: 7 Oct 87 07:17:03 GMT
Sender: uucp@xanth.cs.odu.edu
Lines: 9
> Does anyone know of some Tex ,Latex type program that can
> be used to produce formatted and documented Scheme code.
If you have UNIX TeX try tgrind !
Igor
∂08-Oct-87 2114 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: R↑3RS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 21:14:31 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 9 Oct 87 00:08:57 EDT
Date: Thu, 8 Oct 87 23:06:36 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: R↑3RS
From: RKIRCHNE%carleton.edu@RELAY.CS.NET
Subject: R↑3RS
To: scheme@mc.lcs.mit.edu
R↑3RS is also included with the documentation for TI's PC Scheme version 3.
I just upgraded to it. Also included as one of several sample files is
Kent Dybvig's extend-syntax, which is described in his book and included
as a standard feature in Chez Scheme v 2. extend-syntax is incredibly
powerful for defining special forms -- all one has to do is describe
patterns.
Actually, extend-syntax is of Eugene Kohlbecker's design, and represents
part of his doctoral research here at Indiana. The implementation may
well be mine, however, as I did give one to TI along with permission to
distribute it.
Someone was looking for Scheme for a VAX. I highly recommend Chez Scheme
by Kent Dybvig (dybvig@indiana.csnet, I think) distributed by Cadence
Associates (or something like that). Academic pricing for VMS, other
versions is very reasonable. Someone with accurate info should respond.
If anyone desires information about Chez Scheme for VAX, Sun, or Apollo
computers, please send me electronic mail and I'll see that you are sent
some information (include your physical mailing address). Or contact:
Cadence Research Systems
620 Park Ridge Road
P.O. Box 5031
Bloomington, IN 47407
Kent
R. Kent Dybvig | arpa: dyb@iuvax.cs.indiana.edu
Computer Science Department | csnet: dyb@indiana
Indiana University | usenet: ...!ihnp4!iuvax!dyb
Bloomington, IN 47405 | phone: 812/335-6486
∂09-Oct-87 1738 @MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu Some corrections
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 17:37:09 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Oct 87 20:34:42 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ad13121; 9 Oct 87 20:05 EDT
Received: from carleton.edu by RELAY.CS.NET id aj02782; 9 Oct 87 20:04 EDT
Date: Fri, 9 Oct 87 05:35 CST
From: RKIRCHNE%carleton.edu@RELAY.CS.NET
Subject: Some corrections
To: scheme@mc.lcs.mit.edu
X-VMS-To: IN%"scheme@mc.lcs.mit.edu"
My note on TI's PC Scheme and Indiana's Chez Scheme had some errors.
1. From jinx@zurich.ai.mit.edu -- PC's Scheme's change with respect
to (define ( ... ) ...) expansion DOES conform to R↑3RS.
2. From Dan Friedman -- Eugene Kohlbecker created the remarkable
extend-syntax. Kent Dybvig implemented a version of it in Chez
Scheme.
3. From AI Magazine, Fall 87 p94 -- It is Cadence Research Systems,
P.O. 5031, Bloomington, Indiana 47402, not Cadence Associates that
distributes Chez Scheme. Sue Rykovich (812)333-9269 handles
marketing.
Version 2.0 runs on: VAX 4.2 BSD Unix, 4.3 BSD Unix, Ultrix and VMS,
Sun-3 SunOS, and Apollo Domain/IX. Educational price is 50% of $1500.
Roger Kirchner
∂13-Oct-87 1006 @MC.LCS.MIT.EDU:esosun!vor!jackson@sdcsvax.ucsd.edu Tao, Sues...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 10:06:50 PDT
Received: from sdcsvax.UCSD.EDU (TCP 3201200003) by MC.LCS.MIT.EDU 13 Oct 87 12:07:42 EDT
Received: by sdcsvax.UCSD.EDU (5.57/5.0)
id AA03158 for scheme@MC.LCS.MIT.EDU; Tue, 13 Oct 87 08:04:22 PST
Received: from vor.esosun.uucp by esosun.uucp (3.2/SMI-3.0DEV3)
id AA08799; Tue, 13 Oct 87 08:45:44 PDT
Received: by vor.esosun.uucp (3.2/SMI-3.0DEV3)
id AA04566; Tue, 13 Oct 87 08:45:43 PDT
Date: Tue, 13 Oct 87 08:45:43 PDT
From: esosun!vor!jackson@sdcsvax.ucsd.edu (Jerry Jackson)
Message-Id: <8710131545.AA04566@vor.esosun.uucp>
To: sdcsvax!mc.lcs.mit.edu!scheme
Subject: Tao, Sues...
Cc: vor!jackson
I recently saw the languages Tao and Sues (strongly related to
scheme, I believe..) mentioned in an article in LISP Pointers.
Can anyone point me to any references?
--Thanks
∂14-Oct-87 1850 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET MultiScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Oct 87 18:50:00 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Oct 87 21:32:04 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ag17856; 14 Oct 87 19:26 EDT
Received: from brandeis by csnet-relay.csnet id am05909; 14 Oct 87 19:23 EDT
Received: by brandeis.ARPA (5.51/4.7)
id AA10286; Wed, 14 Oct 87 16:13:06 EDT
Date: Wed, 14 Oct 87 16:13:06 EDT
From: James Miller <jmiller%brandeis.csnet@RELAY.CS.NET>
To: Scheme%MC.LCS.MIT.EDU@RELAY.CS.NET
Subject: MultiScheme
My dissertation, "MultiScheme: A Parallel Processing System Based on
MIT Scheme," is available from the MIT Lab for Computer Science
publications office (545 Technology Square, Cambridge, MA 02139), as
MIT/LCS/TR-402. It reports on an implementation of Scheme extended to
support the FUTURE construct and speculative computation. It has a
number of examples showing relationships to: embedding logic variables
in Scheme, McCarthy's AMB and fair merge, higher order streams
processing, data-flow parallelism, and so forth.
The current release of MIT CScheme contains a serial processor
implementation of the work reported in the thesis. BBN's Butterfly
Lisp product is based directly on the (truly parallel) implementation.
--Jim Miller
Brandeis University
∂16-Oct-87 0402 @MC.LCS.MIT.EDU,@RELAY.CS.NET:sasha@COLGATE.CSNET visit on 11/9?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87 04:02:35 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Oct 87 06:58:56 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab14385; 16 Oct 87 5:26 EDT
Received: from colgate by csnet-relay.csnet id ae15545; 16 Oct 87 5:24 EDT
Received: by colgate (5.51/)
id AA01195; Thu, 15 Oct 87 14:29:13 EDT
Date: Thu, 15 Oct 87 14:29:13 EDT
From: "A. Nakhimovsky" <sasha%colgate.csnet@RELAY.CS.NET>
To: scheme%mc.lcs.mit.edu@RELAY.CS.NET
Subject: visit on 11/9?
I'm teaching a course based on Abelson & Sussman cum scheme this coming
spring for the first time. I'll be in Cambridge Nov. 9: can I visit,
talk to the instructor, look at your syllabus, assignments etc? What
would be a good time?
A. Nakhimovsky (scnet: sasha@colgate)
∂17-Oct-87 2226 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu CScheme question
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Oct 87 22:26:41 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 17 Oct 87 23:26:29 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA08392; Fri, 16 Oct 87 03:55:47 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 Oct 87 01:36:49 GMT
From: russell!evan@labrea.stanford.edu (Evan Kirshenbaum)
Organization: Center for the Study of Language and Information, Stanford U.
Subject: CScheme question
Message-Id: <430@russell.STANFORD.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I recently started using CScheme, and I have a question about the
efficiency of the compiler. When writing macros, a common idiom I use
is:
`(lambda ,args
(let (,@(and var1
`((,var1 ,(generate-uninterned-symbol))))
,@(and var2
`((,var2 ,(generate-uninterned-symbol))))
...)
...))
where temporary variables are gensymed only if they are needed. If no
variables are needed, what comes out is
(lambda (x y z)
(let ()
...))
Now in any other lisp/scheme the internal let binding would be
discarded. In CScheme, it would seem that the internal environment
would have to be created because of the way define works. I use this
idiom a lot, and wind up with functions that pp as (let () (let ()
...)). My question is: is the compiler smart enough to realize that
no defines occur in the body, and so no environment is needed, or do I
have to make macros condition on the presence/absence of temporary
variables?
---
Evan Kirshenbaum
Stanford University
evan@CSLI.STANFORD.EDU
...!{ucbvax,decvax}!decwrl!glacier!evan
If you think my opinions represent this university,
you haven't been on campus recently!
∂17-Oct-87 2324 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MultiScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Oct 87 23:24:10 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 17 Oct 87 23:28:02 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA23830; Fri, 16 Oct 87 17:42:13 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 16 Oct 87 22:18:43 GMT
From: rich@eddie.mit.edu (Richard Caloggero)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Subject: Re: MultiScheme
Message-Id: <7184@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8710150621.AA02160@ucbvax.Berkeley.EDU> jmiller@brandeis.CSNET (James Miller) writes:
>My dissertation, "MultiScheme: A Parallel Processing System Based on
>MIT Scheme," is available from the MIT Lab for Computer Science
>publications office (545 Technology Square, Cambridge, MA 02139), as
>MIT/LCS/TR-402.
> .
> .
> .
>
>--Jim Miller
>Brandeis University
I am extremely interested in seeing a copy of this report.
The problem is that I am blind, and thus neesome kind of
on-line representation of the text
(alternatively, I guess, I could have it put on tape, but this could take ++forever++)!
Is there some way I could obtain a copy of the document?
I suspect copyrighting problems might get in the way -- don't know much
about the legal stuff ...
Can you, or someone out there help me out?
I alsk posted a general query for some sort of documentation on CSCHEME and/or yales T
implementation details.
Might anyone be able to help me with regards to this?
Thanx ...
∂19-Oct-87 1350 @MC.LCS.MIT.EDU:bartlett@decwrl.dec.com Type inference in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 13:50:08 PDT
Received: from sonora.dec.com (TCP 20013200064) by MC.LCS.MIT.EDU 19 Oct 87 16:41:56 EDT
Received: from saturn.dec.com by sonora.dec.com (5.54.4/4.7.34)
id AA21938; Mon, 19 Oct 87 13:39:57 PDT
Received: by saturn.dec.com (5.54.3/4.7.34)
id AA21594; Mon, 19 Oct 87 13:41:53 PDT
From: bartlett@decwrl.dec.com (Joel Bartlett)
Message-Id: <8710192041.AA21594@saturn.dec.com>
Date: 19 Oct 1987 1341-PDT (Monday)
To: scheme@mc.lcs.mit.edu
Cc: bartlett@decwrl.dec.com
Subject: Type inference in Scheme
I am interested in using type inference to get faster code out of my
Scheme compiler. I'd greatly appreciate pointers to any existing work in
that area. I'll summarize and send out the replies (if any) that I get.
thanks,
Joel
∂20-Oct-87 0023 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Type inference in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87 00:23:43 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 20 Oct 87 03:20:48 EDT
Received: from relay2.cs.net by RELAY.CS.NET id af19942; 20 Oct 87 0:22 EDT
Received: from northeastern.edu by RELAY.CS.NET id ai09803; 20 Oct 87 0:21 EDT
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Mon, 19 Oct 87 22:35 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA01690; Mon, 19 Oct 87 22:05:08 EDT
Date: Mon, 19 Oct 87 22:05:08 EDT
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: bartlett@decwrl.dec.com
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Joel Bartlett's message of 19 Oct 1987 1341-PDT (Monday)
Subject: Type inference in Scheme
From: Joel Bartlett <bartlett@decwrl.dec.com>
Date: 19 Oct 1987 1341-PDT (Monday)
To: scheme@mc.lcs.mit.edu
Cc: bartlett@decwrl.dec.com
Subject: Type inference in Scheme
I am interested in using type inference to get faster code out of my
Scheme compiler. I'd greatly appreciate pointers to any existing work in
that area. I'll summarize and send out the replies (if any) that I get.
thanks,
Joel
You should look at my SPS (Semantic Prototyping System) which includes, among
other things, an ML-style type inference system for a pretty good chunk of
Scheme. This is available for ftp at Indiana (write cth@iucs.cs.indiana.edu
for details), else I can send you a tape. A hardcopy writeup is in the
Proceedings of the 1984 SIGPLAN Compiler Construction Conference. If you send
me your address, I'll send you a copy.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂21-Oct-87 1244 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme84 and SPS ftp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 12:44:03 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 21 Oct 87 15:35:12 EDT
Date: Wed, 21 Oct 87 14:34:15 est
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Cc: mw@iuvax.cs.indiana.edu
Subject: Scheme84 and SPS ftp
Scheme84 and SPS are available on iuvax.cs.indiana.edu via ftp (login:
anonymous, with any password) as /usr/ftp/pub/scheme84 and
/usr/ftp/pub/SPS, respectively.
∂21-Oct-87 1357 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Semantic Prototyping System
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 13:57:43 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Oct 87 16:41:21 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab17462; 21 Oct 87 16:19 EDT
Received: from northeastern.edu by RELAY.CS.NET id ag22181; 21 Oct 87 16:13 EDT
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Wed, 21 Oct 87 13:35 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA10753; Wed, 21 Oct 87 13:08:14 EDT
Date: Wed, 21 Oct 87 13:08:14 EDT
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: scheme@mc.lcs.mit.edu
Cc: bartlett@decwrl.dec.com, newton@CSVAX.CALTECH.EDU, mkatz@A.ISI.EDU,
laubsch%hpljl@hplabs.hp.com, sgr@SCRC-STONY-BROOK.ARPA,
tommy%colgate.csnet@RELAY.CS.NET, twleung@ATHENA.MIT.EDU,
finin@BIGBURD.PRC.UNISYS.COM, gudeman%arizona.edu@RELAY.CS.NET,
kanderso@WILMA.BBN.COM
Subject: Semantic Prototyping System
In response to numerous requests:
Scheme84 and SPS are available on iuvax.cs.indiana.edu via ftp (login:
anonymous, with any password) as /usr/ftp/pub/scheme84 and
/usr/ftp/pub/SPS, respectively.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂21-Oct-87 1831 @MC.LCS.MIT.EDU:bartlett@decwrl.dec.com Type Inference in Scheme Summary
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87 18:31:37 PDT
Received: from sonora.dec.com (TCP 20013200064) by MC.LCS.MIT.EDU 21 Oct 87 21:27:06 EDT
Received: from saturn.dec.com by sonora.dec.com (5.54.4/4.7.34)
id AA14559; Wed, 21 Oct 87 18:25:18 PDT
Received: by saturn.dec.com (5.54.3/4.7.34)
id AA02608; Wed, 21 Oct 87 18:27:13 PDT
From: bartlett@decwrl.dec.com (Joel Bartlett)
Message-Id: <8710220127.AA02608@saturn.dec.com>
Date: 21 Oct 1987 1827-PDT (Wednesday)
To: scheme@mc.lcs.mit.edu
Cc:
Subject: Type Inference in Scheme Summary
The question:
I am interested in using type inference to get faster code out of my
Scheme compiler. I'd greatly appreciate pointers to any existing work in
that area...
Responses:
You should look at my SPS (Semantic Prototyping System) which includes, among
other things, an ML-style type inference system for a pretty good chunk of
Scheme. A hardcopy writeup is in the Proceedings of the 1984 SIGPLAN Compiler
Construction Conference.
Scheme84 and SPS are available on iuvax.cs.indiana.edu via ftp (login:
anonymous, with any password) as /usr/ftp/pub/scheme84 and
/usr/ftp/pub/SPS, respectively.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
--
Here is one of the definitive papers on Type Inference:
Robin Milner. "A Theory of Type Polymorphics in Programming"
_Journal of Computer and System Sciences_, 17 348-375 December 1978.
It describes his system of polymorphism in the language ML.
Jamey Hicks (jamey@xn.ll.mit.edu)
--
A type inference system for Common Lisp is described in "Lisp Pointers",
Vol 1, No. 2. The author is Randall D. Beer (beer%case@CSNET-RELAY.ARPA).
Thanks for the pointers,
jfb
∂22-Oct-87 2305 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where can I get C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87 23:05:13 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Oct 87 01:29:53 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA22303; Thu, 22 Oct 87 22:18:09 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Oct 87 17:34:32 GMT
From: gti%psuvm.bitnet@ucbvax.Berkeley.EDU (Leon Geesey)
Organization: The Pennsylvania State University - Computation Center
Subject: Where can I get C-Scheme?
Message-Id: <23060GTI@PSUVM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I was wondering where I could get the source for C-Scheme?
I have FTP access and would like to get C-scheme up and
running on a PC.
leon geesey
∂23-Oct-87 0604 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where can I get C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 06:03:57 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Oct 87 08:59:38 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA29382; Fri, 23 Oct 87 05:52:16 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Oct 87 11:31:17 GMT
From: fxgrp!ljz@ames.arpa (Lloyd Zusman)
Organization: FX Development Group, Inc., Mountain View, CA
Subject: Re: Where can I get C-Scheme?
Message-Id: <129@fxgrp.UUCP>
References: <23060GTI@PSUVM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <23060GTI@PSUVM> GTI@PSUVM.BITNET (Leon Geesey) writes:
>I was wondering where I could get the source for C-Scheme?
>I have FTP access and would like to get C-scheme up and
>running on a PC.
Same here. Respond via mail.
Thanks!
--
Lloyd Zusman, Master Byte Software, Los Gatos, California
"When your software gets hard, go Master Byte."
...!ames!fxgrp!ljz
∂23-Oct-87 1035 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU C Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 10:35:40 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 23 Oct 87 13:33:14 EDT
Received: by GENEVA.AI.MIT.EDU; Fri, 23 Oct 87 13:38:18 edt
Date: Fri, 23 Oct 87 13:38:18 edt
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8710231738.AA15403@geneva>
To: scheme@mc
Subject: C Scheme
Reply-To: jinx@zurich.ai.mit.edu
*** NOTE ***
Please do not send C Scheme specific questions to this mailing list
(scheme@mc.lcs.mit.edu).
Send them instead to info-cscheme%oz@mc.lcs.mit.edu .
If you have problems getting in touch, AS A LAST RESORT, send them to
scheme-request@mc.lcs.mit.edu. They'll be forwarded to the right
place.
Thank you.
∂23-Oct-87 2121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme in the real world
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Oct 87 21:21:44 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Oct 87 23:49:58 EDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA15430; Fri, 23 Oct 87 20:02:43 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Oct 87 18:50:08 GMT
From: tektronix!reed!percival!baer@ucbvax.Berkeley.EDU (Ken Baer)
Organization: Percy's UNIX, Portland, OR.
Subject: Scheme in the real world
Message-Id: <950@percival.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
(Hey LineEater, Cdr this!!!)
I went to Oberlin College, where Scheme was strongly emphasised. The Prof
who taught the Scheme courses (Rich Salter), went to Indiana U. Most of
the people I know of that use Scheme, are from there, or have a strong
connection. I am curious who else uses Scheme, especially in the real world
(read corporate and/or commercial world). Oberlin is producing some very
strong Scheme programmers, what companies out there could use these people?
How are these companies using Scheme? I know there's a group at Tektronix
using Scheme, there must be others.
BTW, Oberlin is on Usenet, but they're feed doesn't have this group.
Maybe someone could contact the postmaster there and work something out.
I'm glad to see this group here.
--
-Ken Baer.
"Press the button labeled 'Extreme Emergency' on the console" - The Doctor.
USENET - ...tektronix!reed!percival!baer OR baer@percival.pdx.com
"The Few, The Proud, The Criminally Insane - Oberlin Computer Science" - me.
∂25-Oct-87 1905 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme in the real world
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 19:05:00 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 25 Oct 87 22:02:08 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA22947; Sun, 25 Oct 87 18:53:50 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Oct 87 23:49:49 GMT
From: psuvax1!vu-vlsi!swatsun!hirai@rutgers.edu (Eiji "A.G." Hirai)
Organization: Sun Lab, Swarthmore College PA
Subject: Re: Scheme in the real world
Message-Id: <1346@carthage.swatsun.UUCP>
References: <950@percival.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <950@percival.UUCP> baer@percival.UUCP (Ken Baer) writes:
>
>I went to Oberlin College, where Scheme was strongly emphasised. The Prof
> ...
>connection. I am curious who else uses Scheme, especially in the real world
We use Scheme here at Swarthmore College in our Programming Languages
class. Our Professor is a devout Scheme evangelist and we are in the
process of being converted (from CommonLisp). Funny that two small liberal
arts collges like Swarthmore and Oberlin are Scheme places. I guess
Swartmore doesn't count as a real world place.
-AG Hirai
--
--
Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. 215-543-9855
UUCP: {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai | "All Cretans are liars."
Inter: swatsun!hirai@bpa.bell-atl.com | -Epimenides
Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | of Cnossus, Crete
∂26-Oct-87 0853 @MC.LCS.MIT.EDU:andy%hobbes@ADS.ARPA applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 08:53:11 PST
Received: from ADS.ARPA (TCP 20071200430) by MC.LCS.MIT.EDU 26 Oct 87 11:53:04 EST
Received: by ADS.ARPA (5.57/1.2)
id AA07538; Mon, 26 Oct 87 08:52:22 PST
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA03168; Mon, 26 Oct 87 08:49:51 PST
Date: Mon, 26 Oct 87 08:49:51 PST
From: andy%hobbes@ADS.ARPA (Andy Cromarty)
Message-Id: <8710261649.AA03168@hobbes.ads.arpa>
To: rrrs-authors@mc.lcs.mit.edu
Subject: applicability of "syntax" constructs
Reply-To: andy%hobbes@ads.arpa
[I haven't seen mail from RRRS-AUTHORS for a while; I assume this is
because the list has been dormant, rather than because of a mailer
problem.]
I'd like to solicit views on the question of application of
macros and their first- vs. second-class status in Scheme.
The popular evaluation model for "syntax," as I understand
it, implies that evaluation of (X a b c) will induce Scheme
to look for a "syntax" definition of X before looking for
a normal binding, whereas in (a X b c) the "syntax" definition
of X is not sought by the evaluator and the normal binding, if
any, is used.
Now consider the case where, for example, "a" above is "apply".
I find this troubling. (apply or '(#f #f #t)) "should work," from
the perspective of the programmer. This is true for two reasons:
1. Consistent treatment of operators as viewed from the perspective of
the programmer (vs. the implementor or language designer).
2. Inability to determine when objects may or may not be applied on
a practical basis.
Some time ago we discussed introducing APPLICABLE?; I believe this
was shelved in favor of PROCEDURE?, which of course is not quite the
same thing. I'm especially concerned about what happens once we
define a user-accessible macro capability and let the users loose
with it: in a large system, a given programmer only writes a small
part of the software, but for Scheme the standard interface specification of
a procedure someone else wrote no longer is adequate to tell you
how to use it---you also need to know whether or not it is APPLICABLE?.
Worse, in practice we learn how to use operators by looking at other
people's code rather than from an interface spec (if one even exists),
and even a programmer who is familiar with the principles of Dijkstra
short-circuit AND/OR constructs and so forth would find nothing in
looking at (or #t #f) to would indicate that (apply or '(#t #f))
would be improper.
Even given the availability of some predicate that distinguishes
between syntax and procedures, our code would become
tortuously cluttered if we have to insert checks for APPLICABLE?
throughout our programs whenever we wish to apply (what we hope is)
the procedure bound to a token someone else defined.
This line of reasoning seems to me to lead to a requirement for either
a "smart compiler" or the implementation of macros as first-class objects,
at which point we seem in essence to be talking about FEXPRS/NLAMBDAS.
I've only gotten into this issue far enough for it to bother me, not
far enough to see a clear design solution; perhaps others have more
insight to offer.
asc
∂26-Oct-87 1526 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 15:25:57 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 26 Oct 87 17:37:57 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 26 Oct 87 17:26:54 est
Date: Mon, 26 Oct 87 17:26:54 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8710262226.AA17162@geneva>
To: andy%hobbes@ads.arpa
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Andy Cromarty's message of Mon, 26 Oct 87 08:49:51 PST <8710261649.AA03168@hobbes.ads.arpa>
Subject: applicability of "syntax" constructs
Reply-To: jinx@zurich.ai.mit.edu
I'd like to solicit views on the question of application of
macros and their first- vs. second-class status in Scheme. ...
I suspect that the subject is highly controversial, but these are my
views on the matter:
1)
There is a traditional pun used in Lisp. The syntax for special forms
and combinations (procedure calls) is the same. This results in a a
fair amount of convenience, some power, and a great deal of confusion.
A perhaps wiser decision would have been to mark special forms with
square brackets (or squiggly braces, or something like that), rather
than the parentheses used for combinations, but the resulting language
would not be a Lisp.
Your problem arises from trying to view special forms as combinations
(due most likely to this pun), and therefore inquiring about the
status of their (nonexistent) operator.
(if <pred> <conseq> <alternative>)
is part of the syntax of the language. IF is not a "special" operator
which does something "strange". The whole expression (form) is special,
and the only thing in common between it and a combination is the
similarity in surface syntax.
In the same way that no C programmer would think of applying "while"
or "if" to arguments (let alone pass them around), no Scheme programmer
should think of invoking "if", "cond", "lambda", "or", or user defined
special form keywords. The keywords mean nothing by themselves, they
are as good as the parentheses that surround the form, and it makes as
much sense to talk about applying them as about applying parentheses,
semicolons, or spaces.
As far as I know, none of the major implementations of Scheme match
the popular evaluation model you suggest. IF, COND, OR, etc can be
viewed as part of the compiler or preprocessor, and are long gone by
the time the issue of where to find X arises.
In MIT Scheme, which is consistent with this philosophy, the question
of whether IF is APPLICABLE?/PROCEDURE? cannot arise. IF is
"nothing", and the expression
(procedure? if)
is in error, and in fact would cause something like
Error: Unbound variable IF
to be printed.
A different question altogether is whether special form keywords can
be valid variable identifiers, and if so, what happens in case of
conflict.
2)
The "unfortunate" fact of life is that Scheme is an applicative order
language, and some things which could be accomplished conveniently in
a normal order dialect cannot. For example, in the presence of
(define (if pred conseq alt)
(cond (pred conseq)
(else alt)))
the following expression is in error, although the intent was quite
different.
(let ((x 0))
(if (= x 0)
'INFINITY
(/ 1 x)))
To make up for this "deficiency" of the language, we "abuse" special
forms, and define a special form whose KEYWORD is "if" and
accomplishes the desired behavior, but is no substitute for a normal
order IF procedure.
Note that in your example
(apply or '(#f #f #t))
the answer is clear, but what should the answer be in
(let ((x 2))
(apply or (list (= x 2) (begin (write 4) (= x 3)))))
There are many possibilities. The main ones are:
a) 4 is never printed. This would be the case in a "normal order
Scheme". If you choose this one, you've just required APPLY to be a
normal order procedure, and similarly for most other high order
procedures. That is a valid language decision, different from that
made by Scheme's designers. While it has nicer properties than
applicative order, normal order also has some problems, not the least
of which is that no one (as far as I know) knows how to compile normal
order languages efficiently.
b) 4 is printed, and the correct "boolean" value is returned. This
leads to a very ugly semantics: For consistency, you would have
the following two expressions behave differently,
(or (= x 2) (begin (write 4) (= x 3)))
((begin or) (= x 2) (begin (write 4) (= x 3)))
which I think is worse than the original "problem".
3)
Assuming that we are happy with the fact that special forms have no
operators, (and therefore the notion of applying OR is confused), the
problem of distinguishing special form keywords from identifiers whose
values are procedures still remains. This is a matter of
readability/documentation, and a simple solution is the adoption of
conventions.
A suggestion along these lines is to use the same sort of convention
that is already informally followed for predicates (the last character
of their name is ?). For example, user defined special form keywords
could have $ as their first character. The built-in special forms
follow no such conventions, but there are few of them, and most
programmers probably remember them, so we can live with them the way
they are.
∂26-Oct-87 1544 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Scheme in the real world
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 15:43:51 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Oct 87 17:38:42 EST
Received: from relay2.cs.net by RELAY.CS.NET id av17137; 26 Oct 87 17:01 EST
Received: from tektronix.tek.com by RELAY.CS.NET id bx08783; 26 Oct 87 16:04 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA13246; Mon, 26 Oct 87 10:38:32 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA04608; Mon, 26 Oct 87 10:37:48 PST
Date: Mon, 26 Oct 87 10:37:48 PST
From: Will Clinger <willc%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8710261837.AA04608@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: Re: Scheme in the real world
Cc: willc%tekchips.tek.com@RELAY.CS.NET
At Tektronix Laboratories, Scheme is viewed as a base language for
research in advanced programming languages and has begun to be used
as an implementation language for research projects such as a specification
environment based on CSP.
Peace,
William Clinger
∂27-Oct-87 0814 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 08:14:04 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 27 Oct 87 11:15:34 EST
Date: Tue, 27 Oct 87 11:13:10 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%geneva.ai.mit.edu@RELAY.CS.NET
Subject: Re: applicability of "syntax" constructs
Cc: rrrs-authors@mc.lcs.mit.edu
Instead of using $ to mark syntactic keywords, why not use the
convention that keywords are capitalized (or in all-caps) and that
identifiers are in lower case?
∂27-Oct-87 0947 @MC.LCS.MIT.EDU:gls@Think.COM applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:47:17 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 27 Oct 87 12:48:20 EST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 27 Oct 87 12:44:44 EST
Received: by kali.think.com; Tue, 27 Oct 87 12:45:08 EST
Date: Tue, 27 Oct 87 12:45:08 EST
From: gls@Think.COM
Message-Id: <8710271745.AA09092@kali.think.com>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%geneva.ai.mit.edu@relay.cs.net, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 27 Oct 87 11:13:10 est <8710271615.AA28649@Think.COM>
Subject: applicability of "syntax" constructs
Date: Tue, 27 Oct 87 11:13:10 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Instead of using $ to mark syntactic keywords, why not use the
convention that keywords are capitalized (or in all-caps) and that
identifiers are in lower case?
BECAUSE people hate mixed case AND think it is ugly.
WOULD you want TO use mixed case IN your code?
--Quux :-)
∂27-Oct-87 1039 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Tao, Sues...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 10:39:28 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Oct 87 13:34:22 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA04338; Tue, 27 Oct 87 10:13:52 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 Oct 87 00:43:20 GMT
From: russell!evan@labrea.stanford.edu (Evan Kirshenbaum)
Organization: Center for the Study of Language and Information, Stanford U.
Subject: Re: Tao, Sues...
Message-Id: <428@russell.STANFORD.EDU>
References: <8710131545.AA04566@vor.esosun.uucp>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
TAO is described in a paper by Ikuo Takeuchi, Hiroshi Okuno and
Nobusayu Ohsatu of NTT called ``A List Processing Language TAO with
Multiple Programming Paradigms'' which appeared in New Generation
Computing 4(1986). It looks quite interesting. I'd be interested in
hearing whether anybody has come up with a way in Lisp or Scheme to do
self-assignment as it is done in TAO. It looks like it could be a
useful way to describe destructive operations.
---
Evan Kirshenbaum
Stanford University
evan@CSLI.STANFORD.EDU
...!{ucbvax,decvax}!decwrl!glacier!evan
If you think my opinions represent this university,
you haven't been on campus recently!
∂27-Oct-87 1259 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 12:59:09 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 27 Oct 87 15:55:44 EST
Received: by GENEVA.AI.MIT.EDU; Tue, 27 Oct 87 15:57:52 est
Date: Tue, 27 Oct 87 15:57:52 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8710272057.AA17882@geneva>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "R. Kent Dybvig"'s message of Tue, 27 Oct 87 11:13:10 est <8710272047.AA17836@geneva>
Subject: applicability of "syntax" constructs
Reply-To: jinx@zurich.ai.mit.edu
Some implementations are case insensitive, and although the issue is
mostly one of readability and convention, and should not be depended
on by code, I'd hate to see some information that a program could not
use (heuristically, of course) to advantage. Otherwise that would be
fine.
∂27-Oct-87 1323 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 13:23:37 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Oct 87 16:20:39 EST
Date: Tue, 27 Oct 87 16:21:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
To: scheme@MC.LCS.MIT.EDU
Message-ID: <275884.871027.JAR@AI.AI.MIT.EDU>
Date: Mon, 26 Oct 87 13:52:20 mst
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8710262052.AA03833@cons.UTAH.EDU>
To: common-lisp@sail.stanford.edu
Subject: 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
CALL FOR PAPERS
1988 ACM Conference on
LISP AND FUNCTIONAL PROGRAMMING
Snowbird, Utah, July 25-27, 1988
The 1988 ACM Conference on LISP and Functional Programming is the
fifth in a series of biennial conferences devoted to the theory,
design, and implementation of programming languages and systems
that support symbolic computation. The conference is jointly
sponsored by ACM SIGPLAN, SIGACT, and SIGART. Papers presented
at the conference must include new ideas or experimental results
that have not been previously published. The conference program
is not limited to topics discussed in previous conferences in the
series; authors are strongly encouraged to submit papers that in-
troduce important new topics that are relevant to functional pro-
gramming and symbolic computation. The major topics that have
been addressed at previous conferences include:
1) programming language concepts and facilities
2) implementation methods
3) machine architectures
4) semantic foundations
5) programming logics
6) program development environments
7) applications of symbolic computation Authors are invited to
submit 11 copies of a technical summary of a prospective confer-
ence paper to the program committee chairman. The length of the
summary should not exceed 3,000 words (10 pages double-spaced or
typeset 10-point on 16-point spacing). Since the committee ex-
pects to receive a large number of submissions, the summary
should be organized so that it is easily understood. It is im-
portant for the summary to identify what has been accomplished,
explain why it is significant, and compare it with previous work.
Submissions must be received by Jan 22, 1988. They should in-
clude a return postal address and an electronic mail address if
it is available. Authors will be notified of the acceptance or
rejection of their papers by March 11, 1988. Full versions of
the accepted papers must be received in camera-ready form by
April 22, 1988. Authors of accepted papers will be required to
sign ACM copyright release forms. Proceedings will be distribut-
ed at the conference and will later be available for purchase
from the ACM. The conference site at Snowbird, Utah is a resort
located in the rugged Wasatch mountain range approximately 35
miles from Salt Lake City. Summer activities include hiking,
climbing, swimming, tennis, and wildflower photography.
Program Committee Chairman Program Committee
Robert (Corky) Cartwright Harold Abelson, MIT
Attn: LFP 88 Richard Bird, Oxford University
Rice University Luca Cardelli, DEC Systems Res. Ctr.
Department of Computer Science Robert Cartwright, Rice University
P. O. Box 1892 Richard Gabriel, Lucid Inc.
Houston, TX 77251-1892 Christopher Haynes, Indiana University
(713) 527-4834 Gerard Huet, INRIA Rocquencourt
cork@rice.edu Gilles Kahn, INRIA Sophia Antipolis
David Moon, Symbolics Inc.
Guy Steele, Thinking Machines Corp.
Carolyn Talcott, Stanford University
General Chairman Local Arrangements Chairman
Jerome Chailloux Robert Kessler
INRIA University of Utah
Domaine de Voluceau-Rocquencourt Department of Computer Science
B.P. 105 3190 M.E.B.
Le Chesnay Cedex Salt Lake City, Utah 84112
France kessler@cs.utah.edu
chaillou@inria.inria.fr
∂27-Oct-87 1414 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 14:13:51 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 27 Oct 87 16:21:41 EST
Date: Tue, 27 Oct 87 16:19:04 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: gls@Think.COM
Subject: Re: applicability of "syntax" constructs
Cc: rrrs-authors@mc.lcs.mit.edu
From: gls@Think.COM
Subject: applicability of "syntax" constructs
Date: Tue, 27 Oct 87 11:13:10 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Instead of using $ to mark syntactic keywords, why not use the
convention that keywords are capitalized (or in all-caps) and that
identifiers are in lower case?
BECAUSE people hate mixed case AND think it is ugly.
WOULD you want TO use mixed case IN your code?
--Quux :-)
$really! $it is obviously better to use dollar signs. $at least
$i think so. $don't you?
Seriously, I do not find the following terribly ugly:
(Define fumble
(Lambda (x)
(If (< x 0)
(fumble (- x))
x)))
or
(DEFINE fumble
(LAMBDA (x)
(IF (< x 0)
(- (fumble (- x)))
x)))
I would prefer to put keywords in bold face, but those with
upper-case only terminals wouldn't be the only ones left out in
the cold!
∂28-Oct-87 0937 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu FX-87 is born
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 09:37:26 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Oct 87 12:35:13 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA02607; Wed, 28 Oct 87 09:10:42 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Oct 87 14:27:41 GMT
From: mit-vax!jouvelot@eddie.mit.edu (Pierre Jouvelot)
Organization: MIT Laboratory for Computer Science, Cambridge
Subject: FX-87 is born
Message-Id: <2967@mit-vax.LCS.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
--
The FX-87 Programming Language and its Reference Manual are now available.
Quoting the abstract :
"The FX programming language is designed to support the parallel
implementation of applications that perform both symbolic and scientific
computations. Unlike previous languages, FX uses an effect system to
discover expression scheduling constraints. The effect system is part of
a kinded type system with three base kinds:
. types, which describe the value of an expression;
. effects, which describe the side-effects that an expression may have;
. regions, which describe the areas of the store in which side-effects
may occur.
Types, effects, and regions are collectively called descriptions.
FX expressions can be abstracted over any kind of description. This
permits type, effect, and region polymorphism. Unobservable side-effects
are masked by the effect system; an effect soundness property guarantees
that the effects computed statically by the effect system are a
conservative approximation of the actual side-effects that a given
expression may have.
Effect polymorphism and effect masking make the FX effect system
substantially more powerful than previous approaches to side-effect
analysis."
The "FX-87 Reference Manual (Edition 1.0)" is the MIT/LCS Technical Report
no.407 and can be ordered (for about $12) at the following address :
LCS Publications
Laboratory for Computer Science
Massachusetts Institute of Technology
545, Technology Square
Cambridge, MA 02139
U.S.A.
An experimental and sequential version of FX has been implemented in Scheme.
People interested in implementation issues can contact gifford@XX.LCS.MIT.EDU
for more information.
David K. Gifford
Pierre Jouvelot
John M. Lucassen
Mark A. Sheldon
--
Pierre Jouvelot
Room NE43-403 ARPA: jouvelot@xx.lcs.mit.edu
Lab for Computer Science USENET: decvax!mit-vax!jouvelot
MIT (or mcvax!litp!pj)
545, Technology Square TPH: (617) 253-0884
Cambridge, MA 02139
USA
∂28-Oct-87 1726 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu applicability of "syntax" constructs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 17:26:35 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Oct 87 19:41:04 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa10202; 28 Oct 87 12:56 EST
Received: from northeastern.edu by RELAY.CS.NET id af21255; 28 Oct 87 12:50 EST
Received: from corwin.ccs.northeastern.edu by
nuhub.acs.northeastern.edu; Wed, 28 Oct 87 09:37 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
id AA11202; Wed, 28 Oct 87 09:25:57 EST
Date: Wed, 28 Oct 87 09:25:57 EST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: dyb@iuvax.cs.indiana.edu
Cc: gls@THINK.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "R. Kent Dybvig"'s message of Tue, 27 Oct 87 16:19:04 est
Subject: applicability of "syntax" constructs
How about making syntactic keywords start with the letters I through N, and
identifiers start with A-H and O-Z?
∂28-Oct-87 1834 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU RE: applicability of "syntax" mumble
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 18:34:19 PST
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 OCT 87 21:23:40 EST
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA11669@VX.LCS.MIT.EDU>; Wed, 28 Oct 87 20:42:45 est
Date: Wed, 28 Oct 87 20:42:45 est
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: RE: applicability of "syntax" mumble
Why use annoying special charcters like $ or case? Why
not have the special form AND and the procedure CONJUNCTION...
OR DISJUNCTION...
IF PREDICATION...
...and the like.
Better yet, since fonts are the wave of the future, lets make
italics old-english indicate ... mumble mumble
Hey! Let's make syntax FIRST CLASS!!
~Ziggy
∂28-Oct-87 1857 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU CALL
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 18:57:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Oct 87 21:42:39 EST
Date: Wed, 28 Oct 87 21:43:19 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: CALL
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <276693.871028.ALAN@AI.AI.MIT.EDU>
We could also eliminate the confusion between keywords and procedure calls
by introducing a new keyword CALL, that would be used to indicate a
combination:
(DEFINE (FACT N)
(IF (CALL < N 2)
1
(CALL * N (CALL FACT (CALL - N 1)))))
To further strain your brains I recall an idea that Bill Rozas (I think)
once had. He suggested that instead of putting the keyword or procedure in
the CAR of an expression, we could use the CADR. Then we might have (with
renamings appropriate for infix keywords):
((N FACT) IS
((N < 2) THEN
1
(N * ((N - 1) FACT))))
Seriously, as long as you can -statically- determine what identifiers are
keywords, I don't see any reason to change the language.
∂28-Oct-87 1921 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU Where can I get C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 19:21:24 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 28 Oct 87 22:17:42 EST
Received: by KLEPH.AI.MIT.EDU; Wed, 28 Oct 87 22:10:56 est
Date: Wed, 28 Oct 87 22:10:56 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8710290310.AA05221@kleph>
To: fxgrp!ljz@ames.arpa
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Lloyd Zusman's message of 23 Oct 87 11:31:17 GMT <129@fxgrp.UUCP>
Subject: Where can I get C-Scheme?
Reply-To: cph@mc.lcs.mit.edu
Date: 23 Oct 87 11:31:17 GMT
From: fxgrp!ljz@ames.arpa (Lloyd Zusman)
In article <23060GTI@PSUVM> GTI@PSUVM.BITNET (Leon Geesey) writes:
>I was wondering where I could get the source for C-Scheme?
>I have FTP access and would like to get C-scheme up and
>running on a PC.
Same here. Respond via mail.
Log into "prep.ai.mit.edu" as "scheme", password "scheme", and follow
the directions.
∂29-Oct-87 1003 @MC.LCS.MIT.EDU:JAR@ML.AI.MIT.EDU policy
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 10:02:57 PST
Received: from ML.AI.MIT.EDU (CHAOS 3133) by MC.LCS.MIT.EDU 29 Oct 87 12:57:25 EST
Date: Thu, 29 Oct 87 12:55:38 EST
From: Jonathan A Rees <JAR%ML.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject: policy
To: scheme@MC.LCS.MIT.EDU
Reply-to: scheme-request@mc.lcs.mit.edu
Message-ID: <5154.871029.JAR@ML.AI.MIT.EDU>
I've gotten tired of saying the same things over and over again, so I
have prepared a Scheme list "policy statement". I'll send this to every
new person who joins the list at MIT. Most of you have probably heard
all this before, so you can ignore it.
----------
General information about the Scheme mailing list:
- The list is not moderated. If you send mail to scheme@mc.lcs.mit.edu,
it will be forwarded to the hundreds (thousands?) of list members on the
ARPA Internet, CSNET, BITNET, Usenet, JUNET, etc. If you have any doubt
about the suitability of your message for this audience, send it to
scheme-request@mc.lcs.mit.edu instead, and your message will be either
answered or forwarded.
- Do not send messages concerning MIT's scheme implementation (C Scheme)
to the list; users of the many other Scheme implementations don't care
to see such messages. There is a separate list,
info-cscheme%oz@mc.lcs.mit.edu, for this purpose. To be added to that
list, send mail to info-cscheme-request%oz@mc.lcs.mit.edu.
- Send administrative requests to scheme-request@mc.lcs.mit.edu, NOT to
JAR. If your machine is scheduled to change its name or routing, or to
go off the net, or if you move, please send mail to scheme-request so
your entry can be changed.
- Every week, several addresses on the scheme list stop working, and
error reports are sent back to the message's sender or to
scheme-request. If a message you send gets bounced, forward the error
report to scheme-request. Bad addresses on the list can't be tolerated;
THEY WILL BE REMOVED FROM THE LIST WITHOUT NOTICE. Your address may
become invalid due to no fault of your own, and/or without your being
aware of it. For example, if your system becomes inaccessible from the
Internet for a week, of if it changes its name, messages to you will
bounce, and your entry will be removed from the list. If you don't get
any scheme messages for, say, three or four weeks, you might want to send
a message to scheme-request to verify that you're still on.
- If there's more than one person at your site who wants to be on the list,
please set up a local redistribution list.
- The list is archived in the following files:
LSPMAI; SCHEME MAIL1 on host AI.AI.MIT.EDU [oldest messages]
LSPMAI; SCHEME MAIL2 on host AI.AI.MIT.EDU
LSPMAI; SCHEME MAIL on host MC.LCS.MIT.EDU [newest messages]
Note that there are spaces in these filenames, so you may have to type
double quotes at your FTP program. If you don't have Internet FTP access,
tough luck.
- There is a file on host AI.AI.MIT.EDU, "LSPMAI; SCHEME IMPLS", that
has brief descriptions of available scheme implementations and how to
get them. If you want a copy of this file, but you don't have Internet
FTP access, send a request to scheme-request.
∂29-Oct-87 1654 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where can I get C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Oct 87 16:54:31 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Oct 87 19:51:45 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA10742; Thu, 29 Oct 87 16:32:26 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Oct 87 21:48:10 GMT
From: fxgrp!ljz@ames.arpa (Lloyd Zusman)
Organization: FX Development Group, Inc., Mountain View, CA
Subject: Re: Where can I get C-Scheme?
Message-Id: <136@fxgrp.UUCP>
References: <129@fxgrp.UUCP>, <8710290310.AA05221@kleph>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8710290310.AA05221@kleph> cph@mc.lcs.mit.edu writes:
>>I was wondering where I could get the source for C-Scheme?
>Log into "prep.ai.mit.edu" as "scheme", password "scheme", and follow
>the directions.
Is there a dialup line into that machine? In general, how does one
log into a machine just by knowing its uucp address? Is there something
about the net I don't know?
Replying by email is OK, but perhaps others would like to know this, also.
--
Lloyd Zusman, Master Byte Software, Los Gatos, California
"We take things well in hand."
...!ames!fxgrp!ljz
∂30-Oct-87 1014 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET portability of SCHEME
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 10:13:57 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 30 Oct 87 13:11:23 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 30 Oct 87 13:10:01 EST
Received: from HNYKUN52.BITNET (EDH) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 1104; Fri, 30 Oct 87 13:09:50 EST
Date: Fri, 30 Oct 87 17:18 N
From: <EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU>
Subject: portability of SCHEME
To: SCHEME@MC.LCS.MIT.EDU
X-Original-To: SCHEME@MC.LCS.MIT.EDU, EDH
How portable is MIT's source?
We are trying to port the MIT Scheme source to a DOS machine. The documentation
warns that long integers must be 32 bits, but nothing is said about normal
integers.
It so happens that many macros expand to code containing forms like the
folowing:
..
long mask = 1 << 24;
..
Now, our C compilers - Manx 3.2, Lattice, as well as Microsoft - take 16 bits
for an integer, and default constants to the same. The value of 'mask' in the
expression just mentioned therefor will be 0 after the assignment.
Questions:
1) Has anyone met this problem and found a way to circumvent it,
and/or
2) Does someone know about a C compiler that does not show this phenomenon.
NB. We know it does not suffice to turn all integers into longs, since they may
cause problems when used as parameters in a function call.
Scheme-team Nijmegen,
the Netherlands.
∂30-Oct-87 1138 @MC.LCS.MIT.EDU:jdevries@ads.arpa Extend-Syntax for MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 11:38:48 PST
Received: from ADS.ARPA (TCP 20071200430) by MC.LCS.MIT.EDU 30 Oct 87 14:33:29 EST
Received: by ADS.ARPA (5.57/1.2)
id AA16872; Fri, 30 Oct 87 11:33:19 PST
Date: Fri, 30 Oct 87 11:33:19 PST
From: Jeff De Vries <jdevries@ads.arpa>
Message-Id: <8710301933.AA16872@ADS.ARPA>
To: scheme@mc.lcs.mit.edu
Subject: Extend-Syntax for MacScheme
In the book "The Scheme Programming Language", Kent Dybvig describes
a powerful tool for syntactic extension called extend-syntax. Basically,
it allows you to specify transformations from input representations to
the corresponding code to be executed. For a quick example, consider
we wish to implement the LET syntactic form. This could be done with
extend-syntax as follows:
(extend-syntax (PIGLET)
((PIGLET ((x v) ...) e1 e2 ...)
(andmap symbol? '(x ...))
((lambda (x ...) e1 e2 ...) v ...)))
This would define a new syntactic form (i.e. macro) named PIGLET that
translates things of the form (PIGLET ((x v) ...) e1 e2 ...) to the
corresponding LAMBDA form after verifying that all the x's are
symbols. Notice the powerful pattern matching abilities provided by
using the ellipsis (...). There is a *LOT* more to extend-syntax than
this example would indicate. For the full glories, (defstruct in about
20 lines of code, objects (as in OOP) in about the same), see the book.
Well, I coveted the power of extend-syntax and desired it greatly, so
I asked Kent Dybvig if he would part with the necessary incantations...
Behold! I had Mail! (thanks kent!)
I am running MacScheme Version 1.22 and have converted the extend-syntax
code to work under such. If you would like a copy, send me e-mail to
that effect and I'll see that a copy is sent to you. If I get swamped
with requests, I might just post the whole thing to here.
Jeff De Vries (ARPA: jdevries@ads.arpa)
Usual Disclaimers Apply.
∂30-Oct-87 1407 @MC.LCS.MIT.EDU:sas@bfly-vax.bbn.com Extend-Syntax for MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 87 14:07:41 PST
Received: from BFLY-VAX.BBN.COM (TCP 20026200235) by MC.LCS.MIT.EDU 30 Oct 87 17:05:05 EST
To: jdevries@ads.ARPA
CC: scheme@mc.lcs.mit.edu
In-reply-to: Jeff De Vries's message of Fri, 30 Oct 87 11:33:19 PST
Subject: Extend-Syntax for MacScheme
Date: 30 Oct 87 16:55:30 EST (Fri)
From: sas@bfly-vax.bbn.com
Yes, please send me a copy of Kent Dybvig's extend-syntax package and
whatever else you've got.
Thanks,
Seth
∂31-Oct-87 1650 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Revised(3) report: could MIT post tex source for it ??
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 87 16:50:46 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 31 Oct 87 19:49:02 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA29449; Sat, 31 Oct 87 16:40:51 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Oct 87 17:08:32 GMT
From: clyde!watmath!utgpu!utzoo!yetti!oz@rutgers.edu
Organization: York U. Computer Science
Subject: Revised(3) report: could MIT post tex source for it ??
Message-Id: <180@yetti.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is it possible for MIT folk to post the tex source for the
revised (3) report on scheme ?? The version I have from the
Cscheme distribution is out of date, and also, the special MIT
TeX macros used in the report are not included. So, it is not
TeXable. A good place to post would be comp.sources.doc.
thnx.. oz
--
You see things, and you say "WHY?" Usenet: [decvax|ihnp4]!utzoo!yetti!oz
But I dream things that never were; ......!seismo!mnetor!yetti!oz
and say "WHY NOT?" Bitnet: oz@[yusol|yulibra|yuyetti]
[Back To Methuselah] Bernard Shaw Phonet: [416] 736-5257 x 3976
∂01-Nov-87 0928 @MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU Revised(3) report: could MIT post tex source for it ??
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Nov 87 09:28:08 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 1 Nov 87 12:27:40 EST
Received: by GENEVA.AI.MIT.EDU; Sun, 1 Nov 87 12:30:39 est
Date: Sun, 1 Nov 87 12:30:39 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8711011730.AA21105@geneva>
To: clyde!watmath!utgpu!utzoo!yetti!oz@rutgers.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: clyde!watmath!utgpu!utzoo!yetti!oz@rutgers.edu's message of 28 Oct 87 17:08:32 GMT <180@yetti.UUCP>
Subject: Revised(3) report: could MIT post tex source for it ??
Reply-To: jinx@zurich.ai.mit.edu
Is it possible for MIT folk to post the tex source for the
revised (3) report on scheme ?? The version I have from the
Cscheme distribution is out of date, and also, the special MIT
TeX macros used in the report are not included. So, it is not
TeXable. A good place to post would be comp.sources.doc.
The sources for r3rs are available by internet/arpanet ftp from host
prep.ai.mit.edu . They are contained in the file /scheme/r3rs.tar, and
you can log in as user scheme (password scheme).
The current MIT CScheme distribution contains these sources as well.
The previous release (release 4) contained rrrs instead, since r3rs
was not yet out.
∂02-Nov-87 1048 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu documentation?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Nov 87 10:48:06 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 Nov 87 13:46:41 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA01149; Mon, 2 Nov 87 10:29:56 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Nov 87 15:15:21 GMT
From: super.upenn.edu!eecae!lawitzke@rutgers.edu (John Lawitzke)
Organization: Mich. State Univ., Electronics R&D Laboratory
Subject: documentation?
Message-Id: <3623@eecae.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is there any sort of reference to learn scheme from?
--
j UUCP: ...ihnp4!msudoc!eecae!lawitzke
"And it's just a box of rain..." ARPA: lawitzke@eecae.ee.msu.edu (35.8.8.151)
∂03-Nov-87 1812 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Source for Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 18:11:25 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 3 Nov 87 20:56:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA14206; Tue, 3 Nov 87 05:32:44 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Nov 87 02:42:32 GMT
From: ihnp4!occrsh!uokmax!rjray@ucbvax.Berkeley.EDU (Randy J Ray)
Organization: University of Oklahoma, Norman, OK
Subject: Source for Scheme?
Message-Id: <825@uokmax.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Unfortunately, here at the University, we are without Scheme at all. Is
there a PD version of Scheme that can be put up or mailed to me? We
are using BSD 4.23 (doesn't everyone?). The source is preferred in C, if
possible, but we will accept that which we can get . . .
Randy J. Ray
rjray@uokmax.uucp
∂03-Nov-87 2205 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 87 22:05:32 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 4 Nov 87 00:12:39 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA21735; Tue, 3 Nov 87 09:54:07 EST
Posted-Date: Tue, 3 Nov 87 09:48:51 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA03451; Tue, 3 Nov 87 09:48:51 EST
Date: Tue, 3 Nov 87 09:48:51 EST
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8711031448.AA03451@darwin.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: Tigger on Scheme
Posted-Date: Mon, 6 Jul 87 07:46:39 EDT
Date: Mon, 6 Jul 87 07:46:39 EDT
From: Tigger@Hundred-Acre-Wood.Milne.Disney
To: ramsdell@linus.uucp
Subject: Scheme
The wonderful thing about Scheme is:
Scheme is a wonderful thing.
Complex procedural ideas
Are expressed via simple strings.
It's clear semantics, and lack of pedantics,
Help make programs run, run, RUN!
But the most wonderful thing about Scheme is:
Programming in it is fun,
Programming in it is FUN!
------------------------------------------------------
The scheme poem was a take-off on the poem explaining the wonderful
thing about about Tiggers. I mistakenly though that Tigger's poem was
from A. A. Milnes' "House At Pooh Corner", but it was created by
Disney in their animated film on Pooh. Thus, I changed Tigger's
return address. Please destroy old copies of the poem.
John
∂04-Nov-87 1702 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Tigger on Scheme / correction
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Nov 87 17:01:53 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Nov 87 19:51:39 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA07151; Wed, 4 Nov 87 16:36:40 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Nov 87 19:41:25 GMT
From: necntc!linus!ramsdell@ames.arpa (John D. Ramsdell)
Organization: The MITRE Corporation, Bedford MA
Subject: Tigger on Scheme / correction
Message-Id: <16715@linus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Posted-Date: Mon, 6 Jul 87 07:46:39 EDT
Date: Mon, 6 Jul 87 07:46:39 EDT
From: Tigger@Hundred-Acre-Wood.Milne.Disney
To: ramsdell@linus.uucp
Subject: Scheme
The wonderful thing about Scheme is:
Scheme is a wonderful thing.
Complex procedural ideas
Are expressed via simple strings.
Its clear semantics, and lack of pedantics,
Help make programs run, run, RUN!
But the most wonderful thing about Scheme is:
Programming in it is fun,
Programming in it is FUN!
------------------------------------------------------
Just correcting the English. Thanks to those who noticed the mistake.
John
∂05-Nov-87 0426 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Tigger on Scheme / correction
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 04:26:07 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 5 Nov 87 07:25:13 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA21799; Thu, 5 Nov 87 07:24:10 EST
Posted-Date: Thu, 5 Nov 87 07:18:54 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA01327; Thu, 5 Nov 87 07:18:54 EST
Date: Thu, 5 Nov 87 07:18:54 EST
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8711051218.AA01327@darwin.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: Tigger on Scheme / correction
Posted-Date: Mon, 6 Jul 87 07:46:39 EDT
Date: Mon, 6 Jul 87 07:46:39 EDT
From: Tigger@Hundred-Acre-Wood.Milne.Disney
To: ramsdell@linus.uucp
Subject: Scheme
The wonderful thing about Scheme is:
Scheme is a wonderful thing.
Complex procedural ideas
Are expressed via simple strings.
Its clear semantics, and lack of pedantics,
Help make programs run, run, RUN!
But the most wonderful thing about Scheme is:
Programming in it is fun,
Programming in it is FUN!
------------------------------------------------------
Just correcting the English. Thanks to those who noticed the mistake.
John
∂06-Nov-87 0655 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Need refs for low-level (c/pascal) implementation of scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Nov 87 06:55:04 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 6 Nov 87 07:16:06 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA20724; Fri, 6 Nov 87 03:49:17 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Nov 87 05:03:52 GMT
From: mnetor!utzoo!yetti!oz@uunet.uu.net
Organization: York U. Computer Science
Subject: Need refs for low-level (c/pascal) implementation of scheme
Message-Id: <181@yetti.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am working on a subset scheme implementation in C, to run
everything in S&IoCP and LittleLisper. Are there any good
references for low-level (C/pascal) implementation of Scheme ?
All I have is Allen's extraordinary but (sigh) slightly
out-of-date book for concrete (i.e. non-meta-circular)
implementation details. [Oh, sure I have Cscheme, but reading
that code gives me migranes every time :-)]
Alternatively, any partial source code for subset/toy schemes
are appreciated.
I already have the reader, cons, gc and lotsa prims, but I am
somewhat stuck at the symbol table/oblist/environment list
level. I have the global oblist allright, but I am getting all
confused as to using it for primitive-environment scheme needs.
If I am missing something, hit me with it... It is all this
late-night hacking slowly eroding my neurons...
oz
--
You see things, and you say "WHY?" Usenet: [decvax|ihnp4]!utzoo!yetti!oz
But I dream things that never were; ......!seismo!mnetor!yetti!oz
and say "WHY NOT?" Bitnet: oz@[yusol|yulibra|yuyetti]
[Back To Methuselah] Bernard Shaw Phonet: [416] 736-5257 x 3976
∂07-Nov-87 1221 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU,@REAGAN.AI.MIT.EDU,@BU-CS.BU.EDU:gjc@bucsf.bu.edu low level "how to scheme"
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 87 12:21:43 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Nov 87 15:20:18 EST
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 7 Nov 87 15:17:25 EST
Received: from bu-cs.BU.EDU (BU-CS.BU.EDU) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 72230; 7 Nov 87 14:54:17 EST
Received: from bucsf (128.197.2.9) by bu-cs.BU.EDU (3.2/4.7)
id AA22685; Sat, 7 Nov 87 14:44:16 EST
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA16059; Sat, 7 Nov 87 14:48:58 est
Date: Sat, 7 Nov 87 14:48:58 est
From: gjc@bucsf.bu.edu (George J. Carrette)
Message-Id: <8711071948.AA16059@bucsf>
To: scheme@ai.ai.mit.edu
Subject: low level "how to scheme"
the best guide is in Structure and Interpretation of Computer Programs.
I have known more that one person who has taken the techniques
directly and written interpreters for scheme in various assembly
languages.
∂08-Nov-87 0241 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: low level "how to scheme"
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 87 02:41:01 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 8 Nov 87 05:16:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA04120; Sun, 8 Nov 87 01:35:49 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Nov 87 06:29:19 GMT
From: pattis@june.cs.washington.edu (Richard Pattis)
Organization: U of Washington, CSCI, Seattle
Subject: Re: low level "how to scheme"
Message-Id: <3558@uw-june.UUCP>
References: <8711071948.AA16059@bucsf>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I was told that George Springer (at Indiana?) is writing an introduction to
Scheme book that takes a more gentle approach to teaching the subject. Does
anyone out there know how to contact him on the net? I'd be interested in
hearing more about this project, and others like it.
Rich Pattis
∂08-Nov-87 1737 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Re: low level "how to scheme"
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 87 17:36:52 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 8 Nov 87 20:34:05 EST
Date: Sun, 8 Nov 87 20:30:29 est
From: George Springer <springer@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: low level "how to scheme"
George Springer can be reached with
springer@iuvax.cs.indiana.edu
He is writing a text that is being used by freshmen as an introductory
course in programming. The first 11 weeks are spent in Scheme and the
last four weeks introduce them to C. It is being used for the second
year and seems to be successful. Notes for the course are being written
and should be finished in a few months.
∂09-Nov-87 0112 @MC.LCS.MIT.EDU:mcvax!tcdcs!omahony@uunet.UU.NET Solution to Exercise 1.9
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 01:11:57 PST
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 9 Nov 87 04:11:24 EST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA11178; Mon, 9 Nov 87 04:07:48 EST
Received: by mcvax.cwi.nl; Mon, 9 Nov 87 09:52:45 +0100 (MET)
Received: from tcdcs by kestrel.Ukc.AC.UK with UUCP id aa18057;
9 Nov 87 7:59 GMT
Received: from csvax1 by csclnb.tcdcs.uucp id aa09172; 7 Nov 87 17:55 EST
Date: Sat, 7 Nov 87 17:55 GMT
From: "Donal O'Mahony - omahony@tcdcs.uucp" <mcvax!tcdcs!OMAHONY@uunet.UU.NET>
Subject: Solution to Exercise 1.9
To: scheme@mc.lcs.mit.edu
X-Vms-To: OMAHONY,IN"scheme@mc.lcs.mit.edu"
Message-Id: <8711071755.aa09172@csclnb.tcdcs.uucp>
Does anybody out there have a good solution to Exercise 1.9 on pg 39
of Structure & Interpretation of Computer Programs. It involves
writing a procedure that evolves an iterative process for solving
the count change problem.
I've tried a few times with no success.
Donal O'Mahony omahony@tcdcs.uucp
Computer Science Dept.,
Trinity College,
Dublin,
Ireland
∂09-Nov-87 0151 @MC.LCS.MIT.EDU:trainor@CS.UCLA.EDU Re: Solution to Exercise 1.9
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 01:51:40 PST
Received: from lanai.cs.ucla.edu (TCP 20030216034) by MC.LCS.MIT.EDU 9 Nov 87 04:41:50 EST
Return-Path: <trainor@CS.UCLA.EDU>
Received: by lanai.cs.ucla.edu (Sendmail 5.57.2/1.13)
id AA29785; Mon, 9 Nov 87 01:35:13 PST
Message-Id: <8711090935.AA29785@lanai.cs.ucla.edu>
To: "Donal O'Mahony - omahony@tcdcs.uucp" <mcvax!tcdcs!OMAHONY@uunet.UU.NET>
Cc: scheme@mc.lcs.mit.edu
Subject: Re: Solution to Exercise 1.9
In-Reply-To: Your message of Sat, 07 Nov 87 17:55:00 +0000.
<8711071755.aa09172@csclnb.tcdcs.uucp>
Date: Mon, 09 Nov 87 01:35:12 PST
From: Vulture of Light <trainor@CS.UCLA.EDU>
>Does anybody out there have a good solution to Exercise 1.9 on pg 39
>of Structure & Interpretation of Computer Programs.
Yes.
>I've tried a few times with no success.
Keep trying.
∂09-Nov-87 1033 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:dan@mitre-bedford.ARPA Removal from mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 10:33:29 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Nov 87 13:06:28 EST
Received: from mitre-bedford.ARPA (TCP 3200600102) by AI.AI.MIT.EDU 9 Nov 87 08:45:00 EST
Full-Name: Willhite
Message-Id: <8711091314.AA02071@mitre-bedford.ARPA>
Posted-From: The MITRE Corp., Bedford, MA
To: scheme@ai.ai.mit.edu
From: dan@mitre-bedford.ARPA
Subject: Removal from mailing list
Date: Mon, 09 Nov 87 08:14:29 EST
Sender: dan@mitre-bedford.ARPA
Please remove me from the scheme mailing list.
Thank you,
Daniel Willhite
The MITRE Corporation
dan@mitre-bedford.arpa
∂09-Nov-87 1920 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Text
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 19:20:28 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 9 Nov 87 22:19:56 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA11052; Mon, 9 Nov 87 19:00:03 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 Nov 87 20:07:49 GMT
From: PT.CS.CMU.EDU!cadre!pitt!cisunx!adbst@cs.rochester.edu (Andrew D. Bowen)
Organization: Univ. of Pittsburgh, Comp & Info Sys
Subject: Scheme Text
Message-Id: <5141@cisunx.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
If you are science oriented, then the book, Structure and Interpretation
of Computer Programs by Abelson and Sussman is very good. It is
published by the MIT press.
Andy Bowen
Dept. of Electrical Engineering
University of Pittsburgh
∂10-Nov-87 0953 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Wanted: SCOOPS info
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 09:53:18 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Nov 87 12:52:20 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA26261; Tue, 10 Nov 87 09:19:28 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Nov 87 03:34:00 GMT
From: render@b.cs.uiuc.edu
Subject: Wanted: SCOOPS info
Message-Id: <189900001@uiucdcsb>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I'm relatively new to scheme, and I have taken on a class project which
I plan to implement in SCOOPS. The version we have (for Cscheme) is
apparently incorrect as it doesn't accept simple requests to create
instances. Does anyone know of a recent public domain version which
might have corrected these bugs? Thanks for any info.
Hal Render
University of Illinois at Urbana-Champaign
render@a.cs.uiuc.edu (ARPA)
{seismo,pur-ee}!uiucdcs!render (USENET)
∂10-Nov-87 2257 @MC.LCS.MIT.EDU:lls@mimsy.umd.edu Please remove me from the mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 22:57:41 PST
Received: from mimsy.umd.edu (TCP 20002100010) by MC.LCS.MIT.EDU 11 Nov 87 01:56:23 EST
Received: by mimsy.umd.edu (5.58/4.7)
id AA19763; Tue, 10 Nov 87 07:45:27 EST
Date: Tue, 10 Nov 87 07:45:27 EST
From: Lauren L. Smith <lls@mimsy.umd.edu>
Message-Id: <8711101245.AA19763@mimsy.umd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Please remove me from the mailing list
I sent a request to scheme-request@mc.lcs.mit.edu to be deleted from
the mailing list - However, I'm still getting mail. Could you please
delete (lls@mimsy.umd.edu)? I prefer using the bboard on the net.
Thank you,
Lauren Smith
∂12-Nov-87 2255 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu What is Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 22:52:13 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Nov 87 10:25:19 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA27604; Thu, 12 Nov 87 07:18:16 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 Nov 87 16:01:22 GMT
From: necntc!linus!philabs!hhb!lee@ames.arpa (lee daniels)
Organization: HHB Systems, Mahwah, NJ
Subject: What is Scheme?
Message-Id: <696@hhb.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
What is Scheme, anyway?
Lee Daniels
HHB Systems
1000 Wyckoff Avenue
Mahwah, N.J. 07430
∂15-Nov-87 0159 NET-ORIGIN@MC.LCS.MIT.EDU Extend-Syntax for Everybody!
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 01:59:39 PST
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 NOV 87 07:56:00 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA15539@EDDIE.MIT.EDU>; Sat, 14 Nov 87 07:51:07 EST
Received: by xanth.cs.odu.edu (5.51/odu-gateway)
id AA25053; Sat, 14 Nov 87 03:51:34 EST
To:
Path: xanth!mcnc!gatech!hao!ames!ucbcad!zodiac!jdevries
From: jdevries@zodiac.ads.com (Jeff De Vries)
Newsgroups: comp.lang.lisp,mail.scheme
Subject: Extend-Syntax for Everybody!
Message-Id: <898@zodiac.UUCP>
Date: 13 Nov 87 21:44:20 GMT
Sender: news@zodiac.UUCP
Reply-To: jdevries@ADS.ARPA (Jeff De Vries)
Distribution: world
Organization: Advanced Decision Systems, Mt. View, CA (415) 941-3912
Lines: 377
By popular demand I have decided to go ahead and post the code for the
MacScheme version of extend-syntax. I had (have?) over 40 requests,
(some of which I can't seem to respond to due to always getting bounced),
plus other indicators that some people are just waiting for me to post it.
To those of you who have no interest in this, I apologize for the long
posting, (just hit your 'junk' key, if you have one).
But first, a few words:
The theoretical work and basic design behind extend-syntax was the work of
Eugene Kohlbecker. It was part of his Ph.D. dissertation, "Syntactic
Extensions in the Programming Language LISP", (Indiana University, 1986).
The enhanced version of the code that I used for the MacScheme version was
written by R. Kent Dybvig, and made available by him.
A more complete description of Kent's book is:
The Scheme Programming Language
R. Kent Dybvig
Prentice-Hall, Englewood Cliffs, New Jersey, 07632 (1987)
Library of Congress Catalog Card Number 86-63489
If you are using a version of Scheme other than MacScheme, you should be
able to convert this to whatever you are using. The main thing to change
is the way macros are defined. There are two macros, (extend-syntax and
extend-syntax/code), plus the macro defining form embedded inside of
extend-syntax. You may have to add (or delete) a support function or two.
ENJOY!!! :-)
Jeff
------------------------distribution starts here------------------------
Here is the code for extend-syntax. It includes the code for:
when
unless
andmap
syntax-match?
extend-syntax
extend-syntax/code
To load it, just enter
(load "extend.sch")
It takes a while to load and will print out:
when
unless
andmap
syntax-match?
extend-syntax/code
(note: extend-syntax gets compiled even though its name doesn't get
printed. It doesn't get printed because it's inside the LET)
After you load it, you may want to do a (dumpheap) See the MacScheme
manual for details.
The documentation for extend-syntax is in "The Scheme Programming
Language" by R. Kent Dybvig. Buy the book. (No, I don't get any
kickbacks). extend-syntax/code returns the source for the
lambda expression that would have been bound to the macro, which is
helpful during debugging and for getting a feel for how extend-syntax
works. You might try (pretty-print (extend-syntax/code --- etc. if
you want to be able to read it easily. Note that the output isn't
directly useable because of gensym'ed variables and how MacScheme
prints quasiquotes, etc. Use extend-syntax to make the macros.
If you have any comments or problems, feel free to contact me. I won't
promise anything, but I'll give it a look. If you port the code to another
version of Scheme, I would be interested in hearing about it.
Jeff De Vries
(ARPA: jdevries@ads.arpa)
DISCLAIMER: All the usual stuff...
-----------------------------snip here---------------------------------
;;; extend.sch
;;; Copyright (C) 1987 Cadence Research Systems
;;; Permission to copy this software, in whole or in part, to use this
;;; software for any lawful noncommercial purpose, and to redistribute
;;; this software is granted subject to the restriction that all copies
;;; made of this software must include this copyright notice in full.
;;; Cadence makes no warranties or representations of any kind, either
;;; express or implied, including but not limited to implied warranties
;;; of merchantability or fitness for any particular purpose.
;;; The basic design of extend-syntax is due to Eugene Kohlbecker. See
;;; "E. Kohlbecker: Syntactic Extensions in the Programming Language Lisp",
;;; Ph.D. Dissertation, Indiana University, 1986." The structure of "with"
;;; pattern/value clauses, the method for compiling extend-syntax into
;;; Scheme code, and the actual implementation are due to Kent Dybvig.
;;; Made available courtesy R. Kent Dybvig
;;; MacScheme conversion by Jeff De Vries
;;; note: requires the use of MacScheme Version 1.2 or greater
;;; the following routines are provided for compatibility with TSPL:
(macro when
(lambda (args)
`(if ,(cadr args)
(begin ,@(cddr args))
#f)))
(macro unless
(lambda (args)
`(if ,(cadr args)
#t
(begin ,@(cddr args)))))
(define (andmap p . args)
;; use "first-finish" rule
(let andmap ((args args) (value #t))
(if (let any-at-end? ((ls args))
(and (pair? ls)
(or (not (pair? (car ls)))
(any-at-end? (cdr ls)))))
value
(let ((value (apply p (map car args))))
(and value (andmap (map cdr args) value))))))
;;; syntax-match? is used by extend-syntax to choose among clauses and
;;; to check for syntactic errors. It is also available to the user.
(define syntax-match?
(lambda (keys pat exp)
(cond
((symbol? pat) (if (memq pat keys) (eq? exp pat) #t))
((pair? pat)
(if (equal? (cdr pat) '(...))
(let f ((lst exp))
(or (null? lst)
(and (pair? lst)
(syntax-match? keys (car pat) (car lst))
(f (cdr lst)))))
(and (pair? exp)
(syntax-match? keys (car pat) (car exp))
(syntax-match? keys (cdr pat) (cdr exp)))))
(else (equal? exp pat)))))
;;; The main code!
(let ()
(define id
(lambda (name access control)
(list name access control)))
(define id-name car)
(define id-access cadr)
(define id-control caddr)
(define loop
(lambda ()
(list '())))
(define loop-ids car)
(define loop-ids! set-car!)
(define c...rs
`((car caar . cdar)
(cdr cadr . cddr)
(caar caaar . cdaar)
(cadr caadr . cdadr)
(cdar cadar . cddar)
(cddr caddr . cdddr)
(caaar caaaar . cdaaar)
(caadr caaadr . cdaadr)
(cadar caadar . cdadar)
(caddr caaddr . cdaddr)
(cdaar cadaar . cddaar)
(cdadr cadadr . cddadr)
(cddar caddar . cdddar)
(cdddr cadddr . cddddr)))
(define add-car
(lambda (access)
(let ((x (and (pair? access) (assq (car access) c...rs))))
(if (null? x)
`(car ,access)
`(,(cadr x) ,@(cdr access))))))
(define add-cdr
(lambda (access)
(let ((x (and (pair? access) (assq (car access) c...rs))))
(if (null? x)
`(cdr ,access)
`(,(cddr x) ,@(cdr access))))))
(define parse
(lambda (keys pat acc cntl ids)
(cond
((symbol? pat)
(if (memq pat keys)
ids
(cons (id pat acc cntl) ids)))
((pair? pat)
(if (equal? (cdr pat) '(...))
(let ((x (gensym)))
(parse keys (car pat) x (id x acc cntl) ids))
(parse keys (car pat) (add-car acc) cntl
(parse keys (cdr pat) (add-cdr acc) cntl ids))))
(else ids))))
(define gen
(lambda (keys exp ids loops)
(cond
((symbol? exp)
(let ((id (lookup exp ids)))
(if (null? id)
exp
(begin
(add-control! (id-control id) loops)
(list 'unquote (id-access id))))))
((pair? exp)
(cond
((eq? (car exp) 'with)
(unless (syntax-match? '(with) '(with ((p x) ...) e) exp)
(error 'extend-syntax "invalid 'with' form" exp))
(list 'unquote
(gen-with
keys
(map car (cadr exp))
(map cadr (cadr exp))
(caddr exp)
ids
loops)))
((and (pair? (cdr exp)) (eq? (cadr exp) '...))
(let ((x (loop)))
(make-loop
x
(gen keys (car exp) ids (cons x loops))
(gen keys (cddr exp) ids loops))))
(else
(let ((a (gen keys (car exp) ids loops))
(d (gen keys (cdr exp) ids loops)))
(if (and (pair? d) (eq? (car d) 'unquote))
(list a (list 'unquote-splicing (cadr d)))
(cons a d))))))
(else exp))))
(define gen-with
(lambda (keys pats exps body ids loops)
(if (null? pats)
(make-quasi (gen keys body ids loops))
(let ((p (car pats)) (e (car exps)) (g (gensym)))
`(let ((,g ,(gen-quotes keys e ids loops)))
(if (syntax-match? '() ',p ,g)
,(gen-with
keys
(cdr pats)
(cdr exps)
body
(parse '() p g '() ids)
loops)
(error ',(car keys)
"does not fit 'with' pattern"
,g
',p)))))))
(define gen-quotes
(lambda (keys exp ids loops)
(cond
((syntax-match? '(quote) '(quote x) exp)
(make-quasi (gen keys (cadr exp) ids loops)))
((pair? exp)
(cons (gen-quotes keys (car exp) ids loops)
(gen-quotes keys (cdr exp) ids loops)))
(else exp))))
(define lookup
(lambda (sym ids)
(let loop ((ls ids))
(cond
((null? ls) #f)
((eq? (id-name (car ls)) sym) (car ls))
(else (loop (cdr ls)))))))
(define add-control!
(lambda (id loops)
(unless (null? id)
(when (null? loops)
(error 'extend-syntax "missing ellipsis in expansion"))
(let ((x (loop-ids (car loops))))
(unless (memq id x)
(loop-ids! (car loops) (cons id x))))
(add-control! (id-control id) (cdr loops)))))
(define make-loop
(lambda (loop body tail)
(let ((ids (loop-ids loop)))
(when (null? ids)
(error 'extend-syntax "extra ellipsis in expansion"))
(cond
((equal? body (list 'unquote (id-name (car ids))))
(if (null? tail)
(list 'unquote (id-access (car ids)))
(cons (list 'unquote-splicing (id-access (car ids)))
tail)))
((and (null? (cdr ids))
(syntax-match? '(unquote) '(unquote (f x)) body)
(eq? (cadadr body) (id-name (car ids))))
(let ((x `(map ,(caadr body) ,(id-access (car ids)))))
(if (null? tail)
(list 'unquote x)
(cons (list 'unquote-splicing x) tail))))
(else
(let ((x `(map (lambda ,(map id-name ids) ,(make-quasi body))
,@(map id-access ids))))
(if (null? tail)
(list 'unquote x)
(cons (list 'unquote-splicing x) tail))))))))
(define make-quasi
(lambda (exp)
(if (and (pair? exp) (eq? (car exp) 'unquote))
(cadr exp)
(list 'quasiquote exp))))
(define make-clause
(lambda (keys cl x)
(cond
((syntax-match? '() '(pat fender exp) cl)
(let ((pat (car cl)) (fender (cadr cl)) (exp (caddr cl)))
(let ((ids (parse keys pat x '() '())))
`((and (syntax-match? ',keys ',pat ,x)
,(gen-quotes keys fender ids '()))
,(make-quasi (gen keys exp ids '()))))))
((syntax-match? '() '(pat exp) cl)
(let ((pat (car cl)) (exp (cadr cl)))
(let ((ids (parse keys pat x '() '())))
`((syntax-match? ',keys ',pat ,x)
,(make-quasi (gen keys exp ids '()))))))
(else
(error 'extend-syntax "invalid clause" cl)))))
(define make-syntax
(let ((x (gensym "x")))
(lambda (keys clauses)
`(lambda (,x)
(cond
,@(map (lambda (cl) (make-clause keys cl x)) clauses)
(else
(error ',(car keys) "invalid syntax" ,x)))))))
(macro extend-syntax
(lambda (x)
(cond
((and
(syntax-match?
'(extend-syntax)
'(extend-syntax (key1 key2 ...) clause ...)
x)
(andmap symbol? `(,(caadr x) ,@(cdadr x))))
(let
((f (make-syntax `(,(caadr x) ,@(cdadr x)) (cddr x))))
(if (syntax-match? '() 'proc f)
`(macro ,(caadr x) ,f)
(error 'extend-syntax
"does not fit 'with' pattern"
f
'proc))))
(else (error 'extend-syntax "invalid syntax" x)))))
(macro extend-syntax/code
(lambda (x)
(cond
((and
(syntax-match?
'(extend-syntax/code)
'(extend-syntax/code (key1 key2 ...) clause ...)
x)
(andmap symbol? `(,(caadr x) ,@(cdadr x))))
(let
((f (make-syntax `(,(caadr x) ,@(cdadr x)) (cddr x))))
(if (syntax-match? '() 'proc f)
`',f
(error 'extend-syntax/code
"does not fit 'with' pattern"
f
'proc))))
(else (error 'extend-syntax/code "invalid syntax" x)))))
) ;;; end of let
;;; end extend.sch
∂23-Nov-87 1739 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [net%TUB.BITNET: Pretty printer]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 17:39:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Nov 87 20:40:03 EST
Date: Mon, 23 Nov 87 20:38:17 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [net%TUB.BITNET: Pretty printer]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <290381.871123.JAR@AI.AI.MIT.EDU>
[I have already sent him the pretty-printer from T, but I thought
I'd give other people a chance to reply. --JAR]
Date: Mon, 23 Nov 87 19:48:07 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
To: scheme-request at mc.lcs.mit.edu
Re: Pretty printer
I'm looking for a (possibly simple-minded) Scheme pretty printer that
is available for free. I have (almost) completed the implementation of
a Scheme interpreter, and it seems to work quite well so far, but
unfortunately I haven't ever been exposed to Lisp and similar languages
before, so the (probably trivial) task of writing something like a
pretty printer would certainly take me a day or longer. For certain
reasons I can't use the pretty printer that comes with CScheme.
Any help is appreciated.
--
Regards,
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
∂23-Nov-87 1816 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [net%TUB.BITNET: Questions]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 87 18:16:43 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Nov 87 20:41:48 EST
Date: Mon, 23 Nov 87 20:40:07 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [net%TUB.BITNET: Questions]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <290382.871123.JAR@AI.AI.MIT.EDU>
Could the responsible parties please answer these questions, and post
the questions and answers to the scheme mailing list? Thanks.
-Jonathan
Date: Mon, 23 Nov 87 19:28:38 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
To: scheme-request at mc.lcs.mit.edu
Re: Questions
I have two minor questions about the Revised↑3 Report of Scheme.
1) The report mentions two procedures (close-input-port <port>) and
(close-output-port <port>). I don't see why it is necessary to
have two procedures to close ports. Wouldn't it be sufficient
to have something like "close-port" that can be applied to both
types of ports?
2) What is the exact difference between (write-char <char>) and
(display <char>)? "write-char" seems to be redundant. Is "display"
supposed to terminate its output by a space or newline or something
like this?
I'm sorry if the answers are obvious; I'm relatively new to Scheme.
--
Regards,
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
∂24-Nov-87 0006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SICP Sources
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 00:06:44 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Nov 87 02:13:05 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA18776; Mon, 23 Nov 87 22:50:46 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Nov 87 05:52:07 GMT
From: iris!windley@ucdavis.ucdavis.edu (Phil Windley)
Organization: U.C. Davis - College of Engineering
Subject: SICP Sources
Message-Id: <564@ucdavis.ucdavis.edu>
References: <290381.871123.JAR@AI.AI.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is the code in SICP (Sussman and Abelson) available electronically? I
seeme to remember hearing it was on prep once, but I couldn't find it.
I'm especially interested in chapters 4 & 5 since I will be doing
those next quarter. Thanks.
Phil Windley
Robotics Research Lab
University of California, Davis
Phil Windley
Robotics Research Lab
University of California, Davis
∂24-Nov-87 0415 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU [net%TUB.BITNET: Questions]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 04:14:53 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 24 Nov 87 07:18:00 EST
Received: by KLEPH.AI.MIT.EDU; Mon, 23 Nov 87 21:53:31 est
Date: Mon, 23 Nov 87 21:53:31 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8711240253.AA21474@kleph>
To: net%TUB.BITNET@MITVMA.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Mon, 23 Nov 87 20:40:07 EST <290382.871123.JAR@AI.AI.MIT.EDU>
Subject: [net%TUB.BITNET: Questions]
Reply-To: cph@mc.lcs.mit.edu
Date: Mon, 23 Nov 87 19:28:38 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
I'll answer your second question and leave the first for someone else.
2) What is the exact difference between (write-char <char>) and
(display <char>)? "write-char" seems to be redundant. Is "display"
supposed to terminate its output by a space or newline or something
like this?
There are two reasons for this. First is the historical development
of the standard. Originally, when `display' was defined, its action
on characters was defined to be the same as `write'. So at that time
`write-char' was not redundant. Later `display' was changed to treat
characters specially, creating the redundancy.
Second, `display' is a generic operation, in the sense that it will
print any object. It recursively prints compound structures, treating
any imbedded strings and characters specially. Because of this, it is
a moderately expensive operation to perform, since it potentially will
have to do quite a bit of work. On the other hand, `write-char' is a
very simple operation, in fact the simplest output operation (all of
the other output procedures could be defined in terms of it). Because
of this it can be very efficiently implemented.
Finally, there is my own personal bias -- MIT Scheme has a
non-standard output procedure called `write-string', which accepts a
single string argument and prints it exactly as `display' would.
Using `write-char', `write-string', and `write', I've found that I
never need to use `display'. This is because all of the instances
where I would have used `display', I actually mean `write-string', so
I use the latter instead.
∂24-Nov-87 1018 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: [net%TUB.BITNET: Questions]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 10:18:50 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Nov 87 13:19:44 EST
Date: Tue, 24 Nov 87 13:14:07 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: cph%kleph.ai.mit.edu@RELAY.CS.NET
Subject: Re: [net%TUB.BITNET: Questions]
Cc: rrrs-authors@mc.lcs.mit.edu
From: Chris Hanson <cph%kleph.ai.mit.edu@RELAY.CS.NET>
To: net%TUB.BITNET@MITVMA.MIT.EDU
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: [net%TUB.BITNET: Questions]
Date: Mon, 23 Nov 87 19:28:38 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
I'll answer your second question and leave the first for someone else.
2) What is the exact difference between (write-char <char>) and
(display <char>)? "write-char" seems to be redundant. Is "display"
supposed to terminate its output by a space or newline or something
like this?
Second, `display' is a generic operation, in the sense that it will
print any object. It recursively prints compound structures, treating
any imbedded strings and characters specially. Because of this, it is
a moderately expensive operation to perform, since it potentially will
have to do quite a bit of work. On the other hand, `write-char' is a
very simple operation, in fact the simplest output operation (all of
the other output procedures could be defined in terms of it). Because
of this it can be very efficiently implemented.
There is a more important reason related to the fact that "display" is a
generic operation. Character objects are not guaranteed to be distinct
from other objects, although they are in some implementations. So, for
example, it is possible to represent them as a range of integers or as
unit-length strings. Since display will always choose to print integers
as integers and strings as strings, the procedure "write-char" is needed
to force a character so represented to be treated as a character.
∂24-Nov-87 1414 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [dyb: [net%TUB.BITNET: Questions]]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 14:14:36 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Nov 87 17:04:24 EST
Date: Tue, 24 Nov 87 17:02:22 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [dyb: [net%TUB.BITNET: Questions]]
To: net%TUB.BITNET@MITVMA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
Message-ID: <290866.871124.JAR@AI.AI.MIT.EDU>
Date: Tue, 24 Nov 87 13:14:07 est
From: R. Kent Dybvig <dyb at iuvax.cs.indiana.edu>
...
Date: Mon, 23 Nov 87 19:28:38 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
To: scheme-request@mc.lcs.mit.edu
What is the exact difference between (write-char <char>) and
(display <char>)? "write-char" seems to be redundant. Is "display"
supposed to terminate its output by a space or newline or something
like this?
... Character objects are not guaranteed to be distinct
from other objects, although they are in some implementations. So, for
example, it is possible to represent them as a range of integers or as
unit-length strings. Since display will always choose to print integers
as integers and strings as strings, the procedure "write-char" is needed
to force a character so represented to be treated as a character.
∂27-Nov-87 2137 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCHEME interpreter in Common Lisp?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Nov 87 21:37:17 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Nov 87 00:37:03 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA15661; Fri, 27 Nov 87 21:27:31 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Nov 87 05:08:26 GMT
From: stever@EDDIE.MIT.EDU (Stephen Robbins)
Organization: MIT EE/CS Computer Facility, Cambridge, MA
Subject: SCHEME interpreter in Common Lisp?
Message-Id: <7516@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi,
I'm looking for a SCHEME interpreter/compiler written in Common Lisp,
for instructional use on Symbolics LISPMs. My main concern is that it
be properly tail-recursive. Speed isn't much of a priority, since
I'll be using it mainly for teaching.
What I've done in the interim is to write a Common Lisp function
which uses a giant TAGBODY and follows the interpreter given in
Structure and Interpretation of Computer Programs. Thanks to the
TAGBODY, I can get tail recursion by using (GO). But this requires
implementing an interpreter, rather than having a way to compile
SCHEME to Common Lisp.
Does anyone have an implementation that might help me?
- Stephen
P.S. If anyone is interested in a copy of my little hack, I'll be
glad to pass it along. I'm probably going to continue expanding it in
my spare time...
--
We live in a society that has replaced wisdom with knowledge, and
is trying to replace knowledge with information. My goal is wisdom.
∂30-Nov-87 1451 @MC.LCS.MIT.EDU:MUSE@XX.LCS.MIT.EDU PC Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 87 14:50:53 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Nov 87 17:51:43 EST
Date: Mon 30 Nov 87 17:46:31-EST
From: Tom Cloney <MUSE@XX.LCS.MIT.EDU>
Subject: PC Scheme
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12354833344.31.MUSE@XX.LCS.MIT.EDU>
F
-------
∂01-Dec-87 1234 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:MUSE@OZ.AI.MIT.EDU PC Scheme hardware interfacing
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 12:33:55 PST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 1 Dec 87 15:34:27 EST
Received: from ENIAC.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 98874; Tue 1-Dec-87 15:28:22 EST
Date: Tue, 1 Dec 87 15:28 EST
From: Tom Cloney <MUSE@OZ.AI.MIT.EDU>
Subject: PC Scheme hardware interfacing
To: scheme@MC.LCS.MIT.EDU
Message-ID: <871201152828.1.MUSE@ENIAC.LCS.MIT.EDU>
What are good places to look (and people to ask) about details of
the PC Scheme implementation, such as how ports are constructed,
whether there are existing primitives for reading and writing memory
locations, and what useful code is floating around locally?
I am trying to interest people in my research group in using Scheme
for what hacking is done on the IBMPC, but the existing documentation
doesn't say much about hardware interfacing unless it is done through
interrupts or XLI.
I am particularly interested in anything specific to the T3100, such as
COM1 and parallel port drivers.
Please add me to the mailing list.
Thanks,
Tom Cloney (Muse@Oz)
∂01-Dec-87 1510 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu The mini-SCHEME interpreter I've sent to some people
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 15:10:10 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 Dec 87 18:09:23 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA29211; Tue, 1 Dec 87 14:06:31 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Dec 87 19:27:13 GMT
From: stever@EDDIE.MIT.EDU (Stephen Robbins)
Organization: MIT EE/CS Computer Facility, Cambridge, MA
Subject: The mini-SCHEME interpreter I've sent to some people
Message-Id: <7554@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Several people in this mailing list have requested copies of my
little SCHEME interpreter. I sent out several which had a
rather severe bug.
I'm afraid I've lost the list of people who requested copies. If
you received a buggy copy, please let me know and I'll mail a new one.
Thank you,
Stephen
--
We live in a society that has replaced wisdom with knowledge, and
is trying to replace knowledge with information. My goal is wisdom.
∂01-Dec-87 1610 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp is Crisp! Lisp is Crisp! Lisp is Crisp! Lisp is Crisp!
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 16:10:08 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 Dec 87 19:11:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA01857; Tue, 1 Dec 87 15:58:44 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Dec 87 20:36:05 GMT
From: mind!apoorva@princeton.edu (Apoorva Muralidhara)
Organization: Cognitive Science, Princeton University
Subject: Lisp is Crisp! Lisp is Crisp! Lisp is Crisp! Lisp is Crisp!
Message-Id: <1409@mind.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Any fellow applicativists out there?
--Apoorva/Applicativist Revolutionary Underground
[Death to the side effects!]
∂01-Dec-87 1645 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com two questions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 16:45:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Dec 87 19:24:43 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa15361; 1 Dec 87 18:54 EST
Received: from tektronix.tek.com by RELAY.CS.NET id as20460; 1 Dec 87 18:48 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA04487; Tue, 1 Dec 87 15:22:48 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA27353; Tue, 1 Dec 87 15:21:07 PST
Message-Id: <8712012321.AA27353@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Cc: net%tub.bitnet@RELAY.CS.NET
Subject: two questions
Date: 01 Dec 87 15:21:05 PST (Tue)
From: willc%tekchips.tek.com@RELAY.CS.NET
>Could the responsible parties please answer these questions, and post
>the questions and answers to the scheme mailing list? Thanks.
>-Jonathan
Maybe that should be "irresponsible parties". I guess someone has to take
the rap, so here are my excuses.
1) The report mentions two procedures (close-input-port <port>) and
(close-output-port <port>). I don't see why it is necessary to
have two procedures to close ports. Wouldn't it be sufficient
to have something like "close-port" that can be applied to both
types of ports?
Yes, and I would not be surprised if most Scheme implementations do it
that way internally. OPEN-INPUT-FILE and OPEN-OUTPUT-FILE need to be
distinct, and I guess it seemed more symmetric for them to have distinct
"inverses".
2) What is the exact difference between (write-char <char>) and
(display <char>)? "write-char" seems to be redundant. Is "display"
supposed to terminate its output by a space or newline or something
like this?
Chris Hanson noted the historical fact that DISPLAY originally acted like
WRITE on characters, so WRITE-CHAR was once necessary for that reason. He
noted also that DISPLAY, being generic, is likely to be much less efficient
than WRITE-CHAR. Kent Dybvig pointed out that characters are not guaranteed
to be distinct from other data types, say small integers or strings of one
character, so WRITE-CHAR is the only portable way you can write a character
itself as opposed to some representation of the character. Thus WRITE-CHAR
remains necessary.
Peace,
William Clinger
∂02-Dec-87 1640 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: (Lisp is Crisp!)↑4
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 16:40:46 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 Dec 87 19:42:10 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA00440; Wed, 2 Dec 87 15:55:54 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Dec 87 18:40:42 GMT
From: umich!dwt@umix.cc.umich.edu (David West)
Organization: University of Michigan EECS Dept. Ann Arbor
Subject: Re: (Lisp is Crisp!)↑4
Message-Id: <584@zippy.eecs.umich.edu>
References: <1409@mind.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <1409@mind.UUCP> apoorva@mind.UUCP (Apoorva Muralidhara) writes:
>
>Any fellow applicativists out there?
> --Apoorva/Applicativist Revolutionary Underground
>
>[Death to the side effects!]
Applicativity has its advantages, but it needs
1) a more humanly-comprehensible syntax than LISP; Miranda (TM) is excellent
in this respect, but the (TM) will probably doom it, as apparently was the
case with COMIT (TM).
2) Some syntactic means for preventing argumentsfrom getting unreadably
numerous just to pass something down to where it's finally used.
3) a public domain portable optimizing implementation (though all three of
these attributes together is perhaps too much to hope for.) The thing
that made Pascal fly was the availability of the Zurich P-compiler
initially, then Turbo. What the world needs now is GNU Miranda or (ok,
I'll be more reasonable) GNU ML. (Richard is probably too busy, though...)
Turbo ML?
-David West dwt@zippy.eecs.umich.edu
[Nested parentheses - just say no]
∂02-Dec-87 1858 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 18:58:23 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 Dec 87 21:57:45 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA03603; Wed, 2 Dec 87 18:21:31 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Dec 87 19:14:11 GMT
From: johnson@mimsy.umd.edu (Greg Johnson)
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Subject: data structures <--> functions
Message-Id: <9597@mimsy.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In Lisp(s), one is able to build a list whose `car' is the atom `lambda',
and then apply this object as a function to arguments:
(setq add2 '(lambda (x) (+ 2 x)))
(lambda (x) (+ 2 x))
(add2 45)
47
Scheme seems to lack this property. So does ML. In short, the pun that
exists in classic lisps between data structures and functions seems to have
been abandoned. Unless you write an interpreter subroutine, you cannot have
a program build a data structure and then use it as an executable function.
Is there some `sanctioned' way that a data structure that `looks' like a
lambda abstraction can be turned into a closure? I tried opening a file for
writing, writing the object out, closing the file, opening it for reading,
and reading the object in using various read primitives, but that didn't
work.
The C Scheme interpreter I have (release 4.1.1) has an undocumented function
named `eval' (surprise!) that appears to take two arguments, an object
to be interpreted and an environment relative to which the interpretation
should take place. By reading Scheme source code, functions to create
and manipulate environments can be found.
A more general question, for those well imbued in the Lisp culture: how
much of a loss is it (or rather, `would it be' if there is in fact some
sanctioned, clean, efficient way to do the above) not to have a mechanism
for lisp programs to build their own functions?
- Greg Johnson
johnson@mimsy.umd.edu
∂02-Dec-87 1953 @MC.LCS.MIT.EDU:gjc@bucsf.bu.edu in reply to "nested parens - just say no"
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 19:53:18 PST
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 2 Dec 87 22:53:53 EST
Received: from bucsf (128.197.2.9) by bu-it.BU.EDU (3.2/4.7)
id AA04875; Wed, 2 Dec 87 22:41:34 EST
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA17544; Wed, 2 Dec 87 22:46:12 est
Date: Wed, 2 Dec 87 22:46:12 est
From: gjc@bucsf.bu.edu (George J. Carrette)
Message-Id: <8712030346.AA17544@bucsf>
To: scheme@mc.lcs.mit.edu
Subject: in reply to "nested parens - just say no"
Ah, its messages like this that lighten my day.
But seriously folks, one thing I may be famous or damned for was
porting CGOL (based on a theory of parsing presented in: Pratt,
Vaughan R., ``Top Down Operator Precedence,'' ACM Symposium on
Principles of Programming Languages Boston, MA; October, 1973.
Yes, 14 years ago kiddies) from maclisp to the MIT lispmachine environment,
(so I probably did the port around 1981).
In short, this makes for an efficient way to extend the lisp syntax
toward the post algol abortions of the sixities and seventies, without
going through all the grammar compilation parsing hair that compiler
books of the same era where famous for spending 99% of their discourse
alotment on.
Others have moved this port of CGOL to at least the Symbolics, LMI,
and TI systems, so although it did not seem to show up in the franz
lisp distribution (unlike most of the other "maclisp extensions" at
the time) the code has not died.
Challenge: PORT CGOL to Scheme.
Hint: Its written in CGOL, not lisp.
∂02-Dec-87 2130 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 21:30:16 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Dec 87 00:07:38 EST
Date: Thu, 3 Dec 87 00:04:53 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: data structures <--> functions
To: johnson@MIMSY.UMD.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 2 Dec 87 19:14:11 GMT from johnson at mimsy.umd.edu (Greg Johnson)
Message-ID: <293963.871203.JAR@AI.AI.MIT.EDU>
Date: 2 Dec 87 19:14:11 GMT
From: johnson at mimsy.umd.edu (Greg Johnson)
I tried opening a file for writing, writing the object out, closing
the file, opening it for reading, and reading the object in using
various read primitives, but that didn't work.
Try something like
(define evaluate
(lambda (expression)
(call-with-output-file "temp"
(lambda (port)
(write `(define temp ,expression) port)))
(load "temp")
temp))
if you can manage to do so without making yourself ill.
∂03-Dec-87 1405 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu scheme benchmarks
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 14:04:56 PST
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 3 Dec 87 17:03:52 EST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28109; Thu, 3 Dec 87 14:55:57 MST
Received: by car.UTAH.EDU (4.30/4.40.2)
id AA19980; Thu, 3 Dec 87 14:56:37 mst
Date: Thu, 3 Dec 87 14:56:37 mst
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8712032156.AA19980@car.UTAH.EDU>
To: scheme@mc.lcs.mit.edu
Subject: scheme benchmarks
Is there a collection of results of scheme implementations running
significant benchmarks (something at least of the order of the Gabriel
benchmarks)?
I would be especially interested in how MacScheme, PC Scheme,
Chez Scheme, T, Vincennes Scheme and Cscheme compare with each other,
and against various Common Lisps running the same benchmarks.
Thanks,
Harold
∂03-Dec-87 1534 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Applicative languages? Anyone?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 15:33:58 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 3 Dec 87 18:32:24 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28209; Thu, 3 Dec 87 15:01:44 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Dec 87 17:40:17 GMT
From: hp-pcd!uoregon!markv@hplabs.hp.com (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: Applicative languages? Anyone?
Message-Id: <1202@uoregon.UUCP>
References: <1409@mind.UUCP>, <584@zippy.eecs.umich.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <584@zippy.eecs.umich.edu> dwt@zippy.eecs.umich.edu (David West) writes:
>Applicativity has its advantages, but it needs
>1) a more humanly-comprehensible syntax than LISP; Miranda (TM) is excellent
> in this respect, but the (TM) will probably doom it, as apparently was the
> case with COMIT (TM).
I have just recently become interested in functional/applicative
prramming. Having read several essays on Miranda, I am amazed
at the high level that programs can be described in Miranda.
While suffering from some problems (as noted by Dave West),
Miranda seems excellent for simple and not-so-simple programming
jobs.
>2) Some syntactic means for preventing argumentsfrom getting unreadably
> numerous just to pass something down to where it's finally used.
I have seen an extension to prolog for object-oriented
programming that works in much this way. Normally, object state
is represented by a structure which is passed and has fields
(corresponding to instance-vars) bound to new values as the
object changes state. This allows you to backtrack through
object changes, which would be hard to do if we used real
assignment. But passing these objects around is tedious, so
"syntactic sugar" is developped to carry the object state
around. For more info, see University of Oregon Tech Report
-TR-87-09, "Object Oriented Programming with First Order Logic",
by John S. Conery.
>3) a public domain portable optimizing implementation (though all three of
> these attributes together is perhaps too much to hope for.) The thing
> that made Pascal fly was the availability of the Zurich P-compiler
> initially, then Turbo. What the world needs now is GNU Miranda or (ok,
> I'll be more reasonable) GNU ML. (Richard is probably too busy, though...)
> Turbo ML?
Hmmm, not a bad idea. I have just acquired "Implementation of
Functional Programming Languages by Simon L. Peyton Jones, and
am much impressed by the depth/level of the text. Seeing as I
have to do a final thesis/project sometime :-) I might be
tempted to try a hand at an ML interpreter/compiler. I would
like to hear from anyone who is trying/has tried similar
projects.
markv@uoregon.edu \ Mark Terrence VandeWettering
University of Oregon \ ..!tektronix!uoregon!markv
Computer Science Dept. \
∂04-Dec-87 0219 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp Re: (Lisp is Crisp!)↑4
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 02:19:09 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Dec 87 05:18:38 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa28512; 4 Dec 87 5:05 EST
Received: from switzerland by RELAY.CS.NET id ak08082; 4 Dec 87 4:53 EST
Received: from ean by SWITZERLAND.CSNET id a015061; 3 Dec 87 17:07 MET
Date: 3 Dec 87 17:07 +0100
From: David West <umich!dwt@UMIX.CC.UMICH.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Message-ID: <584@zippy.eecs.umich.edu>
References: <1409@mind.UUCP>
Subject: Re: (Lisp is Crisp!)↑4
>Organization: University of Michigan EECS Dept. Ann Arbor
In article <1409@mind.UUCP> apoorva@mind.UUCP (Apoorva Muralidhara) writes:
>
>Any fellow applicativists out there?
> --Apoorva/Applicativist Revolutionary Underground
>
>[Death to the side effects!]
Applicativity has its advantages, but it needs
1) a more humanly-comprehensible syntax than LISP; Miranda (TM) is excellent
in this respect, but the (TM) will probably doom it, as apparently was the
case with COMIT (TM).
2) Some syntactic means for preventing argumentsfrom getting unreadably
numerous just to pass something down to where it's finally used.
3) a public domain portable optimizing implementation (though all three of
these attributes together is perhaps too much to hope for.) The thing
that made Pascal fly was the availability of the Zurich P-compiler
initially, then Turbo. What the world needs now is GNU Miranda or (ok,
I'll be more reasonable) GNU ML. (Richard is probably too busy, though...)
Turbo ML?
-David West dwt@zippy.eecs.umich.edu
[Nested parentheses - just say no]
∂04-Dec-87 0254 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp in reply to "nested parens - just say no"
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 02:53:53 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Dec 87 05:21:53 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa28546; 4 Dec 87 5:10 EST
Received: from switzerland by RELAY.CS.NET id ao08082; 4 Dec 87 4:55 EST
Received: from ean by SWITZERLAND.CSNET id a015317; 3 Dec 87 17:12 MET
Date: 3 Dec 87 17:12 +0100
From: "George J. Carrette" <gjc%bucsf.bu.edu@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
Message-ID: <8712030346.AA17544@bucsf>
Subject: in reply to "nested parens - just say no"
Ah, its messages like this that lighten my day.
But seriously folks, one thing I may be famous or damned for was
porting CGOL (based on a theory of parsing presented in: Pratt,
Vaughan R., ``Top Down Operator Precedence,'' ACM Symposium on
Principles of Programming Languages Boston, MA; October, 1973.
Yes, 14 years ago kiddies) from maclisp to the MIT lispmachine environment,
(so I probably did the port around 1981).
In short, this makes for an efficient way to extend the lisp syntax
toward the post algol abortions of the sixities and seventies, without
going through all the grammar compilation parsing hair that compiler
books of the same era where famous for spending 99% of their discourse
alotment on.
Others have moved this port of CGOL to at least the Symbolics, LMI,
and TI systems, so although it did not seem to show up in the franz
lisp distribution (unlike most of the other "maclisp extensions" at
the time) the code has not died.
Challenge: PORT CGOL to Scheme.
Hint: Its written in CGOL, not lisp.
∂04-Dec-87 0327 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 03:27:48 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Dec 87 05:22:00 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa28547; 4 Dec 87 5:10 EST
Received: from switzerland by RELAY.CS.NET id an08082; 4 Dec 87 4:55 EST
Received: from ean by SWITZERLAND.CSNET id a015179; 3 Dec 87 17:09 MET
Date: 3 Dec 87 17:09 +0100
From: Greg Johnson <johnson@mimsy.umd.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Message-ID: <9597@mimsy.UUCP>
Subject: data structures <--> functions
>Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
In Lisp(s), one is able to build a list whose `car' is the atom `lambda',
and then apply this object as a function to arguments:
(setq add2 '(lambda (x) (+ 2 x)))
(lambda (x) (+ 2 x))
(add2 45)
47
Scheme seems to lack this property. So does ML. In short, the pun that
exists in classic lisps between data structures and functions seems to have
been abandoned. Unless you write an interpreter subroutine, you cannot have
a program build a data structure and then use it as an executable function.
Is there some `sanctioned' way that a data structure that `looks' like a
lambda abstraction can be turned into a closure? I tried opening a file for
writing, writing the object out, closing the file, opening it for reading,
and reading the object in using various read primitives, but that didn't
work.
The C Scheme interpreter I have (release 4.1.1) has an undocumented function
named `eval' (surprise!) that appears to take two arguments, an object
to be interpreted and an environment relative to which the interpretation
should take place. By reading Scheme source code, functions to create
and manipulate environments can be found.
A more general question, for those well imbued in the Lisp culture: how
much of a loss is it (or rather, `would it be' if there is in fact some
sanctioned, clean, efficient way to do the above) not to have a mechanism
for lisp programs to build their own functions?
- Greg Johnson
johnson@mimsy.umd.edu
∂04-Dec-87 0401 @MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 04:00:53 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Dec 87 05:22:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab28546; 4 Dec 87 5:10 EST
Received: from switzerland by RELAY.CS.NET id ap08082; 4 Dec 87 4:56 EST
Received: from ean by SWITZERLAND.CSNET id a015364; 3 Dec 87 17:12 MET
Date: 3 Dec 87 17:12 +0100
From: Jonathan A Rees <JAR@mc.lcs.mit.edu>
To: johnson@mimsy.umd.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: <Msg of 2 Dec 87 19:14:11 GMT from johnson at mimsy.umd.edu (Greg Johnson)>
Message-ID: <293963.871203.JAR@AI.AI.MIT.EDU>
Subject: data structures <--> functions
Date: 2 Dec 87 19:14:11 GMT
From: johnson at mimsy.umd.edu (Greg Johnson)
I tried opening a file for writing, writing the object out, closing
the file, opening it for reading, and reading the object in using
various read primitives, but that didn't work.
Try something like
(define evaluate
(lambda (expression)
(call-with-output-file "temp"
(lambda (port)
(write `(define temp ,expression) port)))
(load "temp")
temp))
if you can manage to do so without making yourself ill.
∂04-Dec-87 0911 @MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu Applicative languages? Anyone?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 09:11:30 PST
Received: from b.cs.uiuc.edu (TCP 30001242402) by MC.LCS.MIT.EDU 4 Dec 87 12:09:17 EST
Received: by b.cs.uiuc.edu (UIUC-5.52/9.7)
id AA16314; Fri, 4 Dec 87 11:05:26 CST
Date: Fri, 4 Dec 87 11:05:26 CST
From: reddy@b.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8712041705.AA16314@b.cs.uiuc.edu>
To: scheme@mc.lcs.mit.edu
Subject: Applicative languages? Anyone?
>2) Some syntactic means for preventing argumentsfrom getting unreadably
> numerous just to pass something down to where it's finally used.
This is an interesting issue. I can think of two solutions right
away:
1. Package up all the arguments into a data structure (say an
association-list or an object), and then you only need to pass around
one data structure. (A good way to implement this data structure
would be as a "frame" a la Abelson and Sussman. I have tried earlier
to lobby for a "make-frame" primitive, like the "make-environment"
primitive, but was unsuccessful).
2. If this passing around of arguments is happening internal to a
function, use lexical scoping. Say f is a function that needs n
arguments. Define it as
(define (f x1 x2 ... xn)
(define (local-function1) ...)
...
(define (local-functionk) ...)
...)
The arguments x1,...,xn need not be passed to every local-function.
What is wrong with these solutios? Perhaps there is a different
problem that you have in mind, but haven't stated precisely yet.
Uday Reddy
University of Illinois
∂04-Dec-87 1400 @MC.LCS.MIT.EDU:sullivan@marge.math.binghamton.edu ML
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 13:58:52 PST
Received: from marge.math.binghamton.edu (TCP 20070401001) by MC.LCS.MIT.EDU 4 Dec 87 16:32:23 EST
Received: by marge.math.binghamton.edu (5.54)
id AA11927; Fri, 4 Dec 87 16:26:03 EST
From: fred sullivan <sullivan@marge.math.binghamton.edu>
Message-Id: <8712042126.AA11927@marge.math.binghamton.edu>
To: scheme@mc.lcs.mit.edu
Date: Fri, 4 Dec 87 16:26:01 EST
Subject: ML
X-Mailer: Elm [version 1.5]
I have heard rumors of a public domain (or free) ML interpreter. Does
anyone know about this? I have a VAX running Ultrix.
Thanks,
Fred Sullivan
Department of Mathematical Sciences
State University of New York at Binghamton
Binghamton, New York 13903
Email: sullivan@marge.math.binghamton.edu
∂04-Dec-87 1455 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@MITVMA.MIT.EDU:PS33@MCGILLA.NETNORTH
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 14:55:10 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 4 Dec 87 17:08:47 EST
Received: from MITVMA.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Fri 4 Dec 87 17:01:19-EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 04 Dec 87 16:47:10 EST
Received: from MCGILL.NETNORTH.CA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
id 9786; Fri, 04 Dec 87 16:47:08 EST
Received: by MCGILL1 (Mailer X1.24) id 9181; Fri, 04 Dec 87 16:42:16 EST
Date: FRI DEC 04, 1987 16.41.57
From: PS33%MCGILLA.BITNET@MITVMA.MIT.EDU
To: SCHEME@MC.LCS.MIT.EDU
From: Tom Shultz, Dept. of Psychology, McGill Univ.
ps33@mcgilla.bitnet
Subject: data structures <--> functions
Comments: To: Jonathan A Rees <JAR@mc.lcs.mit.edu>
Comments: cc: scheme@mc.lcs.mit.edu
In-Reply-To: <Msg of 3 Dec 87 17:12>
>>>Try something like
>>> (define evaluate
>>> (lambda (expression)
>>> (call-with-output-file "temp"
>>> (lambda (port)
>>> (write `(define temp ,expression) port)))
>>> (load "temp")
>>> temp))
>>>if you can manage to do so without making yourself ill.
One of the problems with this approach is that both "load"
and "eval" are supposed to be avoided by MacScheme users
wanting to take advantage of selective linking. Another problem
is the slowness of accessing an external file.
There really should be a better solution for this general problem
of having a program build a data structure and then execute it as
a function.
Any ideas?
∂04-Dec-87 1544 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU ML implementations
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 15:44:20 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 4 Dec 87 17:51:10 EST
Date: Fri 4 Dec 87 17:45:15-EST
From: Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>
Subject: ML implementations
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12355881689.66.NIKHIL@XX.LCS.MIT.EDU>
There are several implementations of ML in existence, differing in syntax
and semantics. I can name at least the following:
Edinburgh LCF: the ``original'' ML, circa late 1970's. Implemented in
Lisp, I believe, running on Dec-10s.
Unix ML: implemented by Luca Cardelli, Edinburgh, Bell Labs, and now
with DEC. Circa 1983. Syntax substantally influenced by the language
HOPE (Burstall and MacQueen). Compiles to FAM code (Luca's Functional
Abstract Machine) and thence to Vax native code.
LML: ``lazy ML''. Chalmers, Goteborg, Sweden (Tom Johnsson, Lennart
Augustsson, et. al.) Circa early 80's through today. LCF-like
syntax. No side-effects. Normal-order semantics. Compiles to abstract
machine, and then to Vax code (I think). They distribute it.
ML on Poly: David Mathews, Cambridge U. I don't know much about this
at all, except that it is implemented in the language Poly (Mathews'
language), incorporates persistence, and was in existence by 1985.
CAML: ``ML on the Categorical Abstract Machine''. Pierre Curien, et.
al., Univ of Paris. Circa 1986 through today. Subset of SML.
Compiles into CAM code, which I think is then translated into code for
the abstract machine developed by the ``Le Lisp'' folks.
And, perhaps, others. Apologies for omissions/inaccuracies in the
above list.
Beginning about 3-4 years ago, there was a major trans-Atlantic effort
to standardize ML. The result was SML: ``Standard ML''. Over the
last year or so, Dave MacQueen has been leading an effort at ATT Bell
Labs Murray Hill to implement a full SML compiler, written in SML
itself. This Monday (Nov 30), I learned from Dave that the compiler
is now available in beta-test, with sources, under license from ATT.
They're not trying to make money on it, so it's available cheap. It
runs on Vax/Unix at least, and maybe other machines. For details,
Dave can be contacted at
dbm%research.att.com@relay.cs.net
Rishiyur Nikhil (nikhil@xx.lcs.mit.edu)
-------
∂05-Dec-87 0210 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 87 02:10:03 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 5 Dec 87 05:05:49 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA07454; Sat, 5 Dec 87 02:02:53 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Dec 87 09:14:50 GMT
From: clyde!watmath!utgpu!jarvis.csri.toronto.edu!utai!jeem@rutgers.edu (Jim des Rivieres)
Organization: CSRI, University of Toronto
Subject: Re: data structures <--> functions
Message-Id: <4171@utai.UUCP>
References: <9597@mimsy.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <9597@mimsy.UUCP>, Greg Johnson asks how much of a loss would it be
to not have a mechanism for a lisp program to build a data structure and then
use it as an executable function?
An analogous question: How much of a loss would it be if all of a standard
stored-program computer's instructions had to reside in read-only memory?
The answer in both cases is that, while the vast majority of programmers would
not be directly inconvenienced by the lack of meta-level facilities , it would
be absolutely crippling to the system programmers that have to supply the
editors, compilers, linkers, and debuggers for that system.
∂05-Dec-87 1042 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 87 10:41:51 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 87 13:31:22 EST
Date: Sat, 5 Dec 87 13:34:17 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: data structures <--> functions
To: net%TUB.BITNET@MITVMA.MIT.EDU
cc: SCHEME@AI.AI.MIT.EDU, johnson@MIMSY.UMD.EDU
In-reply-to: Msg of Sat 5 Dec 87 14:06:59 +0100 from Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
Message-ID: <295045.871205.JAR@AI.AI.MIT.EDU>
Date: Sat, 5 Dec 87 14:06:59 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
To: scheme-request at mc.lcs.mit.edu
In Scheme you can easily achieve this by first evaluating the list and then
applying the result (a procedure) to the argument 45. Try the following:
(define add2 '(lambda (x) (+ 2 x)))
((eval add2 (the-environment)) 45) --> 47
There is some disagreement here over what exactly "Scheme" means. The
Revised↑3 Report has no EVAL procedure, and no (THE-ENVIRONMENT) special
form, but most Scheme implementations, apparently including the one
you're referring to, do have some kind of EVAL.
There were several reasons for excluding EVAL from the report, including
(a) there is no general agreement among Scheme designers as to what
environment EVAL should evaluate expressions with respect to, or
whether EVAL should take an explicit environment object as an
argument;
(b) it is not clear how to give a formal semantics to EVAL;
(c) EVAL interacts poorly with selective linking.
On the other hand, EVAL is undeniably useful in particular special
situations. (Most of the time that one would be tempted to use EVAL in
ancient Lisps, procedures or ad-hoc interpreters will serve in Scheme.)
EVAL will probably continue to be supported as an unofficial extension in
most implementations for the foreseeable future, and it will probably
continue to not be standardized for a while. The same is true of
macros. This is what happens when a standard is created by a committee.
∂07-Dec-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:09:27 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Dec 87 11:35:38 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA23411; Mon, 7 Dec 87 08:31:50 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Dec 87 09:36:00 GMT
From: otter!kers@hplabs.hp.com (Christopher Dollin)
Organization: hplabs-brc Bristol,UK.
Subject: Re: ML
Message-Id: <1510002@otter.HP.COM>
References: <8712042126.AA11927@marge.math.binghamton.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Well it's far from free but ...
If you buy Poplog from System's Designers, you get Sussex University's Poplog
environment with Pop11, Common Lisp, and Prolog. For not a lot extra you can
also have Poplog ML which an implementation of Standard ML, integrated into
Poplog in "the usual" way (ie integrated editor, on-line help).
Poplog also runs on Suns and HP 9000/300s and various other things.
Regards,
Kers (and will it put in my .signature too?)
∂07-Dec-87 2309 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:09:40 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Dec 87 11:36:03 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA23459; Mon, 7 Dec 87 08:33:09 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Dec 87 09:36:39 GMT
From: otter!kers@hplabs.hp.com (Christopher Dollin)
Organization: hplabs-brc Bristol,UK.
Subject: Re: ML
Message-Id: <1510003@otter.HP.COM>
References: <8712042126.AA11927@marge.math.binghamton.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
/ otter:comp.lang.scheme / kers@otter.HP.COM (Christopher Dollin) / 9:36 am Dec 7, 1987 /
Well it's far from free but ...
If you buy Poplog from System's Designers, you get Sussex University's Poplog
environment with Pop11, Common Lisp, and Prolog. For not a lot extra you can
also have Poplog ML which an implementation of Standard ML, integrated into
Poplog in "the usual" way (ie integrated editor, on-line help).
Poplog also runs on Suns and HP 9000/300s and various other things.
Regards,
Kers (and will it put in my .signature too?)
∂08-Dec-87 1620 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:20:43 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Dec 87 19:19:14 EST
Date: Tue, 8 Dec 87 19:23:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: data structures <--> functions
To: gjs@ZOHAR.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 6 Dec 87 01:51:10 est from gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-ID: <296594.871208.JAR@AI.AI.MIT.EDU>
Date: Sun, 6 Dec 87 01:51:10 est
From: gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
To: JAR at AI.AI.MIT.EDU
Re: data structures <--> functions
I really feel the need for EVAL (or ENCLOSE) quite seriously.
In particular I find the need to execute code that my programs write.
I wish this would be somehow solved.
How about if we put a meta-circular evaluator into the scheme library
that only knows about the standard R↑3RS global variables? Then if you
wanted to evaluate (+ (EXPT 2 23) 7), you could do
(LOAD "scheme-library/eval") ;or whatever
(EVAL-IN-R↑3RS-ENV '(+ (EXPT 2 23) 7))
Then, although particular implementations could choose to do "efficient"
implementations of this library routine, the beast is implementable in
R↑3 Scheme, so no one could complain about its semantics or any
threat to change the language definition itself.
The only problem is, what if the expression E has free variables (e.g.
FOO) that are defined in the current environment, but not in the R↑3RS
global environment? Well, if FOO isn't going to be assigned, how about
((EVAL-IN-R↑3RS-ENV '(LAMBDA (FOO ...) E))
FOO
...)
or, if it is going to be assigned, something more complicated, like
((EVAL-IN-R↑3RS-ENV '(LAMBDA (GET-FOO SET-FOO! ...) E'))
(LAMBDA () FOO)
(LAMBDA (VAL) (SET! FOO VAL))
...)
where E' = E with (GET-FOO) substituted for FOO and SET-FOO! substituted
for SET! FOO. Or, another entry point to the interpreter could be created
that would do substitutions of this kind automagically.
I think this would serve moderately well.
I'd be happy to submit such a package to the library (name and arguments
negotiable) if there's interest. This could at least hold us until we
can come to agreement over something that would give real level-crossing
access to environments.
∂09-Dec-87 0932 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU data structures <--> functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 09:32:51 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 9 Dec 87 12:08:19 EST
Received: by KLEPH.AI.MIT.EDU; Wed, 9 Dec 87 12:08:55 est
Date: Wed, 9 Dec 87 12:08:55 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8712091708.AA13269@kleph>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Tue, 8 Dec 87 19:23:30 EST <296594.871208.JAR@AI.AI.MIT.EDU>
Subject: data structures <--> functions
Reply-To: cph@mc.lcs.mit.edu
Date: Tue, 8 Dec 87 19:23:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Date: Sun, 6 Dec 87 01:51:10 est
From: gjs at ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
To: JAR at AI.AI.MIT.EDU
Re: data structures <--> functions
I really feel the need for EVAL (or ENCLOSE) quite seriously.
As I recall, the original problem with EVAL was just the decision
about whether or not there would be a second argument. We were unable
to come to concensus because there was no compatible way to solve the
problem without using optional arguments, which no one wanted to do.
Since everyone has EVAL, it seems silly to be tied up on this one
point. Maybe we should adopt a different procedure, perhaps called
STANDARD-EVAL or GLOBAL-EVAL, which took just one argument. This
would be identical to EVAL on systems without first-class
environments, and would supply a default environment on the others.
∂10-Dec-87 0750 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Request for MacScheme source for SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 07:50:07 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 10 Dec 87 10:43:06 EST
Date: Thu, 10 Dec 87 10:42:22 est
From: Carl Bruggeman <bruggema@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Request for MacScheme source for SCOOPS
Does anyone know if there is a version of SCOOPS available
for MacScheme? If you have one, could you email me the
source or tell me where I can access it thru ftp.
Thanks in advance,
Carl Bruggeman
bruggema@iuvax.cs.indiana.edu
∂10-Dec-87 1152 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Request for MacScheme source for SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Dec 87 11:52:12 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 10 Dec 87 10:43:06 EST
Date: Thu, 10 Dec 87 10:42:22 est
From: Carl Bruggeman <bruggema@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Request for MacScheme source for SCOOPS
Does anyone know if there is a version of SCOOPS available
for MacScheme? If you have one, could you email me the
source or tell me where I can access it thru ftp.
Thanks in advance,
Carl Bruggeman
bruggema@iuvax.cs.indiana.edu
∂14-Dec-87 2214 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Applicative languages? Anyone?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 22:14:41 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Dec 87 00:40:38 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28397; Mon, 14 Dec 87 20:35:40 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Dec 87 12:40:13 GMT
From: mcvax!ukc!its63b!csnjr@uunet.uu.net (Nick Rothwell)
Organization: LFCS, University of Edinburgh
Subject: Re: Applicative languages? Anyone?
Message-Id: <819@its63b.ed.ac.uk>
References: <1409@mind.UUCP>, <584@zippy.eecs.umich.edu>, <1202@uoregon.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <1202@uoregon.UUCP> markv@drizzle.UUCP (Mark VandeWettering) writes:
>In article <584@zippy.eecs.umich.edu> dwt@zippy.eecs.umich.edu (David West) writes:
>>Applicativity has its advantages, but it needs
>>1) ...
>>2) Some syntactic means for preventing argumentsfrom getting unreadably
>> numerous just to pass something down to where it's finally used.
>
> Hmmm, not a bad idea. I have just acquired "Implementation of
> Functional Programming Languages by Simon L. Peyton Jones, and
> am much impressed by the depth/level of the text. Seeing as I
> have to do a final thesis/project sometime :-) I might be
> tempted to try a hand at an ML interpreter/compiler. I would
> like to hear from anyone who is trying/has tried similar
> projects.
ML gives you objects with modifiable state, so that you don't need to
pass a state structure around with you. The disadvantage, of course, is
that you smash the applicative behaviour of the language -
whether it's worth it depends what you're trying to do.
Another way around this is to use type abstraction. That way, your
state structure is an abstract object with a few access functions to get
at the bits you need. I've always used the former approach, so I don't know
how far the latter approach gets you. It's quite possible to take non-
applicative features like assignment and abstract over them to build
structured objects with varying state, a la Smalltalk perhaps. This isn't
"dirty" functional programming - it's just using a functional language as if
it were a language of a different kind. I recently dedicated a lecture to the
structured use of side-effects in ML.
By the way, I have various little typecheckers and interpreters for tiny
functional languages lying around on-line somewhere, if you're interested.
All written in ML, of course.
--
Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk
<Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
"Nothing's forgotten. Nothing is ever forgotten." - Herne
∂14-Dec-87 2316 @MC.LCS.MIT.EDU,@RELAY.CS.NET:scheme-request@mc.lcs.mit.edu Re: Applicative languages? Anyone?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 23:16:06 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Dec 87 01:52:54 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa10391; 15 Dec 87 1:46 EST
Received: from switzerland by RELAY.CS.NET id aa05175; 15 Dec 87 1:41 EST
Received: from ean by SWITZERLAND.CSNET id a009814; 15 Dec 87 7:34 MET
Date: 15 Dec 87 7:33 +0100
From: Nick Rothwell <mcvax!ukc!its63b!csnjr@uunet.uu.net>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Message-ID: <819@its63b.ed.ac.uk>
References: <1409@mind.UUCP>, <584@zippy.eecs.umich.edu>, <1202@uoregon.UUCP>
Subject: Re: Applicative languages? Anyone?
>Organization: LFCS, University of Edinburgh
In article <1202@uoregon.UUCP> markv@drizzle.UUCP (Mark VandeWettering) writes:
>In article <584@zippy.eecs.umich.edu> dwt@zippy.eecs.umich.edu (David West) writes:
>>Applicativity has its advantages, but it needs
>>1) ...
>>2) Some syntactic means for preventing argumentsfrom getting unreadably
>> numerous just to pass something down to where it's finally used.
>
> Hmmm, not a bad idea. I have just acquired "Implementation of
> Functional Programming Languages by Simon L. Peyton Jones, and
> am much impressed by the depth/level of the text. Seeing as I
> have to do a final thesis/project sometime :-) I might be
> tempted to try a hand at an ML interpreter/compiler. I would
> like to hear from anyone who is trying/has tried similar
> projects.
ML gives you objects with modifiable state, so that you don't need to
pass a state structure around with you. The disadvantage, of course, is
that you smash the applicative behaviour of the language -
whether it's worth it depends what you're trying to do.
Another way around this is to use type abstraction. That way, your
state structure is an abstract object with a few access functions to get
at the bits you need. I've always used the former approach, so I don't know
how far the latter approach gets you. It's quite possible to take non-
applicative features like assignment and abstract over them to build
structured objects with varying state, a la Smalltalk perhaps. This isn't
"dirty" functional programming - it's just using a functional language as if
it were a language of a different kind. I recently dedicated a lecture to the
structured use of side-effects in ML.
By the way, I have various little typecheckers and interpreters for tiny
functional languages lying around on-line somewhere, if you're interested.
All written in ML, of course.
--
Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh.
nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk
<Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
"Nothing's forgotten. Nothing is ever forgotten." - Herne
∂14-Dec-87 2354 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Request for MacScheme source for SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Dec 87 23:54:17 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Dec 87 02:11:18 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA01244; Mon, 14 Dec 87 22:59:41 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 12 Dec 87 07:32:39 GMT
From: jh@ohio-state.arpa (Juha Hein{nen)
Organization: Tampere University of Technology, Finland
Subject: Re: Request for MacScheme source for SCOOPS
Message-Id: <2108@korppi.tut.fi>
References: <8712101554.AA15940@ucbvax.Berkeley.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
MacScheme doesn't have enviroments (atleast my version doesn't). It
would be straightforward to port SCOOPS if somebody first provides
environments. The hacks provided with MacScheme distribution are not
enough.
--
Juha Heinanen
Tampere Univ. of Technology
Finland
jh@tut.fi (Internet), tut!jh (UUCP)
∂15-Dec-87 1839 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Looking for C-Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Dec 87 18:39:09 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Dec 87 21:35:20 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA24174; Tue, 15 Dec 87 18:07:53 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 14 Dec 87 17:23:00 GMT
From: hp-pcd!hpcvlx!keith@hplabs.hp.com (Keith Taylor)
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Subject: Looking for C-Scheme
Message-Id: <530001@hpcvlx.HP.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Anybody know where I can get a copy of C-Scheme (I assume that's how it's
spelled). I'm interested in something that will run on HP 9000/300s or
HP 9000/800s (running HP-UX).
Thanks,
Keith M. Taylor
Hewlett-Packard
Corvallis, Oregon
hp-pcd!hpcvxkt!keith
∂17-Dec-87 0430 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu Re: SCOOPS for MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 04:30:19 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 16 Dec 87 18:27:44 EST
Date: Wed, 16 Dec 87 09:28:50 est
From: Carl Bruggeman <bruggema@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: SCOOPS for MacScheme
Last week I asked if anyone had ported SCOOPS to MacScheme.
I have received about half a dozen requests of the form,
"When you find them can you send me a copy". I finally
received an offer of source code but it may take some time
since I need to send a disk thru U.S. mail. Because only six
people have asked me for the sources, I currently plan to
distribute them via email rather than posting to this group.
If I receive more than a couple more requests after posting
this message I will assume there is enough interest in this
group to justify posting the sources here.
Carl Brugeman
bruggema@iuvax.cs.indiana.edu
∂17-Dec-87 0642 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:ZZZO@DHVRRZN1.BITNET NOTE from ZZZO
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 06:42:51 PST
Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 17 Dec 87 09:27:54 EST
Received: from DHVRRZN1.BITNET by CUNYVM.CUNY.EDU ; Thu, 17 Dec 87 09:26:34 EST
Date: Thu, 17 Dec 87 13:04:10 MEZ
To: scheme@mc.lcs.mit.EDU
From: ZZZO%DHVRRZN1.BITNET@CUNYVM.CUNY.EDU
Subject: NOTE from ZZZO
Date: 17 December 1987, 12:56:12 MEZ
From: Wolfgang Zocher (0511) 762-3684 ZZZO at DHVRRZN1
To: SCHEME at MC.LCS.MIT.EDU
Subject: CScheme on 68000 system
I'm just trying to install CScheme on an 68000 system (Atari running
OS-9) with 1MB memory. The microcode compiled very good, but the run-
time system will not load. When I try to make the bare-system, loading
stackp.bin. will cause an error and scheme says: bogus error vector...
and finished loading.
Is there anybody out there, who can help me with own experiences in
installing Cscheme on small 68000 systems??
Any idea is welcome
Wolfgang Zocher (ZZZO at DHVRRZN1.BITNET)
∂17-Dec-87 0958 @MC.LCS.MIT.EDU:brando%linus@mitre-bedford.ARPA SCOOPS for MacScheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 09:58:18 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 17 Dec 87 12:54:40 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by linus.research (3.2/4.7)
id AA03255; Thu, 17 Dec 87 12:53:34 EST
Date: Thu, 17 Dec 87 12:53:34 EST
From: Thom Brando <brando%linus@mitre-bedford.ARPA>
Posted-Date: Thu, 17 Dec 87 12:53:34 EST
Message-Id: <8712171753.AA03255@linus.research>
To: bruggema@iuvax.cs.indiana.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Carl Bruggeman's message of Wed, 16 Dec 87 09:28:50 est <8712170059.AA04028@mitre-bedford.ARPA>
Subject: SCOOPS for MacScheme
Yes, please post the sources to the scheme mailing list. If you don't please
email to me. Thanks.
∂17-Dec-87 1215 @MC.LCS.MIT.EDU:Esler.Opus@BCO-MULTICS.ARPA "box" data type in Chez Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 12:14:55 PST
Received: from BCO-MULTICS.ARPA (TCP 1200600037) by MC.LCS.MIT.EDU 17 Dec 87 15:11:01 EST
Date: Thu, 17 Dec 87 14:47 EST
From: Esler@BCO-MULTICS.ARPA
Subject: "box" data type in Chez Scheme.
Message-ID: <871217194738.501942@BCO-MULTICS.ARPA>
I was looking through the code for a small operating system, posted by
Chris Haynes recently. I found the functions "box", "set-box!", and
"swap-box!" used as primitives. Could someone familiar with Chez Scheme
explain what these do ? Equivalent functions written in standard (R↑3)
Scheme would be helpful.
Kevin Esler, Honeywell Bull Inc, Billerica, MA.
∂18-Dec-87 0715 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Byte code speed.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 07:15:36 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 18 Dec 87 09:58:24 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 18 Dec 87 09:57:48 EST
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 9458; Fri, 18 Dec 87 09:57:46 EST
Date: Fri, 18 Dec 87 15:47:25 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Subject: Byte code speed.
Date: 18 December 1987, 15:38:49 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
A while ago there was some mail about benchmarking Scheme, what's
new about that ?
Using the very simplistic (fib 20) test I was surprised to get very
good results on my M24 running TI PC Scheme 2.0, and quite good one
for MacScheme. This compared to straight interpreters. (Lisp interpreters,
vs Byte code interpreters).
My question is: Where can I get description of the byte code used by
TI PC scheme ? How about the compiler and the byte code interpreter ?
(I was quite surprised to see that my 8Mz 8086 run at the same speed than
the IBM 3090-150 cpu, the difference beeing TI PC Scheme on the tiny
box, and CScheme 5.3 on the big blue one) (around 5 sec for (fib 20)
on each).
Happy new year.
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@mitvma.mit.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂18-Dec-87 0830 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [ericson: MacScheme]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 08:30:24 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 18 Dec 87 11:14:12 EST
Date: Fri, 18 Dec 87 11:11:48 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [ericson: MacScheme]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <301537.871218.JAR@AI.AI.MIT.EDU>
Date: Wed, 16 Dec 87 14:38:19 EST
From: Lars Ericson <ericson at csd16.nyu.edu>
... I'd like
to hear from anybody who has tried to implement major T facilities (namely:
object/operation facility) in MacScheme.
Thank you,
Lars Ericson
ericson@csd16.nyu.edu
∂18-Dec-87 1024 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Speed
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 10:24:00 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 18 Dec 87 13:06:57 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 18 Dec 87 13:06:18 EST
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 0855; Fri, 18 Dec 87 13:06:14 EST
Date: Fri, 18 Dec 87 19:06:36 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Subject: Speed
+Date: Fri, 18 Dec 87 12:36:10 est
+From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
+To: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
+n-Reply-To: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU's message of Fri, 18 Dec 87
+ 15:47:25 GMT <8712181549.AA15413@zohar>
+Subject: Byte code speed.
+
+great... TI PC Scheme 3.0 is still faster!
+But on big problems (~100 pages of code) CScheme beats the
+PC scheme by a large amount.
Why on larger code ? (memory management ?)
As far as I have observed PC Scheme GC somewhat less than CSCheme,
From old popular wisdom (here, in France) it is said that the speed
of an interpreter is strongly related to the use of "CONS" for the
own use of the interpreter itself, and I have the feeling that
PC Scheme "conses" less than CScheme too. (I am surely wrong, it
is just a feeling. But the popular wisdom seems solid.)
(CScheme is somewhat more clever than some other Lisp I have on
my system, but around twice as slow, I am strongly thinking that
the difference between then is the fact that the other interpreter
does not "cons" at all)
Comments ?
Again my question: where can I find documents related to the
byte coding used in the popular Scheme (PC, Mac, C) ?
Extended question: I think that Scheme could be implemented with
incredible efficiency on modern Forth 32 bit chips, with stack
cache. Am I wrong ?
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@mitvma.mit.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂18-Dec-87 1401 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com Byte code speed
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 14:01:17 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Dec 87 16:44:18 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab19578; 18 Dec 87 16:13 EST
Received: from csc.ti.com by RELAY.CS.NET id ak29887; 18 Dec 87 16:07 EST
Received: from home by tilde id AA12877; Fri, 18 Dec 87 14:45:26 CST
Received: by home id AA05200; Fri, 18 Dec 87 14:44:28 CST
Date: Fri, 18 Dec 87 14:44:28 CST
From: David Bartley <bartley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8712182044.AA05200@home>
To: Scheme@mc.lcs.mit.edu
Cc: network%frsac11.bitnet@MITVMA.MIT.EDU,
Bartley%home.csc.ti.com@RELAY.CS.NET
Subject: Byte code speed
> From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu
> A while ago there was some mail about benchmarking Scheme, what's
> new about that ?
> Using the very simplistic (fib 20) test I was surprised to get very
> good results on my M24 running TI PC Scheme 2.0, and quite good one
> for MacScheme. This compared to straight interpreters. (Lisp interpreters,
> vs Byte code interpreters).
>
> My question is: Where can I get description of the byte code used by
> TI PC scheme ? How about the compiler and the byte code interpreter ?
> [...]
> Jean-Pierre H. Dumas
The only description of our work in the open literature is the paper
entitled ``The Implementation of PC Scheme'' in the proceedings of the
1986 ACM Conference on Lisp and Functional Programming, pp 86-93.
Although it doesn't disclose nitty-gritty details, the paper explains
the general nature of our byte-threaded-coded virtual machine and
gives some examples of its instruction set. It also has an overview
of the compiler and a listing of the 8088 code for the 5-instruction
``next'' operation of the emulator.
> As far as I have observed PC Scheme GC somewhat less than CSCheme,
> From old popular wisdom (here, in France) it is said that the speed
> of an interpreter is strongly related to the use of "CONS" for the
> own use of the interpreter itself, and I have the feeling that
> PC Scheme "conses" less than CScheme too. (I am surely wrong, it
> is just a feeling. But the popular wisdom seems solid.)
Our emulator does no consing on its own except to extend the stack
when it overflows. Until release 3.0, PC Scheme had no interpreter at
all. It now mixes interpretive and compiled execution in the
following way: An S-expression given to EVAL will be interpreted until
a subproblem is encountered which involves variable binding (e.g., a
LAMBDA, LET, or LETREC). The subproblem is then compiled and executed.
As a result, simple expressions like (DEFINE X 3) and X are interpret-
ed, but the procedure in (DEFINE F (LAMBDA (X) ...)) is always compiled.
Regards,
David Bartley
∂19-Dec-87 0739 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Speed
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 87 07:39:27 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 Dec 87 10:35:17 EST
Date: Sat, 19 Dec 87 10:32:57 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Sender: JAR0@AI.AI.MIT.EDU
Subject: Speed
To: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 18 Dec 87 19:06:36 GMT from NETWORK%FRSAC11.BITNET at MITVMA.MIT.EDU
Message-ID: <301942.871219.JAR0@AI.AI.MIT.EDU>
Date: Fri, 18 Dec 87 19:06:36 GMT
From: NETWORK%FRSAC11.BITNET at MITVMA.MIT.EDU
Again my question: where can I find documents related to the
byte coding used in the popular Scheme (PC, Mac, C) ?
The byte code interpreter and compiler used in MacScheme are described in
not much detail in a paper by Will Clinger in the 1984 Lisp and FP
Symposium proceedings, "The Scheme 311 compiler: An exercise in
denotational semantics."
∂19-Dec-87 0932 @MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu MacScheme SCOOPS Update
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 87 09:32:24 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 19 Dec 87 12:27:08 EST
Date: Sat, 19 Dec 87 12:26:02 est
From: Carl Bruggeman <bruggema@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: MacScheme SCOOPS Update
MacScheme SCOOPS Update:
1. I have received almost 40 requests for MacScheme SCOOPS
which means the sources should be posted rather than
mailed out.
2. John Ulrich is the person who did the implementation.
(I forgot to mention that in the last posting)
3. Will Clinger (of Semantic Microsystems) informed me that
a version of SCOOPS supplied by John Ulrich (same author)
is distributed with MacScheme starting with version 1.5
He also mentioned that it was not based on the TI source
and was not currently supported by Semantic Microsystems.
It seems to me the next step should be that someone with version
1.5 of MacScheme should post the sources (I don't have it). In order
to prevent multiple postings, it would be best if those who have the
ability to upload and post the sources to the net, send me mail to that
effect and I will give the OK to the first one who replies.
Due to the holiday, I will be off the net while out of town from
Dec 22 to Dec 27. Hopefully, the sources will be posted the week of
the 28th.
I would like to thank John Ulrich and William Clinger for their
help and information.
Carl Bruggeman
bruggema@iuvax.cs.indiana.edu
∂19-Dec-87 1310 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme Standard
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 87 13:10:12 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 19 Dec 87 15:55:20 EST
Date: Sat, 19 Dec 87 15:54:15 est
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Scheme Standard
The Microprocessor Standards Committee (MSC) of the IEEE Computer
Society is proposing formation of a working group for the purpose of
developing an IEEE Scheme standard. Some of the merits of such
a move follow:
PRO:
(1) An official standard will demonstrate the LEGITIMACY of Scheme in
the eyes of many. I expect this will frequently make the difference
in decisions by businesses and educators to adopt Scheme.
(2) It will increase Scheme's VISIBILITY. Word of standards
travels in many quarters where Scheme is hardly known.
(3) It will add MOTIVATION and DISCIPLINE to efforts at refining
Scheme. The last Scheme meeting we had indicated some need for more
discipline, and perhaps the lack of activity in this newsgroup of late
indicates need for more motivation.
(4) It will improve code portability (and publication uniformity).
The force of this point is reduced greatly by the existing Report,
which satisfies much of this need.
CON:
(5) Changes could be made that would be unreasonably expensive for
existing Scheme implementations to incorporate.
(6) Unnecessary and technically flawed features could be added.
(7) The specification could make Scheme rigid, cutting off
experimentation and research.
(8) Participants would be forced to cope with administrative hassles
and the time and monetary costs of travel to meetings.
The PROs speak for themselves, though comments that expand or
reinforce them are welcome. Let me address the CONs.
I believe (5) and (6) are the most serious concerns. They express
fear that the authors of the existing Report, who have been very
conservative in these respects, will "lose control" of the
standardization process. The best strategy for avoiding this is to
act promptly. By acting now, I believe the Report authors and others
of like mind will prevail both in voting numbers and administrative
matters. If we delay, others will almost certainly initiate the
standardization process (and thereby assume administrative control).
Also, the longer we wait the larger the Scheme community becomes. An
increasing number of converts to Scheme are apt to be defectors from
Common Lisp who want something simpler, but are also attached to all
sorts of things that we'd rather not see in Scheme. Many of these
folks will be from industry, with travel money and agendas that will
bring them to standards meetings.
Working group attendance is open to the public. Voting rights are
based on attendance at recent meetings, using a formula determined by
the Chair and acceptable to the MSC. A reasonable formula would give
voting rights initially to attendees of the previous Scheme Report
meetings and exclude others at their first meeting, and perhaps also
their second.
Official standardization may contribute a bit to the rigidity of a
language, but I believe this contribution will be much less than is
feared by some. Standards are typically revised every two years or
so, at least for the first few revisions, and it is certainly possible
to reverse earlier decisions. The best known standards are for the
best known languages, and the standards process for these languages
reflects the inertia already present as a result of long tradition.
A standard inevitably costs time and money, but I believe this can be
kept to tolerable levels. Though active working groups typically
meet about four times a year, by continuing our tradition of extensive
discussions on the net it should be possible to reduce this number to
two per year.
In balance, I feel the advantages of a standard clearly outweigh the
disadvantages, at least if we act reasonably soon so it does not get
out of control.
The MSC will consider the formation of a Scheme standardization
working group at its meeting on January 7th. I am being considered
for Chair, with Will Clinger for Vice-Chair. I have no "hidden
agenda". In the first year or so I would like to see the working
group endeavor to ratify approximately what we already have in the
R3RALS, with some clarifications and improvements that were intended
for a R4RALS in the same time frame. Standardization is a means to
consolidate and gain recognition for progress that has been made. It
draws upon and facilitates (rather than precludes) progress by less
institutionalized groups.
Comments are welcome.
-- Chris Haynes
∂19-Dec-87 1453 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Common Lisp in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 87 14:53:22 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Dec 87 17:44:05 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA27719; Sat, 19 Dec 87 14:37:04 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Dec 87 18:30:26 GMT
From: hplabsz!kempf@hplabs.hp.com (Jim Kempf)
Organization: Hewlett-Packard Laboratories
Subject: Common Lisp in Scheme?
Message-Id: <1252@hplabsz.HPL.HP.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I know about Jonathan Reese's Scheme in Common Lisp, but has anybody
implemented the opposite, Common Lisp in Scheme? Although I like the
clean semantics of Scheme, reality sometimes intrudes. I'm trying to
decide what Lisp to purchase for my AT, and TI's PC Scheme looks
attractive, especially compared to the overpriced AT Common Lisps
available. There is currently a port of Kyoto Common Lisp
underway, but it may take awhile and might end up not being any
cheaper than the already available crop, besides requiring a C
compiler.
Before I start hacking, anybody done it yet? Thanx!
Jim Kempf kempf@hplabs.hp.com
∂23-Dec-87 1553 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:U09254@UICVM.BITNET Scheme on CMS?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:53:23 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 Dec 87 15:21:54 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sun, 20 Dec 87 15:21:05 EST
Received: from UICVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
7428; Sun, 20 Dec 87 15:21:02 EST
Received: by UICVM (Mailer X1.24) id 8785; Sun, 20 Dec 87 14:20:07 CST
Date: Sun, 20 Dec 87 14:20:04 CST
From: Richard G Larson <U09254%UICVM.BITNET@MITVMA.MIT.EDU>
To: SCHEME@MC.LCS.MIT.EDU
Subject: Scheme on CMS?
I am looking for an implementation of Scheme which will run under IBM's
CMS operating system, and would be at least adequate for instructional use.
Various people have told me about Scheme front-ends for LISP, and about
C source for Scheme, but what I'd really like to know is whether anyone
has a MODULE file, etc which I can just drop in on CMS and have students
run it. (If such doesn't exist, I may have to do some work!)
∂23-Dec-87 1554 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Quasiquotation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:54:23 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 21 Dec 87 12:46:16 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 21 DEC 87 09:45:53 PST
Date: Mon, 21 Dec 87 09:44:58 PST
From: Pavel.pa@Xerox.COM
Subject: Quasiquotation
To: Scheme@mc.lcs.mit.edu
Message-ID: <871221-094553-5271@Xerox>
In the Revised↑3 Report, the grammar for quasiquotation expressions contains the
following production:
<list template D> ::= '<quasiquotation D>
Shouldn't this be
<list template D> ::= '<template D>
If not, why not? Also, why is there not a formal description of the semantics
of quasiquotation? I expected to find a precise definition in the section
giving the meanings of the other derived expression types, but there's nothing
there.
Pavel
∂23-Dec-87 1555 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com Object oriented programming in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:54:37 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Dec 87 16:51:29 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab02945; 21 Dec 87 16:08 EST
Received: from tektronix.tek.com by RELAY.CS.NET id bs09431; 21 Dec 87 15:54 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA16300; Mon, 21 Dec 87 12:16:59 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA06929; Mon, 21 Dec 87 12:15:32 PST
Date: Mon, 21 Dec 87 12:15:32 PST
From: Norman Adams <adams%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8712212015.AA06929@tekchips.TEK.COM>
Subject: Object oriented programming in Scheme
To: Lars Ericson <ericson%csd16.nyu.edu@RELAY.CS.NET>
Cc: scheme@mc.lcs.mit.edu
... I'd like
to hear from anybody who has tried to implement major T facilities (namely:
object/operation facility) in MacScheme.
Lars Ericson
ericson@csd16.nyu.edu
We have been experimenting with an object system based on T's. We have a
prototype implementation which we are evaluating, and we hope to have
something interesting to say in a few months. If all goes well, there is
some chance we will make source available for a sample implementation.
For those not familiar with the T object system: I eschew zealotry, but I
find the T approach (roughly closures + dispatch) more in the Scheme spirit
than anything in the Flavors family. Our changes to the T object system
are intended to make reasonably fast implementions possible. I would
consider an implementation reasonably fast if time to send a message, do
the method lookup, and pass control to the method, is less than the cost of
2 procedure calls in the worst case.
Our prototype is almost portable Scheme. We also have a faster version
that is quite specific to MacScheme. In a single, simple-minded benchmark,
compared to Ulrich's SCOOPS for MacScheme: the slow version is 20% the
speed, the faster version 2 or 3 times the speed (that's 5 procedure call
times). I would guess that, a few lines of assembly code, in a few key
places, are needed to make the MacScheme version "reasonably fast."
Norman Adams
Computer Research Lab
Tektronix Labs
-------
∂23-Dec-87 1555 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Object oriented programming in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:55:08 PST
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 21 Dec 87 22:09:19 EST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01076; 22 Dec 87 3:04 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 22 Dec 87 02:54:02 gmt
Message-Id: <5821.8712220254@aiva.ed.ac.uk>
To: adams <@relay.cs.net:adams@tekchips.tek.com>, scheme@mc.lcs.mit.edu
Subject: Re: Object oriented programming in Scheme
> Date: Mon, 21 Dec 87 12:15:32 PST
> From: Norman Adams <adams%com.tek.tekchips@net.cs.relay>
> We have been experimenting with an object system based on T's. [...]
> For those not familiar with the T object system: I eschew zealotry, but I
> find the T approach (roughly closures + dispatch) more in the Scheme spirit
> than anything in the Flavors family. Our changes to the T object system
> are intended to make reasonably fast implementions possible. I would
> consider an implementation reasonably fast if time to send a message, do
> the method lookup, and pass control to the method, is less than the cost of
> 2 procedure calls in the worst case.
This is interesting. If you don't mind saying something about your
implementation short of posting the source, I'd like to hear more.
It seems that you'll always have to do two procedure calls: one for
the operation and another for the method; three if you must also call a
handler that returns the method. And that still leaves the method lookup
itself. Flavors are about the same: one for the generic function, one
for the method, and about a call's worth (let's say) for looking up the
method. So, generic operations should have 2-3 times the overhead of an
equivalent function. But...
I recently implemented a T-like system in a completely straightforward
way in Common Lisp. I expected an operation to take 3 calls (operation,
handler, method), and timing with KCL on a VAX more or less confirmed
this. Here procedure calls were pretty expensive because they used
CALLS. I reasoned that they might be less dominant on a Sun, so I tried
again on a 3/260. To make this even less meaningful, I used Sun Common
Lisp this time. Calling a (generic) operation on an object with just one
method that returned the square of its arguement (this is what I was
doing) took 1.9 times longer then an equivalent function when both were
adjusted to take out the time required to square in-line. The total
time (10000 iterations) was still pretty small, though, so the results
may not be very meaningful. Why was the factor 1.9 instead of, say, 3?
I don't know.
In any case, it's difficult to implement T objects exactly. T objects
can be used as functions, and it's difficult to get most Lisp systems to
accept new kinds of function objects. So, since I couldn't do
(OBJECT fn . clauses)
I just implemented
(OBJECT . clauses)
I also had operation lookup based on the name of the operation. That
is, the dispatch function had (cond ((eq request 'op)) ...) instead of
(cond ((eq request op)) ...).
There's a certain elegance to this system that I didn't fully appreciate
until I'd used it for a while. Now I even miss the objects-as-functions.
Nonetheless, it is somewhat inflexible. You can't add new methods
incrementally (they must all be there in the OBJECT body), for example.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂23-Dec-87 1555 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme on CMS?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:55:24 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Dec 87 02:15:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA13746; Mon, 21 Dec 87 22:49:37 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Dec 87 17:43:41 GMT
From: ihnp4!alberta!calgary!jameson@ucbvax.Berkeley.EDU (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Re: Scheme on CMS?
Message-Id: <1267@vaxb.calgary.UUCP>
References: <8712202027.AA12866@ucbvax.Berkeley.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Several of the previous transactions appear to be seeking info on Scheme
implementations (and source) for various purposes. There appear to be
implementations of Scheme in Common Lisp and C, and maybe Common Lisp
implementations in Scheme, Scoops in Scheme, etc. etc.
I am also looking for an implementation (for a pc).
Could someone in the know please summarize what implementations are available,
for what machines, and if source is available at what cost?
I'd be happy to write the summary if someone will send me the info, but
it might be faster if somone more knowledgeable posted it directly.
As a fail safe, I'll summarize and post whatever I receive, whether or
not a knowledgeable sumary is posted.
Kevin ...{ihnp4,ubcvision}!alberta!calgary!vaxb!jameson
∂23-Dec-87 1556 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Byte code speed
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:55:57 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 09:13:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07692; 22 Dec 87 9:02 EST
Received: from tektronix.tek.com by RELAY.CS.NET id bc13377; 22 Dec 87 8:49 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA23859; Mon, 21 Dec 87 18:22:04 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA11558; Mon, 21 Dec 87 18:20:35 PST
Date: Mon, 21 Dec 87 18:20:35 PST
From: Will Clinger <willc%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8712220220.AA11558@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: Re: Byte code speed
David Bartley of TI wrote concerning PC Scheme:
Our emulator does no consing on its own except to extend the stack
when it overflows.
In the sense intended by David this is true of MacScheme 1.5 also, but
it depends on what is meant by "on its own". Besides the byte codes that
obviously allocate storage, such as cons and make-vector, there are byte
codes such as + that allocate storage on occasion. Of more interest are
the byte codes that create closures, that allocate lists for rest arguments,
and that allocate heap storage for variables that are closed over by lambda
expressions (unless this is done by the byte codes that create closures).
Clearly both PC Scheme and MacScheme have such byte codes.
I think the French wisdom is that fast interpreters do not allocate
garbage-collected storage for argument lists, implicit temporaries,
or continuations. This is true of PC Scheme and MacScheme 1.5, but older
versions of MacScheme were significantly slower than Version 1.5 in part
because they allocated continuations on the heap. It's interesting that
the original design back in 1983 called for stack-allocated continuations,
but the heap-allocated continuations that were used as a temporary
measure during the bootstrap ran fast enough (because of a fairly fast
garbage collector) that there wasn't much pressure to change it until the
native code compiler was added this spring (by Eric Ost and Anne Hartheimer).
Peace, Will Clinger
∂23-Dec-87 1556 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Some Remarks on Standardization (by someone who has been there)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:56:28 PST
Received: from SAIL.Stanford.EDU (TCP 4425400302) by MC.LCS.MIT.EDU 22 Dec 87 15:13:41 EST
Date: 22 Dec 87 0956 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Some Remarks on Standardization (by someone who has been there)
To: rrrs-authors@MC.LCS.MIT.EDU
Ladies and Gentlemen:
I have heard from my friend Will Clinger and read in a message from
Chris Haynes that the Scheme group is considering pursuing an IEEE
standard for Scheme. I made some remarks to Will about this by phone,
but I would like to address them to the group as a whole. Let me say at the
outset that I do not have any deep feelings about the matter, though I
cannot guarantee that I won't present strong arguments on one side or the
other in this message. The rest of this message largely follows the
outline of Chris Haynes's (Strunk and White) message:
1) Is a Standard Necessary?
Chris Haynes points out that some businesses and educators would adopt
Scheme if it were a standard language. The Europeans believe this is true
for Lisp in Europe. I do not believe it is true in the US. The problem
with adoption of Scheme and Lisp in the US by industry is that they are
too closely associated with AI, that it is difficult or impossible to have
Scheme/Lisp-written code be linkable into an executable image along with
other code, and that the speed of code is unacceptable. I think each of
these can be attacked, I think that solving the second reduces the
importance of the third, and that none of this has to do with
standarization.
Like it or not, Scheme is a dialect of Lisp. And right now Common Lisp is
regarded as the only Lisp worth considering. Now as you may know, I am not
a huge supporter of Common Lisp as a language - note my Critique paper with
Rod Brooks and my attempt with Will Clinger to push for a cleaner language
(in fact Scheme) at the ISO level (which attempt has not yet failed); note also
my recent interview with Unix Review. On the other hand, I am a supporter
of Common Lisp as a tool for legitimizing Lisp and for getting a decent standard
for Lisp. The strategy I use is that standarization is a two step process: first
you convince people there ought to be a standard; second, you convince them that
if there is to be a standard, it ought to be a good one. Common Lisp as a
defacto standard achieves the first of these. I was trying, with Will's help,
to achieve the second.
Splitting up Common Lisp from Scheme has some desirable and some undesirable
effects. A desirable effect is that this sends the message that Scheme is so
unlike Common Lisp that if you had doubts about Common Lisp because of
weird features, Scheme don't have 'em. An undesirable effect is that the
people you hope to convince of Scheme - industry - don't see Common Lisp
and Scheme as very different at all: maybe one is smaller than the other.
In the old days, one excuse I heard about why people didn't use Lisp was that
the ``Lisp community cannot get it together,'' by which was meant that
the various quarters could not agree on a single Lisp. An ANSI Common Lisp and
an IEEE Scheme reinforces that. I would not want to rule out the possibility
of an ANSI Scheme as a standard within the Lisp family, including Common Lisp.
I don't believe that an IEEE standard will increase the visibility of
Scheme significantly. Remember, there are ANSI and IEEE standards for all
sorts of bizarre languages (and I don't mean ADA). These remain as
anonymous to everyone I know as they were before they were standardized.
Finally, standarization is the reward for a successful language, not a
tool for making it so. Some argue that standardizing Lisp will save the
language from sinking back into academia, but I doubt this. I believe
Lisp has to fit into the rest of the world better. C is being standardized
because everyone uses it, and so with Common Lisp.
2) Will Standardization Help Motivation and Discipline?
This is somewhat of a fairy tale. What has happened with Common Lisp is
that many people who used to do the work have ducked new work because they
believe that the next guy should feel motivated to do the work. When push
comes to shove, the work gets done in informal groups who are
self-motivated, which is the current situation with Scheme - nothing will
change other than for the worse.
3) Will a Standard Improve Portability?
You can choose to have a non-validatable language (ISO prohibits this,
I think). You can also choose to leave some things up to implementations.
The standard doesn't necessarily improve things.
***********************************************************************
The arguments against standardization and the remarks Chris makes about
them are more interesting than the arguments for standardization.
4) Will a Standard Increase the Likelihood of Difficult Implementation?
Do you expect difficult-to-implement features will be added? What are some
possibilities? Or do you expect that increased pressure to conform will
require implementors to implement already-standard but difficult-to-implement
features? If these features are elegant and the right thing, why give
implementability and efficiency the upper hand (or any hand)? And if
implementability and efficiency begin to reign, what else will they
bring into the language?
5) Will Unnecessary and Flawed Features Creep In?
If Scheme currently includes only necessary features, then
necessity is based on judgement. If unnecessary but convenient
features will be left out, then there is some reason to desire an
official library. Such a library requires funding to achieve and
maintain - Common Lisp failed completely to do this although it
was an explicit goal.
The issue of technically flawed features raises the largest issue in
my mind. Throughout the Common Lisp and CLOS efforts we employed Moon's
Maxim: Do Not Standardize on Research. Standardization is codifying and
specifying existing, proven practice with minor cleanup. If you follow
this, you will not include any technically flawed features, only technically
retarded ones.
Here is a case in point: If you standardize Scheme in the next year or
two, that standard cannot include any macro facility. This is because
a PhD thesis on the topic has just been published, and no implementation
of the latest, most final ideas has been in use for long enough. The Common
Lisp macro facility is mightily flawed, but it codifies 20 years of
practice, and its flaws are well-known. This situation is very much more
desirable than casting as a standard something you just thought of.
6) Will Research Stop?
Well, I don't know. The personal motivation for research does not stop,
but the funding for that research might stop. This has happened to the
Common Lisp community. Until this year, there was funding aplenty for
Lisp research from DARPA; now it's all gone. We standardized ourselves
out of our jobs.
Note that successful standards are revised every 5 - 10 years.
7) Will the Wrong Folks Move In?
I have to admit that the commentary on this topic reminded me of the most
despicable days of the Common Lisp effort, and it actually makes me a bit
sad. The desire to define a standard and the need to be a small group in
control are inconsistent. If you feel strongly about achieving both, you
will accomplish a situation you will regret for a long time. When you
choose to make a standard for a language, you are saying that you have
something that the community at large uses and wants to continue to use;
this is an act of generosity and public spirit. When you turn around and
state that these very people towards whom you have shown this concern
should be excluded, you are saying that these people are incapable or
evil; this is an act of arrogance and insensitivity. Silly as it might
sound, this will come back to haunt you just as it came back to haunt the
Common Lisp folks.
There really was a Quinquevirate, a gang of five, who controlled Common
Lisp for the last year of its definition and who tried to control the first
year of standards discussion just prior to X3J13 forming. We actively tried
to exclude people from our inner circle. The rational basis was that we
were the founding fathers and knew the motivations for the decisions. But like
the Constitution, the interpretation of what we did fell from our hands and
should have fallen from our hands. The only fact that eases my own conscience
is that some people of impeccable character participated along with me.
Nevertheless, I'm ashamed of that period.
If you want to exclude the wrong people, remain informal and self-selected.
If you want to standardize, welcome outsiders - this is what you want, right?
You want converts, so don't insult them. If you want your ideas to
prevail, then they must prevail because they are good ideas and because
you have exerted technical leadership. All standards organizations impose
a form of democracy on the process. Imagine that your worst enemies are
Chairman and Vice Chairman. Do you fear that your ideas and your ability to
lead the community at large (who will vote) are not strong enough to
prevail? If you do, then do not start the process.
Also note, your rules for voting rights exclude Steele and me.
I doubt IEEE would allow it. Some of the Quinquevirate were threatened
with lawsuits. Don't do it.
7) What's the Right Thing?
Here's a sad story. It's the story that is forcing Will Clinger out
of the ISO process. You all know that the EuLisp community was pushing
for a more Scheme-like language as an ISO standard. One reason they
felt this was is that the Common Lisp community excluded them early on.
However, the forces at large have caused Common Lisp to prevail to
such an extent that the EuLisp community seems to be backing down
and is ready to work with Common Lisp. I had hoped, along with Will,
that we could have worked with them to bring a better standard to the
international community. I think that the only way to do this, now, is
for the Scheme and Common Lisp communities to work together more closely
somehow. As you think about this statement, keep in mind that many
members of the Common Lisp world wished something more like Scheme had
been adopted.
Well, enough of this. The war for Lisp is not on the standards
battelfield anymore, anyway.
-rpg-
∂23-Dec-87 1555 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Quasiquotation
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:54:52 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 87 20:34:24 EST
Date: Mon, 21 Dec 87 20:31:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Quasiquotation
To: Pavel.pa@XEROX.COM
cc: Scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 21 Dec 87 09:44:58 PST from Pavel.pa at Xerox.COM
Message-ID: <302612.871221.JAR@AI.AI.MIT.EDU>
Date: Mon, 21 Dec 87 09:44:58 PST
From: Pavel.pa at Xerox.COM
<list template D> ::= '<quasiquotation D>
Shouldn't this be
<list template D> ::= '<template D>
Yes, of course. Thanks for pointing this out.
Also, why is there not a formal description of the semantics of
quasiquotation? I expected to find a precise definition in the
section giving the meanings of the other derived expression types,
but there's nothing there.
It was omitted because no one got around to writing it. Steele's
description in Common Lisp: The Language comes close, but doesn't
explicitly deal with nesting. I'll make an attempt before the next
revision comes out.
∂23-Dec-87 1555 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Speed (of byte code interpreters)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:55:42 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 09:12:27 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07689; 22 Dec 87 9:02 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ax13377; 22 Dec 87 8:48 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA23301; Mon, 21 Dec 87 17:50:40 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA11388; Mon, 21 Dec 87 17:49:12 PST
Date: Mon, 21 Dec 87 17:49:12 PST
From: Will Clinger <willc%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8712220149.AA11388@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: Re: Speed (of byte code interpreters)
The byte code interpreter and compiler used in MacScheme are described in
not much detail in a paper by Will Clinger in the 1984 Lisp and FP
Symposium proceedings, "The Scheme 311 compiler: An exercise in
denotational semantics."
More detail can be found in Appendix D of the current MacScheme and
MacScheme+Toolsmith manuals. The purpose of this appendix is to tell
how to write a machine code procedure that can be called from Scheme,
but in doing so it describes some of the data representations, register
conventions, calling conventions, and byte codes.
Along with the paper cited by Jonathan, this is everything that has been
published about the implementation of MacScheme.
Peace, Will Clinger
∂23-Dec-87 1556 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Scheme on CMS?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:56:13 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Dec 87 13:00:52 EST
Date: Tue, 22 Dec 87 12:58:31 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scheme on CMS?
To: ihnp4!alberta!calgary!jameson@UCBVAX.BERKELEY.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 21 Dec 87 17:43:41 GMT from ihnp4!alberta!calgary!jameson at ucbvax.Berkeley.EDU (Kevin Jameson)
Message-ID: <302853.871222.JAR@AI.AI.MIT.EDU>
Date: 21 Dec 87 17:43:41 GMT
From: ihnp4!alberta!calgary!jameson at ucbvax.Berkeley.EDU (Kevin Jameson)
Several of the previous transactions appear to be seeking info on Scheme
implementations (and source) for various purposes. There appear to be
implementations of Scheme in Common Lisp and C, and maybe Common Lisp
implementations in Scheme, Scoops in Scheme, etc. etc.
I am also looking for an implementation (for a pc).
Could someone in the know please summarize what implementations are
available, for what machines, and if source is available at what
cost?
I periodically announce that I have a list of implementations, which
I'll send to anyone requesting it. (Send your request to
scheme-request@mc.lcs.mit.edu.) It's not quite up to date, but it's
close. It's sort of big so I'd rather not post it to the mailing list.
People with Internet FTP access can get the list from
MC.LCS.MIT.EDU:LSPMAI;SCHEME IMPLS
If you know of any available implementations that are missing from the
list, or if you discover any inaccurate information, please let me know.
∂23-Dec-87 1556 @MC.LCS.MIT.EDU,@RELAY.CS.NET:feeley%iro.udem.cdn@UBC.CSNET Small Scheme compiler in Prolog...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:56:47 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Dec 87 16:16:44 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab12439; 22 Dec 87 15:52 EST
Received: from ubc by RELAY.CS.NET id ab15820; 22 Dec 87 15:38 EST
Received: by ean.ubc.ca id AA27211; Tue, 22 Dec 87 10:21:35 pst
Date: 22 Dec 87 13:21 -0500
From: Marc Feeley <feeley%iro.udem.cdn%ubc.csnet@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <90*feeley@iro.udem.cdn>
Subject: Small Scheme compiler in Prolog...
Hi everyone,
I recently wrote a Scheme compiler in Prolog (for a logic programming
course). The compiler handles almost all of scheme's special forms
(only backquote notation, => syntax in conds and rest arguments are
not implemented). It generates native-code for SUNs, has only
a few primitive procedures implemented and no garbage-collector.
The code generated is fairly efficient (tak takes 1 sec on a SUN3).
Those who are interested in having the source please send me a
message directly (the compiler is 45Kbytes and is written in Quintus
prolog but should be easily ported to other prologs).
If there are enough requests, I'll write a couple pages of doc (presently
you have to read the scarce comments in the code) and maybe I'll add
some more primitives and who knows... maybe a GC.
Don't expect any replies before the middle of January... Happy holidays!
Send requests to:
feeley@brandeis.csnet (my current address at Brandeis University)
feeley%grafik.iro.udem.cdn@ubc.csnet (my `home' address at the University
of Montreal).
∂23-Dec-87 1553 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Byte code speed
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:53:38 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Dec 87 17:44:12 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA14433; Sun, 20 Dec 87 14:38:43 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Dec 87 01:59:19 GMT
From: ihnp4!alberta!calgary!jameson@ucbvax.Berkeley.EDU (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Re: Byte code speed
Message-Id: <1266@vaxb.calgary.UUCP>
References: <8712182044.AA05200@home>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can anyone tell me anything about public domain Scheme implementations
which will run on a PC? GNU Scheme, I am told, is too big.
Thanks.
...{ihnp4,ubcvision}!alberta!calgary!vaxb!jameson
∂23-Dec-87 1554 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET RE: Scheme on Atari ST.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 15:53:54 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 21 Dec 87 07:53:59 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 21 Dec 87 07:53:04 EST
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 8410; Mon, 21 Dec 87 07:53:02 EST
Date: Mon, 21 Dec 87 13:46:01 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Subject: RE: Scheme on Atari ST.
Date: 21 December 1987, 13:09:03 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
To everybody concerned by Scheme on the Atari ST:
To my knowledge there is no native Scheme on this computer.
If you run a Mac emulator (Aladin or Magic Sac) then you can use MacScheme.
If you run PC Ditto then you can run TI PC Scheme.
(I would be most interested to hear about the speed of this combo.)
Why there is no MIT's CScheme on the Atari: memory.
When I get 4 meg (no less) of memory on my ST, I will port CScheme
6.1 or whatever is available at this time.
Last year I have spend a lot of time porting 4.1 on my 1040, up to the point
where the microcode compiled, using MWC 1.0. It is a lot of trouble because
there is some code in Scheme that is dependent upon C int = 32 bits.
But 1Meg is not enough to run CScheme.
If I try again, it will be with Lattice 3.04.
Some people are currently writing new Scheme implementations, if they
are portable, in C preferably, then we may end up with a working version
quite soon, if we can have the sources on the ST.
An other possibility is to start from XLISP, and change it from CommonLisp
to Scheme, I looked at the code, it is quite easy. The problem is the
speed of this implementation is not very good at all...
The last possibility would be to use Vincennes Scheme, it should run
on 2meg of memory, compiled with the Lattice C. There is currently
some technical problems to get the sources, and I still dont know
what is the Policy about this code. (Private, Copyrighted, public domain
or else...)
Keep on Scheming.
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@mitvma.mit.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂23-Dec-87 2218 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Why are case implementations so slow?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Dec 87 22:18:40 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Dec 87 01:15:57 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA00126; Wed, 23 Dec 87 21:22:12 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Dec 87 07:55:42 GMT
From: jh@ohio-state.arpa (Juha Hein{nen)
Organization: Tampere University of Technology, Finland
Subject: Why are case implementations so slow?
Message-Id: <2225@korppi.tut.fi>
References: <5821.8712220254@aiva.ed.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Dispatching of a method is straighforwardly done using a case
expression on the operation symbol. I have tested the case speed of
three Scheme implementations (CScheme, MacScheme and PC Scheme) and in
all of them cond is faster than case!
Since the case labels have to be symbols, shouldn't the case
expression be faster than the corresponding cond expression? Is there
some reason why Scheme's case can't be implemted using a computed goto
like in ordinaty programming languages?
--
Juha Heinanen
Tampere Univ. of Technology
Finland
jh@tut.fi (Internet), tut!jh (UUCP)
∂24-Dec-87 0656 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA A vote against standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Dec 87 06:56:22 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 24 Dec 87 09:51:47 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA02009; Thu, 24 Dec 87 09:50:13 EST
Posted-Date: Thu, 24 Dec 87 09:46:55 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA01711; Thu, 24 Dec 87 09:46:55 EST
Date: Thu, 24 Dec 87 09:46:55 EST
Message-Id: <8712241446.AA01711@darwin.sun.uucp>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dick Gabriel's message of 22 Dec 87 0956 PST <8712222018.AA08060@mitre-bedford.ARPA>
Subject: A vote against standardization
I must agree with a few of Dick's comments, especially those
pertaining to the question of timing. It seems to me too early to
standardize Scheme, a language destined to go through big changes.
1) Currently, there is no conforming macro facility, nor an official
description of the correct one.
2) The situation with EVAL is not settled (I favor Rees's EVAL-IN-R3RS).
3) I would not like to see us get into the same mess Common Lisp got
into over object-oriented programming. We should standardize after
there is some consensus on what to do on that subject. I am eagarly
awaiting Adam's and Clinger's suggestion.
4) We have no support for the development of large systems. I think
this is an area that the Scheme community could greatly advance.
Dick's interview in UNIX Review points out the limitation of Common
Lisp. Let's standardize after we have something to say about large
systems.
5) Parallelism? Maybe we should break ground?
John
∂24-Dec-87 1105 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Why are case implementations so slow?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Dec 87 11:05:10 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Dec 87 14:02:10 EST
Date: Thu, 24 Dec 87 14:00:52 est
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Why are case implementations so slow?
One reason is that the "natural" expansion of
(case e0 ((k1 k2 ...) e1 e2 ...) ...)
is
(let ([tag e0]) (cond ((memv? tag '(k1 k2 ...)) e1 e2 ...) ...))
where "tag" does not occur free in e1 e2 ....
This is surely slower than using the "equivalent" eq? tests when there
is only one key per clause and that key is a symbol. The Chez Scheme
expander looks for these special cases and expands them "appropriately",
so you should find case as fast as cond. You could write your own case
macro that does the same thing.
However, it is not practical to turn case into a computed goto unless
there are several keys within a relatively small range of fixnums or
characters. It could be beneficial, certainly, but Chez Scheme doesn't
bother, and I suspect that most other implementations don't either.
R. Kent Dybvig | arpa: dyb@iuvax.cs.indiana.edu
Computer Science Department | csnet: dyb@indiana
Indiana University | usenet: ...!ihnp4!iuvax!dyb
Bloomington, IN 47405 | phone: 812/335-6486
∂27-Dec-87 1007 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU skim (a low fat implementation of Scheme)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 87 10:07:42 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Dec 87 13:04:45 EST
Date: Sun, 27 Dec 87 13:02:57 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: skim (a low fat implementation of Scheme)
To: scheme@MC.LCS.MIT.EDU
Message-ID: <304152.871227.JAR@AI.AI.MIT.EDU>
Date: Thu, 24 Dec 87 11:10:47 +0100
From: harvard!ut-sally!uunet!mcvax!litp!ald at bbn.com
To: jar at ai.ai.mit.edu
Re: Scheme on CMS?
Organization: L.I.T.P, Universite P7, PARIS
Return-Receipt-To: uunet!mcvax!inria!litp!ald@RUTGERS.EDU
In article <302853.871222.JAR@AI.AI.MIT.EDU> you write:
>
>If you know of any available implementations that are missing from the
>list, or if you discover any inaccurate information, please let me know.
There is an implementation of Scheme, that i believe is not
currently registered:
Name: skim (a low fat implementation of Scheme)
Authors: A. Deutsch, R. Dumeur, C. Consel, J.D. Fekete.
Runs-on: Sun[23], Vax, Orion under BSD Unix.
Has: An interpreter and a compiler (vax only for now).
Features:
- R3RS compatibility (but misses complex, bignums and ratios);
- extensible type system and operations;
- stop/copy gc;
- scode based interpreter.
Availability:
- the system has been registered;
- binaries are available (we do not plan to distribute sources now).
Performance:
- the interpreter is quite fast (5 times faster that MIT-scheme).
- the compiler is not an optimizing compiler.
Contact:
- ...mcvax!inria!litp!{ald|chac|jdf|red}
Best regards,
Alain Deutsch.
∂27-Dec-87 1406 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU A vote against standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 87 14:05:58 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 DEC 87 17:04:56 EST
Received: from PIGPEN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 27 Dec 87 17:04-EST
Date: Sun, 27 Dec 87 17:05 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: A vote against standardization
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8712241446.AA01711@darwin.sun.uucp>,
The message of 22 Dec 87 12:56 EST from Dick Gabriel <RPG@SAIL.Stanford.EDU>,
The message of 19 Dec 87 15:54 EST from Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-ID: <871227170521.7.ALAN@PIGPEN.AI.MIT.EDU>
Here is my vote against official standardization.
I will limit myself to briefly remarking on the dangers of the "First
Strike" theory of programming language standardization:
If the good guys (us) don't get together and make a standard, then the
bad guys (them) will do it and screw up. Therefore (even though we
don't really want the hassle of standards bureaucracy) we had better do
it first.
This argument attempts to encourage a stampede by playing to everybody's
insecurities about losing control of the language. It is dangerous to
place too much weight on this argument, because you can find yourself
saddled with a standards process that in fact -nobody- really wanted (not
even the people you perceive of as the "bad guys").
If a critical mass of the Scheme community decides that it will participate
in an official standards committee, then there will be a standard, no
matter what the rest of us might think. But I hope that if that happens,
the members of that critical mass will have decided to participate on the
basis of arguments -other- than the First Strike theory.
∂27-Dec-87 2214 @MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU A vote against standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 87 22:14:03 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 28 Dec 87 01:13:54 EST
Received: by KLEPH.AI.MIT.EDU; Mon, 28 Dec 87 01:14:15 est
Date: Mon, 28 Dec 87 01:14:15 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8712280614.AA27983@kleph>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Sun, 27 Dec 87 17:05 EST <871227170521.7.ALAN@PIGPEN.AI.MIT.EDU>
Subject: A vote against standardization
Reply-To: cph@mc.lcs.mit.edu
Date: Sun, 27 Dec 87 17:05 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Here is my vote against official standardization.
Let me add my voice to those of Alan and John. I think it is
premature to form an explicit standard. I also feel that the drive
for standardization should be undertaken by us when we have some kind
of concensus that it is a desirable thing, not because of pressure
from external parties who have little or no commitment to the language
(I would place the IEEE people in this category).
∂28-Dec-87 1109 @MC.LCS.MIT.EDU:KMP@Riverside.SCRC.Symbolics.COM My vote against standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Dec 87 11:09:38 PST
Received: from Riverside.SCRC.Symbolics.COM (TCP 20024224425) by MC.LCS.MIT.EDU 28 Dec 87 14:09:25 EST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213984; Mon 28-Dec-87 14:07:47 EST
Date: Mon, 28 Dec 87 14:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: My vote against standardization
To: RRRS-Authors@MC.LCS.MIT.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <8712280614.AA27983@kleph>,
<871227170521.7.ALAN@PIGPEN.AI.MIT.EDU>,
The message of 22 Dec 87 12:56 EST from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <871228140737.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I think a Scheme standardization process at this time would be an
extraordinarily bad idea.
I think that a time will come when, as RPG suggests, it will be
appropriate to offer the ideas of Scheme as a gift to the community to
stand on their own, but I do not think this is the time.
I was not clear on whether this standardization process was generated by
one of our members. If this move toward standardization is externally
generated, I suggest that the RRRS-Authors should make a formal
statement to IEEE asking them not to make the standard. If the move was
internally generated or if there was any prior groundwork done by any of
our members without involving the others, then I take great personal
offense at our not having been informed.
It is my strong belief that the larger the group becomes, the less
useful work it can do. We have useful work yet to do with Scheme. It is
questionable whether we can do it with a group the size that we have
now. It is nearly certain that we cannot do it with a group the size of
a standards organization.
It is also nearly certain that the organizational structure of a
standards committee is not appropriate for design work. Design is a
creative process and it cannot generally be achieved by an enforced
democratic process.
For a time it is still appropriate to be exclusive, anti-social, etc.
(one of the options RPG suggested we might take). I believe that for a
time it is still appropriate to weigh certain people's opinions more
than others (even if for friendship's sake we don't always come out and
say whose or why).
Entrance into standardization should be clearly accompanied by an
agreement to cease all design work. If we think that any further
substantive change to the language is in order (macros, eval, optional
arguments, ...), we're inviting disaster. CL has shown that one
compromise leads to another, and that in the end we may have something
that locally appeases many stated gripes, but that globally is a
hodgepodge.
There is no reason that we can't make Scheme into a language which has
greater appeal. But achieving that requires some interesting design work
to be done, not the bureaucracy of a standards committee. And anyway,
I'm content to have Scheme be a language which does not appeal to
everyone -- as long as there is a community which recognizes its value.
I'm not content to have Scheme be a language whose goal in life is to
maximize the number of people to whom it appeals at the cost of its
values.
I am willing to risk that IEEE (or anyone else) might still try to make
a Scheme standard without our consent. I assume they have the legal
right to make such a standard with or without our cooperation, but I
think we should give them the benefit of the doubt and assume they are
honorable folks who would respect our wishes. There is no shame in being
proven wrong on this point.
∂31-Dec-87 0150 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu problem bringing up Scheme 6.1
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 01:50:21 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 31 Dec 87 04:47:46 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA23229; Thu, 31 Dec 87 01:39:47 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 30 Dec 87 21:26:08 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson)
Organization: NCR E&M, Cambridge OH
Subject: problem bringing up Scheme 6.1
Message-Id: <1821610@ncrcpx.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've been able to get Scheme to link under System V Release 2 on an
NCR Tower 32. This is 68020-based. I've had to modify the C
preprocessor (may the source be with you), and have had to make some
minor additions/changes to unix.c, config.h - the usual things from
what I can tell. I'm starting to get excited. Maybe it will work,
eh? (Canadian accent showing...)
But No...
Here's what happened in the next step:
cd /usr/craig/Scheme/
make runtime/scheme.bin
cd runtime; rm -f *.bin
etc/make_bin
Psbtobin /usr/craig/Scheme/runtime/Sgraph.psb
:
: (Additional stuff deleted)
:
Psbtobin /usr/craig/Scheme/runtime/sdata.psb
/usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped
*** Error code 1
Stop.
Compilation exited abnormally with code 1 at Wed Dec 30 16:12:06
Gag, gag, gag. Looking into the source code there's nothing obvious.
Could some kind soul out there point me in the right direction. I've
found at least one definate bug in the distributed code. Maybe
there's another???
I would really LOVE to get this stuff working. Once working I hope to
modify GNU cpp so that others can use it on SYSVR2. (I've already
tried, but GNU cpp gets VERY confused trying to play with all the
defines - even more than USG cpp. Just need more time.)
Any help offers??? Please???
--
R. Craig Peterson "Next time someone asks you if you're a god
ncrlnk!ncrcam!ncrcpx!craig say YES!!"
N8INO Ghost Busters
E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)
∂31-Dec-87 1010 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Question about load.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 10:09:59 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 87 13:07:32 EST
Date: Thu, 31 Dec 87 13:05:50 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Question about load.
To: net%TUB.BITNET@MITVMA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 29 Dec 87 14:40:01 +0100 from Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
Message-ID: <305448.871231.JAR@AI.AI.MIT.EDU>
Date: Tue, 29 Dec 87 14:40:01 +0100
From: Oliver Laumann <net%TUB.BITNET at MITVMA.MIT.EDU>
The R3RS does not specify in which environment definitions loaded
from a file will be bound. Consider the following function:
(define (f) (load "foo"))
where "foo" contains the definition
(define x 9).
When "f" is invoked, is the variable "x" put into the environment frame
created by the call to "f", that is, is it made a local variable,
or is it entered into the environment frame in which "f" has been
defined?
I personally would expect the former, but this would make it impossible
to write a function similar to "require" supported by Gnu-Emacs.
C-Scheme seems to load definitions into the environment employed by
the read-eval-print loop, which is more useful (but less obvious).
Scheme is lexically scoped, and LOAD is a procedure, therefore there's
no way that LOAD could find out the environment from which it was
called. Thus it has to get an environment from somewhere else, e.g. the
current global state of the read-eval-print loop. C Scheme and T
both have this semantics.
What is your opinion about this and how is it handled by existing
interpreters? In interpreters that support environments as first-class
objects (like C-Scheme), shouldn't "load" receive a second argument --
the environment in which the contents of the file will be evaluated?
C-Scheme and T both do indeed accept an environment as an optional
second argument to LOAD.
∂02-Jan-88 1250 @MC.LCS.MIT.EDU:ericson@csd16.nyu.edu Optimizing tail-recursive operations using jumps
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 12:50:25 PST
Received: from csd16.nyu.edu (TCP 20036500057) by MC.LCS.MIT.EDU 2 Jan 88 15:46:50 EST
Received: by csd16.nyu.edu (3.2/25-eef)
id AA17960; Sat, 2 Jan 88 15:48:48 EST
Date: Sat, 2 Jan 88 15:48:48 EST
From: Lars Ericson <ericson@csd16.nyu.edu>
Message-Id: <8801022048.AA17960@csd16.nyu.edu>
To: scheme@mc.lcs.mit.edu
Subject: Optimizing tail-recursive operations using jumps
Consider the following calling pattern:
;0 Calling /' with arguments (<f <f 1>> <f <f <f -2<pp Y>>>>)
; 1 Calling // with arguments (<f <f 1>> <f <f <f -2<pp Y>>>>)
; 2 Calling /' with arguments (<f 1> <f <f -2<pp Y>>>)
; 3 Calling // with arguments (<f 1> <f <f -2<pp Y>>>)
; 4 Calling /' with arguments (1 <f -2<pp Y>>)
; 5 Calling // with arguments (<f 1> <f -2<pp Y>>)
; 5 Returned from // with values ((<f 1>) / (<f -2<pp Y>>))
; 4 Returned from /' with values ((<f 1>) / (<f -2<pp Y>>))
; 3 Returned from // with values ((<f 1>) / (<f -2<pp Y>>))
; 2 Returned from /' with values ((<f 1>) / (<f -2<pp Y>>))
; 1 Returned from // with values ((<f 1>) / (<f -2<pp Y>>))
;0 Returned from /' with values ((<f 1>) / (<f -2<pp Y>>))
/' is a procedure and // is an operation. Both are compiled, one calls
the other. It is apparent that every call is tail-recursive, since the
results on the way "back up" are unmodified.
Why not use continuations somehow to have a "REWRITE-CALL", similar to
a plain old JUMP, which passes arguments to a subprocedure, overwriting
the argument space on the stack for the calling procedure, such that
when the subprocedure returns, it returns to the caller of the caller?
Like DEFINE-INTEGRABLE, REWRITE-CALL would be an optimization that the
user applies intentionally when it is clear that the call is tail-recursive.
This seems like it would be pretty easy to implement, both for interpreted
and compiled code, in terms of continuations.
-- Lars Ericson
∂05-Jan-88 1540 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 15:40:16 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Jan 88 18:30:50 EST
Received: by iuvax.cs.indiana.edu; id AA26238; Tue, 5 Jan 88 16:35:05 EST
Date: Tue, 5 Jan 88 16:35:05 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8801052135.AA26238@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization
More time is needed for discussion, so the formation of a Scheme
standardization working group will NOT be proposed at the MSC meeting
this month.
We should continue the debate what would be a good time to start a
standardization effort and how it would be best to proceed.
Historically, it seems that every language that obtains a reasonably
large user community is eventually standardized (usually over the
objections of its designers and implementers). Since the Scheme
community is growing rather rapidly, it is just a matter of time
before some part of the user community initiates standardization. So
the question is WHEN, not WHETHER, it would be best to untertake
standardization.
Perhaps there are sound technical reasons for a substantial delay (say
a year or more). If so, I would like to hear them. However, my
impression from last summer's meeting is that almost all of what we
have now is relatively stable, and the new features we would like to
consider adding (macros, modules, etc.) are all very much in the
design stage. It will likely take at least a year (probably two or
more) to refine these proposals and get them widely implemented, and
another year of experience with them before we can be sure we like
them. Only then (2 or 3 years hence) would it seem likely that major
new features should be candidates for standardization.
I believe the advantages of moving relatively soon to standardize
approximately what we have now outweigh the disadvantages of waiting
that long. Admittedly this judgment is based on weighing the
importance of a number of nontechnical considerations. Thus it is
impossible for me to be sure this is right, much less make a
definitive argument in its favor. In this respect especially, we need
feedback from all segments of the Scheme community (not just its
designers and implementers).
It is vital that standardization not impede the development of new
features and improved implementations, but I do not see why it should
(other than taking the time of some individuals who would be involved
in both). Again, if anyone has technical grounds for casting
reasonable doubt on this judgment, please speak up.
I'm leaving town again for a couple of weeks. I'll respond to many
of the comments received thus far when I return.
Regards,
Chris Haynes
∂06-Jan-88 1117 @MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 11:17:32 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Jan 88 14:12:56 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa28365; 6 Jan 88 14:11 EST
Received: from csc.ti.com by RELAY.CS.NET id ai21643; 6 Jan 88 13:58 EST
Received: from mips by tilde id AA15625; Wed, 6 Jan 88 12:36:27 CST
Received: by mips id AA17672; Wed, 6 Jan 88 12:36:22 CST
Date: Wed, 6 Jan 88 12:36:22 CST
From: Clyde Camp <camp%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8801061836.AA17672@mips>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Scheme Standardization
========================================================================
= IT IS MUCH MORE DIFFICULT TO GIVE BIRTH TO SOMETHING THAN TO KILL IT =
========================================================================
I've watched the RRRS-AUTHORS mail for the last couple of weeks with
interest and feel it is time to respond to the issues raised on
standardization and clear up a few apparent misconceptions.
For those of you who do not know me, my name is Clyde Camp and I work
for the Computer Science Center of Texas Instruments. I've been
involved in standards work both inside TI and outside for about 15
years. I'm also the chair of the Microprocessor Standards Committee
(MSC), having been vice-chair for a year and secretary for three years
preceding that.
Before I go any further, let me point out that in any discipline there
are always horror stories of things gone wrong or difficulties
encountered. The standards world is no different and the few horror
stories are widely circulated while the many successes go largely
un-noticed by all except those directly involved. It is also
interesting to note that, historically, the more severe problems have
been due to hesitation or waiting too long to do something rather than
starting things too quickly. One of the major reasons for the various
committees is to isolate the technical work of the working group members
from most of the "hassle" of the standardization process itself. Only
the chair NEED worry about that (although anyone else who is really
interested is welcome to attend anything.)
The rest of this is broken into three parts:
1) A history of the Scheme standard proposal mentioned by Chris
Haynes.
2) A response to the replies he had received as of January 4th.
3) A set of recommendations which the readers should consider.
(transmitted separately)
In the interests of time I have not attempted to explain the sequential
steps involved in standardization, except as they directly apply. The
process is rather well outlined in a pair of articles by Dr. Michael
Smolin in the August-87 issue of IEEE MICRO (pages 82-83) and in the
October-87 issue (pp 92-94).
If any of you wish to contact me directly, I can be reached at (214)
995-0407 (beware the answering machine) or at camp%TI-CSL@CSNET-RELAY.
!
***HISTORY***
The current attempt to bring about a Scheme standard was originally
initiated by me about the middle of last year and was based on the
following:
1) Scheme is an ideal language for general symbolic processing
2) It is significantly better suited for embedded applications and
small systems than Common Lisp
3) It is an ideal educational/instructional language
4) There were at least three commercial implementations (all mostly
alike, but with significant differences)
5) There seemed to be a growing ground swell of users who liked the
language (brought about in no small part by the Abelson/Sussman
'Bible')
6) There was already a group in existence who had generated a working
'specification' for the language, who represented a reasonable mix
of theorists, users and implementors and who were eminently
qualified. This existing 'specification' is already better
than some existing standards.
7) I didn't want to see the Common Lisp standardization mess (due in a
large part to waiting too long before starting) repeated with
Scheme. I wanted it to be a pro-active standard rather than a
retro-active one.
8) I felt that the IEEE/CS was the best way to get such a standard
developed.
My personal belief is that Scheme stands a very good chance of being the
symbolic and arithmetic language-of-choice in the long-term (5-10
years). But I don't believe that it can be so without at least
partially leaving its current academic environment and finding a
sponsoring organization such as the IEEE or ACM - there will be too many
external pressures (user, industry, government).
At that time I sent Jonathan Rees, David Bartley and a few others a
short message on the pros/cons of standardization and suggested that the
topic be brought up at the June-1987 RRRS meeting. Based on David's
report back to me that it had been raised and quickly dismissed, I took
the easy path of not pursuing the issue any further (and have even lost
the text of the message I sent.)
In early December, 1987, Jim Flournoy (with the Computer Society
Standards Activity Board) independently recognized that it might be an
appropriate time to begin a Scheme standardization effort. He called me
and asked for names of people who I thought might be willing to chair
such an activity. I opened up the RRRS red-book and gave him the names
of the people who were foolish enough to have their names printed on the
first page. When he reported back that Chris Haynes and Will Clinger
had agreed to consider being chair and secretary respectively, I called
both back in mid-December and, after several long discussions, conned
them into considering positions of chair and vice-chair instead.
Will and Chris then began polling the Scheme community for Interest,
Disinterest, Non interest. The jury is still out.
Without going into all the gory details, we tried to get things lined up
to have Chris or Will present at the January MSC meeting (or me pitch
their presentation). The January meeting was important because it was
the day before the annual ANSI Standards Project Authorization Review
Committee (SPARC) meeting. It would have been ideal if this could have
been worked out since SPARC is the committee which reviews submissions
to ANSI by X3 and IEEE. For various reasons, this time frame turned out
to be too short for everybody to get their act together, so I would like
to try for the the next MSC meeting in March or the one in May.
One of the primary reasons for pushing on this is to get a head start on
all the administrative time lags built into the process.
For those of you who are by this time thinking "All that crap is the
reason I didn't want to get involved with the damn standards activity to
begin with" the good news is that none of the above should affect what
the working group is doing or when it meets. One of the major reasons
for the various committees is to isolate the technical work of the
working group (WG) members from most of the administrative process of
the standardization business itself. Only the chair NEED worry about
that although anyone else who is really interested is welcome to attend
anything.
***** RESPONSE ****
CHRIS HAYNES:
A excellent (balanced) summary. There is little I can add other than to
correct a few minor points (which may have been due to a
mis-communication on my part to begin with).
With respect to working group attendance and 'voting' rights, there are
NO formal procedural requirements at the working group level. The WG
Chair is pretty much free to run things the way he wants. Although
there are some informal guidelines that will be recommended, the CS
Policies and Procedures manual states merely that the chair of the
working group is responsible for developing the document. Again, the
reason for this is to keep the working group as free from the
administrative details as it wishes to be. There are no requirements
for meeting frequency or place or attendance for example. While the
Chair is required to be a CS or IEEE member, there is no such
requirement on any of the other WG members.
As Chris pointed out, trial-use standards are reviewed every two years
and recommended for full use, withdrawal or revision. Full-use
standards come up for review every five years for reconfirmation,
withdrawal or revision. So a 'STANDARD' is not cast in concrete for all
time.
The extensive use of E-mail net to development a standard is a new (to
the MSC) methodology, but one which I encourage. Although non-net
interested parties must also be accommodated, the Chair can probably
handle this is by keeping a mailing list of those entities and sending
them hard copies of the net traffic at periodic intervals or as
necessary. The IEEE secretariat can be used to take care of
reproduction and mailing if necessary (all she needs is one copy and a
mailing list) but we have a limited budget and prefer that the WG work
this out if possible.
DICK GABRIEL:
(1-3) There are some tough arguments and questions here but many of them
are between basic philosophical issues which are akin to arguing the
advantages/disadvantages of big-endian vs. little-endian. Dick's
comments about splitting up (or not) Scheme and Common Lisp were
interesting because I've wondered as well about the possibility of a
family of symbolic processing languages. The scope of something like
this is scary and the initial reaction is probably "No way, Jose -
Impossible". But those of you who think pulling together (apparently)
radically different things under one umbrella is an impossible task
should talk to Maurice Graube who chairs the 802 networking standard (a
success story if ever there was one.)
I fully agree with Dick's statement that the work gets done by small
groups which are self motivated but disagree with his conclusion that
nothing will change other than for the worse. A properly run standards
working group does help motivation, discipline and visibility - it
happens more often than not. Common Lisp is, unfortunately, an example
of 'not'.
(4-6) The answer to all three of these is basically "It's possible, but
only if you let it." I think it's far less likely that any of these
fears will be realized if the RRRS cadre is in the driver's seat. A
scenario that bothers me more is "company X" pushing its implementation
of Scheme as THE correct and only implementation.
(7 - the first one) RPG is right except for the last paragraph, which
again is my fault. With exception of the actual working groups, voting
rights at each committee level are xxxx + "appointment by the chair with
concurrance of the next higher chair" where xxxx is formally specified
in the CS Policies and Procedures manual. The working groups have no
such restrictions and although the recommendation is that some generally
uniform policy be maintained, it is always the Chair's perogative to
issue voting rights (for example to individuals who can't personally
attend for some reason but who are obviously valuable contributors) or
to remove them (for example to allow company-X only one vote to prevent
it from sending 300 people to swing the standard to meet its product) or
to not vote at all and develop the specification by some other means of
consensus.
With respect to lawsuits, the IEEE provides protection to the WG from
such things to some extent. While such an issue has never come up and
the degree or capability to which the IEEE would defend such a suit is
unknown, members are certainly better protected than a non-sponsored
group.
(7 - the right thing?) Perhaps this effort?
RAMSDELL:
=========
These are largely tactical decisions which can be made if and when a WG
is formed. Again, standards can be added to. The current RRRS approach
of essential vs non-essential may be entirely appropriate. Similar
things have been done on hardware standards. I think I would advise
against trying to include parallelism at this stage.
ALAN BAWDEN:
============
I don't believe in the "First Strike" theory either, although I do
wonder why it keeps happening. Seriously, it has happened but while the
possibility exists, I suspect that in this particular case the scheme
community is sufficiently close-knit that it would be aware of such an
effort and might be able to insert the red-book as a proposed draft even
if it should occur. It is always easier and more efficient to start
with something which is at least partially acceptable than to start all
over from scratch - if for no other reason than the job of physically
entering the text.
CHRIS HANSON:
===============
What?!?!?!?
I'm one of those "IEEE people" you refer to (as are four of the 17 RRRS
authors) and I will certainly take issue with anyone who tells me I have
no committment to the language. It's BECAUSE I have a committment to
the language that I'm taking the effort to try and get this effort
going. If you have legitimate arguments on either side then voice them
by all means, but please do so without rancor.
KENT PITMAN:
============
I hope the previous megawords clear up some of your confusion with
regard to who is doing what and why.
You are somewhat right in your belief that the larger a group becomes,
the less useful work it can do. I say somewhat because it depends on
the absolute size - I'll contend that three can do more than one but
certainly 20 can do more than 200. However, as I've said before, the
entire standards organization is not involved here - only those that are
in your working group. Even this could become large although only a few
do "useful work". Using the MSC itself as an example, the mailing list
is about 200, however only 30 or so are what I would call participating.
The rest are there primarily for info although they may inject comments
(sometimes even useful ones!) now and then. It may help to think about
it like CS-NET. How many read or have access to RRRS-AUTHORS vs how many
actually contribute?
Ceasing design work to initiate a standard is not a requirement. If it
were, there would be far fewer standards around. It is entirely
possible to be in 100% compliance with a standard and yet extend it
provided the extensions don't alter things you've done before. The goal
of a standard is most definitely NOT to "maximize the number of people
to whom it appeals at the cost of its values" although where to draaw
the line is often difficult to decide.
===================
My recommendations on where to proceed from here are being transmitted
in a separate message.
REgards, Clyde
∂06-Jan-88 1330 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu getting C-Scheme running on Sun-3 / want Scoops info
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 13:29:49 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 6 Jan 88 16:21:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA25879; Wed, 6 Jan 88 12:57:27 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 Jan 88 16:29:29 GMT
From: siemens!edsel!biggers@princeton.edu (Mark Biggers)
Organization: Siemens RTL, Princeton, NJ
Subject: getting C-Scheme running on Sun-3 / want Scoops info
Message-Id: <374@siemens.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hello,
I am sure this has been requested before (maybe it should be with
the C-Scheme distribution), but has anyone gotten C-Scheme fully
installed on SunOS v3.4? I think the installation went fine
until the undump attempt.
Also, would like to get SCOOPS source and info on SCOOPS; any
pointers to this appreciated!
mark
-------------------------------------------------------------------------
Mark Biggers
Siemens Research & Technology Laboratories
105 College Road East
Princeton, NJ 08540
UUCP: {almost anywhere}!princeton!siemens!biggers
ARPA: biggers%siemens@princeton.edu
-------------------------------------------------------------------------
∂06-Jan-88 1913 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU who contributes?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 19:13:36 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Jan 88 22:12:48 EST
Date: Wed, 6 Jan 88 22:08:39 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: who contributes?
To: camp%mips.csc.ti.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 6 Jan 88 12:36:22 CST from Clyde Camp <camp%mips.csc.ti.com at RELAY.CS.NET>
Message-ID: <307797.880106.JAR@AI.AI.MIT.EDU>
Date: Wed, 6 Jan 88 12:36:22 CST
From: Clyde Camp <camp%mips.csc.ti.com at RELAY.CS.NET>
How many read or have access to RRRS-AUTHORS vs how many
actually contribute?
I was sort of curious about this. I count 22 individuals directly on
the mailing list, plus four redistributions:
OZ - 14 people
HP-SCHEME - I have no idea; I'll guess 4
Indiana - ditto; guess 7
TI - ditto; guess 7
That makes about 54 people, if I add correctly. Probably a conservative
estimate.
43 people (plus one program and one stuffed animal) have contributed to
the 825 messages. 20 people have contributed 7 or more messages each.
These 20 people account for 95% of the messages. (Counting messages is
a crude measure, but it's all I have the energy to do.) As I expected, I
am the most embarrassed, with Bill Rozas and Will Clinger 2nd and 3rd.
Jonathan Rees 191 (192 with this message)
Bill Rozas 84
Will Clinger 70
David Bartley 64
John Ramsdell 60
Kent Dybvig 55
Chris Hanson 55
Guy Steele 30
Kent Pitman 24
Gerald Jay Sussman 21
Mitchell Wand 20
Chris Haynes 17
Andy Cromarty 15
Dan Friedman 13
Andy Freeman 12
Bert Halstead 11
Norman Adams 10
George Carrette 8
Paul Hudak 7
Alan Bawden 7
Perry Wagle 6
Gary Brooks 5
Don Oxley 4
Charlotte Mooers 4
Matthias Felleisen 3
Ken Haase 3
Hal Abelson 3
Warren Harris 2
Myrna Fox 2
Henry Wu 2
Eugene Kohlbecker 2
David Brown 2
Steve Vegdahl 1
Robert Hieb 1
Richard Kelsey 1
Richard Fateman 1
Oliver Laumann 1
Morris Katz 1
Mark Meyer 1
Larry Masinter 1
Jay Leech 1
Clyde Camp 1
Arthur Altman 1
COMSAT 1
Tigger 1
∂07-Jan-88 0508 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MDEBAR@BNANDP11.BITNET Scoops ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 05:08:44 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Jan 88 08:01:45 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Thu, 07 Jan 88 08:01:02 EST
Received: from SCF1.FNDP.AC.BE by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
8229; Thu, 07 Jan 88 08:00:59 EST
Received: by BNANDP11 (Mailer X1.25) id 5533; Thu, 07 Jan 88 13:41:10 +01
Date: Thu, 07 Jan 88 13:36:44 +01
From: Michel Debar <MDEBAR%BNANDP11.BITNET@MITVMA.MIT.EDU>
Subject: Scoops ?
To: SCHEME@MC.LCS.MIT.EDU
If you have an implementation of Scoops for either C Scheme (on a vax
VMS), or MacScheme (on a Macintosh), please let me know. Better yet,
if you can do it, mail me the Scheme code. Thanks a lot.
To be clear, I am looking for both implementations, not just any one,
but evidently, either one is much better than none...
Michel Debar - Fndp Computing Centre - Rue Grandgagnage 21, 5000 namur
Belgium - Tel + 32 (81) 22 06 31
mdebar%bnandp11.bitnet@cunyvm.cuny.edu
∂07-Jan-88 1732 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scoops ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 17:32:02 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Jan 88 20:09:04 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA26851; Thu, 7 Jan 88 16:38:45 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Jan 88 17:11:54 GMT
From: marge.math.binghamton.edu!sullivan@bingvaxu.cc.binghamton.edu (fred sullivan)
Organization: SUNY Binghamton, NY
Subject: Re: Scoops ?
Message-Id: <759@bingvaxu.cc.binghamton.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I also need scoops for c-scheme. Is it available?
Thanks,
Fred Sullivan
Department of Mathematical Sciences
State University of New York at Binghamton
Binghamton, New York 13903
Email: sullivan@marge.math.binghamton.edu
∂07-Jan-88 1848 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the Amiga
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 18:48:22 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Jan 88 21:43:40 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA22119; Thu, 7 Jan 88 12:09:07 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Jan 88 16:17:58 GMT
From: goldberg@acf3.nyu.edu (Benjamin Goldberg)
Organization: New York Univsersity
Subject: Scheme for the Amiga
Message-Id: <518@acf3.NYU.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anyone know of a Scheme implementation for the Amiga?
-Ben Goldberg
∂08-Jan-88 1659 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Jan 88 16:59:50 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 8 Jan 88 19:56:27 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA20886; Fri, 8 Jan 88 15:28:24 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Jan 88 21:45:30 GMT
From: wpd@athena.mit.edu (William P Doyle)
Organization: Massachusetts Institute of Technology
Subject: Re: Scheme for the Amiga
Message-Id: <2194@bloom-beacon.MIT.EDU>
References: <518@acf3.NYU.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <518@acf3.NYU.EDU> goldberg@acf3.nyu.edu (Benjamin Goldberg) writes:
>Does anyone know of a Scheme implementation for the Amiga?
I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an
easy thing to do. First of all, there is no way CScheme will work on a
machine with only 0.5M of RAM. I have got it working with 2.5M, but it
really wants 4M, heavy sigh... Also, if you want to work on implementing
it, you will need a hard disk. But the important thing is, it does exist and
is alive. I am currently trying to work on the interrupt scheme (sorry, no
pun intended) before I am happy with it.
______________________________________________
| |
| Patrick Doyle wpd@ATHENA.MIT.EDU |
∂11-Jan-88 0520 @MC.LCS.MIT.EDU:AHAAS@G.BBN.COM leaving
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 05:20:17 PST
Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 11 Jan 88 08:17:00 EST
Date: Mon 11 Jan 88 08:15:32-EST
From: AHAAS@G.BBN.COM
Subject: leaving
To: scheme@MC.LCS.MIT.EDU
Please take me off the list.
-------
∂11-Jan-88 1355 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Problem with MIT-Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 88 13:55:23 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Jan 88 16:48:44 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA03617; Mon, 11 Jan 88 13:36:23 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Jan 88 18:07:05 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson)
Organization: NCR E&M Cambridge, Ohio
Subject: Problem with MIT-Scheme
Message-Id: <1821614@ncrcpx.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've tried to send this to MIT, but couldn't get through:
To: info-cschme-request%oz@mc.lcs.mit.edu, INFO-CSCHEME%OZ@MC.LCS.MIT.EDU
Subject: join scheme mailing list & problem
I am trying to get MIT Scheme up on an NCR Tower 32 - SYSVR2. I've
got everything going along just fine untill:
Psbtobin /usr/craig/Scheme/runtime/screen.psb
Psbtobin /usr/craig/Scheme/runtime/sdata.psb
/usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped
*** Error code 1
`runtime/scheme.bin' not remade because of errors
Not very nice. I looked into Psbtobin and found it to be quite
involved. I wonder if you know of any bugs that may be obvious. An
sdb run on the core shows:
$ sdb Psbtobin ../runtime/core
0x80a in read_a_string:138: *string++ = ((char) read_a_char());
*w
133: To[STRING_LENGTH] = Make_Non_Pointer(TC_FIXNUM, len);
134:
135: /* Space */
136: getc(Portable_File);
137: while (--len >= 0)
138: *string++ = ((char) read_a_char());
139: *string = '\0';
140: return (To + Pointer_Count);
141: }
142: !
*t
read_a_string(To=0x8134,Slot=0x7228) [Psbtobin.c:138]
Read_External(N=300,Table=0x7078,To=0x7528) [Psbtobin.c:410]
do_it() [Psbtobin.c:750]
Setup_Program(argc=1,argv=0xdffd84,Noptions=0,Options=0x5274) [Psbtobin.c:226]
main(argc=1,argv=0xdffd84,14679436) [Psbtobin.c:851]
*To/s
'7↑?J↑Z_}
*To/x
0x8134
*To/2x
0x8134 0x7228
*Pointer_Count/2x
0x37ff4b 0xdfc63b
*
BTW, adb agrees with sdb about the arguments:
$ adb Psbtobin ../runtime/core
ready
$c
Read_External+0x4e: read_a_string (0x8134, 0x7228)
do_it+0x58: Read_External (0x12c, 0x7078, 0x7528)
Setup_Program+0x76: do_it (0x5274)
main+0x22: Setup_Program (0x1, 0xdffd84, 0x0, 0x5274)
start%+0x2c: main (0x1)
???: start% (0x518f2eaf, 0x841ef, 0xc2f48)
$q
Can you be of any help? I would really like to get this stuff going.
Thanks in advance.
--
R. Craig Peterson "Next time someone asks you if you're a god
ncrlnk!ncrcam!ncrcpx!craig say YES!!"
N8INO Ghost Busters
E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)
∂13-Jan-88 1724 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Request for C-Scheme info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 17:24:48 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 13 Jan 88 20:19:17 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA03417; Wed, 13 Jan 88 16:49:01 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Jan 88 03:57:15 GMT
From: pbox!okstate!norman@rutgers.edu (Norman Graham)
Organization: Oklahoma State Univ., Stillwater
Subject: Request for C-Scheme info
Message-Id: <3057@okstate.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I'm about to uucp C-Scheme from Ohio State, but before I do I would
like to know what I'm getting myself into. Some of the questions
going through my mind right now are
- Is this thing SysV compatible?
- If it's not, is it easily portable (or has someone else done it :-)?
- Is it a decent implementation?
- Is it documented?
- Is it the greatest thing since sliced bread?
If it is not sysV compatible I would appreciate hearing any war stories
about porting it.
Please send mail to me as I'm sure that this has been discussed before.
--
Norman Graham
Oklahoma State University Internet: norman@a.cs.okstate.edu
Computing and Information Sciences UUCP: {cbosgd, ihnp4,
219 Mathematical Sciences Building rutgers}!okstate!norman
Stillwater, OK 74078-0599
∂13-Jan-88 1808 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0 ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 88 18:08:30 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Jan 88 22:46:00 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA06955; Tue, 12 Jan 88 19:22:51 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 12 Jan 88 20:37:39 GMT
From: gt-cmmsr!rr@gatech.edu (Richard Robison)
Organization: Center for Man-Machine Systems Research - Ga Tech
Subject: Scheme for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0 ???
Message-Id: <31868@gt-cmmsr.GATECH.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is Scheme available for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0? Thanks.
-Richard
--
Richard Robison
UUCP: rr@gt-cmmsr.UUCP (404-894-6221)
...!{allegra,hplabs,ihnp4,ulysses}!gatech!gt-cmmsr!rr
INTERNET: rr@cmmsr.gatech.edu
∂15-Jan-88 1911 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: SYSV Scheme was Re: Request for C-Scheme info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 19:11:06 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Jan 88 18:03:39 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA22413; Fri, 15 Jan 88 11:45:20 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 Jan 88 14:43:22 GMT
From: ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcam!ncrcpx!craig@sdcsvax.ucsd.edu (R. Craig Peterson)
Organization: NCR E&M Cambridge, Ohio
Subject: Re: SYSV Scheme was Re: Request for C-Scheme info
Message-Id: <1821615@ncrcpx.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <3057@okstate.UUCP> norman@a.cs.okstate.edu writes:
>I'm about to uucp C-Scheme from Ohio State, but before I do I would
>like to know what I'm getting myself into. Some of the questions
>going through my mind right now are
>
> - Is this thing SysV compatible?
> - If it's not, is it easily portable (or has someone else done it :-)?
> - Is it a decent implementation?
> - Is it documented?
> - Is it the greatest thing since sliced bread?
>
>If it is not sysV compatible I would appreciate hearing any war stories
>about porting it.
>
>Please send mail to me as I'm sure that this has been discussed before.
>
>--
>Norman Graham
>Oklahoma State University Internet: norman@a.cs.okstate.edu
>Computing and Information Sciences UUCP: {cbosgd, ihnp4,
>219 Mathematical Sciences Building rutgers}!okstate!norman
>Stillwater, OK 74078-0599
I've uploaded the MIT-Scheme from OSU. I have a few System VR2 boxes
here, and I've worked at porting it to SYSV. I've got it working just
fine until part way through its conversion of some files from its
non-machine-specific format to something for your machine; creating
its runtime library stuff. It ends up getting a segmentation
violation. I haven't had any chance to look at it for a couple of
weeks as I'm very busy getting ready for a demo for another product
here. If you'd like what I've done, I'd be glad to send it to you.
I'm still looking for help!! Does anyone know of any known bugs.
Here's the scenario:
I am trying to get MIT Scheme up on an NCR Tower 32 - SYSVR2. I've
got everything going along just fine until:
Psbtobin /usr/craig/Scheme/runtime/screen.psb
Psbtobin /usr/craig/Scheme/runtime/sdata.psb
/usr/craig/Scheme/microcode/Psbtobin: Segmentation violation -- Core dumped
*** Error code 1
`runtime/scheme.bin' not remade because of errors
Not very nice. I looked into Psbtobin and found it to be quite
involved. I wonder if you know of any bugs that may be obvious. An
sdb run on the core shows:
$ sdb Psbtobin ../runtime/core
0x80a in read_a_string:138: *string++ = ((char) read_a_char());
*w
133: To[STRING_LENGTH] = Make_Non_Pointer(TC_FIXNUM, len);
134:
135: /* Space */
136: getc(Portable_File);
137: while (--len >= 0)
138: *string++ = ((char) read_a_char());
139: *string = '\0';
140: return (To + Pointer_Count);
141: }
142: !
*t
read_a_string(To=0x8134,Slot=0x7228) [Psbtobin.c:138]
Read_External(N=300,Table=0x7078,To=0x7528) [Psbtobin.c:410]
do_it() [Psbtobin.c:750]
Setup_Program(argc=1,argv=0xdffd84,Noptions=0,Options=0x5274) [Psbtobin.c:226]
main(argc=1,argv=0xdffd84,14679436) [Psbtobin.c:851]
*To/s
'7↑?J↑Z_}
*To/x
0x8134
*To/2x
0x8134 0x7228
*Pointer_Count/2x
0x37ff4b 0xdfc63b
*
BTW, adb agrees with sdb about the arguments:
$ adb Psbtobin ../runtime/core
ready
$c
Read_External+0x4e: read_a_string (0x8134, 0x7228)
do_it+0x58: Read_External (0x12c, 0x7078, 0x7528)
Setup_Program+0x76: do_it (0x5274)
main+0x22: Setup_Program (0x1, 0xdffd84, 0x0, 0x5274)
start%+0x2c: main (0x1)
???: start% (0x518f2eaf, 0x841ef, 0xc2f48)
$q
Can you be of any help? I would really like to get this stuff going.
Thanks in advance.
--
R. Craig Peterson "Next time someone asks you if you're a god
ncrlnk!ncrcam!ncrcpx!craig say YES!!"
N8INO Ghost Busters
E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)
∂20-Jan-88 0207 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Problems bringing up CScheme 6.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 88 02:07:20 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Jan 88 05:03:37 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28920; Wed, 20 Jan 88 01:30:13 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Jan 88 16:48:32 GMT
From: ingr!b14!clark@uunet.uu.net (Clark Williams)
Organization: Intergraph Corp. Huntsville, Al
Subject: Problems bringing up CScheme 6.1
Message-Id: <389@b14.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am attempting to bring up CScheme 6.1 on two machines and am encountering
difficulties on both. I am hoping that someone with a little more Lisp/Scheme
experience than I have will be able to spot my problems or at least point me
in the right direction.
The first machine is an Intergraph InterPro-220 workstation. This machine
runs System V release 3 on the Clipper RISC processor set. After editing
config.h and setting the relevant parameters, a make yields this message:
> cd runtime;../microcode/scheme -fasl runmd.bin <../etc/make_band.scm
>Scheme Microcode Version 10.2
>MIT Scheme, unix [ATT (V)] version
>
>utabs.bin loaded purified evaluated
>implmd.bin loaded purified evaluated
>boot.bin loaded purified evaluated
.
. <<<-------------------18 lines deleted
.
>numpar.bin loaded purified evaluated
>numunp.bin loaded
>
>Purify phase error 9a0, 99f
>
>Inconsistency detected.
>*** Error code 1
>
>Stop.
My question is, where should I start looking? I am new to the Lisp/Scheme world
and I don't even know what 'purify' means in this context. Should I look in the
Psbtobin.c code for a problem translating the .psb file to a .bin file? Or
should I look in the purify.c code?
The second machine is an Intergraph Micro II (MicroVax II with our boards)
running VMS 4.5 (yes I know, BLECH!). This machine gets through the initial
load-purify-evaluate phase and then this happens:
>Cold load finished. Type
>
>((access finish-load runtime-system))
>
>to load the rest of the system.
>
>1 ]=> ((access finish-load runtime-system))
>No such file #("pathname" () () "emacs" "bin" NEWEST)
>
>2 Error->
It just hasn't been my day.
Any insight to these problems would be greatly appreciated.
--
_ /| | Clark Williams
Ack Thippfft! \'o.O` | Intergraph Corp.
=(___)= | {uunet|ihnp4}!ingr!b14!clark
U | (205) 772-6881
∂21-Jan-88 1949 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Question: Are the GABRIEL-benchmarks translated into SCHEME already?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 19:48:52 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Jan 88 22:41:45 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA18118; Thu, 21 Jan 88 19:10:18 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Jan 88 15:08:18 GMT
From: mcvax!dutrun!dutesta!brouw@uunet.uu.net (Gerard Brouwer)
Organization: Delft University of Technology, Netherlands
Subject: Question: Are the GABRIEL-benchmarks translated into SCHEME already?
Message-Id: <1068@dutesta.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In the book 'Performance and Evaluation of Lisp Systems' the writer
Richard P.Gabriel presents a dozen famous benchmarks. They are written in
CommonLisp. What I am looking for is a translation of these benchmarks
in SCHEME. If anyone knows if these SCHEME-benchmarks do exist,
and where to get them please contact me. Thanks for your cooperation.
Gerard Brouwer,
Delft University of Technology UUCP: MCVAX!dutrun!dutesta!brouw
Department of Electrical Engeneering
Section Computer Architecture
Mekelweg 4
2628 CD Delft, The Netherlands
∂22-Jan-88 0903 @MC.LCS.MIT.EDU:rnoss%isis.educ.lon.ac.uk@NSS.Cs.Ucl.AC.UK
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 09:03:04 PST
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 22 Jan 88 11:58:14 EST
Received: from isis.educ.lon.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07684; 22 Jan 88 16:53 GMT
Date: 22 Jan 1988 16:51:53-GMT
From: rnoss <rnoss%isis.educ.lon.ac.uk@NSS.Cs.Ucl.AC.UK>
To: scheme <@NSS.Cs.Ucl.AC.UK:scheme@mc.lcs.mit.edu>
Hi -- I've just been in contact with Hal Abelson who says you may
be able to help us. We have a Pyramid running unix. Is there a scheme
that we could run? How do we get it? How much? etc.....
All information would be welcome
Thanks
Richard Noss
(University of London -- Institute of Education)
∂22-Jan-88 1116 @MC.LCS.MIT.EDU,@RELAY.CS.NET:tjfs@HPLB.CSNET Problems bringing up CScheme 6.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 11:16:40 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jan 88 14:13:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa00502; 22 Jan 88 12:45 EST
Received: from hplb by RELAY.CS.NET id ac16785; 22 Jan 88 12:33 EST
Received: from CSNet-Relay by hplb.csnet; 21 Jan 88 4:37:44-WET (Thu)
Received: from relay.cs.net by RELAY.CS.NET id gf00770; 20 Jan 88 11:19 EST
Received: from mc.lcs.mit.edu by RELAY.CS.NET id aa21723; 20 Jan 88 5:15 EST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Jan 88 05:03:37 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28920; Wed, 20 Jan 88 01:30:13 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Jan 88 16:48:32 GMT
From: Clark Williams <clark%b14%ingr@uunet.uu.net>
Organization: Intergraph Corp. Huntsville, Al
Subject: Problems bringing up CScheme 6.1
Message-Id: <389@b14.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am attempting to bring up CScheme 6.1 on two machines and am encountering
difficulties on both. I am hoping that someone with a little more Lisp/Scheme
experience than I have will be able to spot my problems or at least point me
in the right direction.
The first machine is an Intergraph InterPro-220 workstation. This machine
runs System V release 3 on the Clipper RISC processor set. After editing
config.h and setting the relevant parameters, a make yields this message:
> cd runtime;../microcode/scheme -fasl runmd.bin <../etc/make_band.scm
>Scheme Microcode Version 10.2
>MIT Scheme, unix [ATT (V)] version
>
>utabs.bin loaded purified evaluated
>implmd.bin loaded purified evaluated
>boot.bin loaded purified evaluated
.
. <<<-------------------18 lines deleted
.
>numpar.bin loaded purified evaluated
>numunp.bin loaded
>
>Purify phase error 9a0, 99f
>
>Inconsistency detected.
>*** Error code 1
>
>Stop.
My question is, where should I start looking? I am new to the Lisp/Scheme world
and I don't even know what 'purify' means in this context. Should I look in the
Psbtobin.c code for a problem translating the .psb file to a .bin file? Or
should I look in the purify.c code?
The second machine is an Intergraph Micro II (MicroVax II with our boards)
running VMS 4.5 (yes I know, BLECH!). This machine gets through the initial
load-purify-evaluate phase and then this happens:
>Cold load finished. Type
>
>((access finish-load runtime-system))
>
>to load the rest of the system.
>
>1 ]=> ((access finish-load runtime-system))
>No such file #("pathname" () () "emacs" "bin" NEWEST)
>
>2 Error->
It just hasn't been my day.
Any insight to these problems would be greatly appreciated.
--
_ /| | Clark Williams
Ack Thippfft! \'o.O` | Intergraph Corp.
=(___)= | {uunet|ihnp4}!ingr!b14!clark
U | (205) 772-6881
∂22-Jan-88 1428 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com Re: Are the GABRIEL-benchmarks translated into SCHEME already?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 14:27:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jan 88 17:24:15 EST
Received: from relay2.cs.net by RELAY.CS.NET id ad03422; 22 Jan 88 16:14 EST
Received: from tektronix.tek.com by RELAY.CS.NET id cr18045; 22 Jan 88 16:00 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA04647; Fri, 22 Jan 88 09:58:02 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA09354; Fri, 22 Jan 88 09:57:49 PST
Date: Fri, 22 Jan 88 09:57:49 PST
From: Will Clinger <willc%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8801221757.AA09354@tekchips.TEK.COM>
To: scheme@mc.lcs.mit.edu
Subject: Re: Are the GABRIEL-benchmarks translated into SCHEME already?
Cc: mcvax!dutrun!dutesta!brouw@uunet.uu.net
I have translated all but two (STAK and POLY) of the Gabriel benchmarks
into Scheme and have sent them to a number of people. In a couple of weeks
I will submit them to the Scheme "yellow pages" after fixing the bugs and
non-portable constructions that have been reported to me. In the meantime
I'm willing to send them to people who can't wait.
Today is my last day as an employee of Tektronix. My new address will be
William Clinger
Semantic Microsystems, Inc.
4470 SW Hall Blvd, Suite 340
Beaverton, OR 97005
Telephone: (503) 643-4539
Since Semantic will probably be consulting for Tektronix, I think I will
still be able to read mail sent to:
willc%tekchips.tek.com@relay.cs.net
I will probably not log in more than once a week or so, though. Semantic
has had an inactive account on Compuserve, which I expect to reactivate.
Peace, Will
∂23-Jan-88 0008 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu suggestions for the next revision of scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 00:08:03 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Jan 88 03:04:42 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA22261; Fri, 22 Jan 88 23:51:38 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Jan 88 17:44:01 GMT
From: jh@ohio-state.arpa (#Hein{nen Juha)
Organization: Tampere University of Technology, Finland
Subject: suggestions for the next revision of scheme
Message-Id: <545@tutor.tut.fi>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have a couple of suggestions for the next revision of Scheme that
all deal with orthogonality issues:
First, named let* and letrec should be included in Scheme. I have
several times run into situations where a construct like
(let* loop ((x ...) (y ...x...)) ...)
would have been useful. So far I haven't needed named letrec but, at
least for completenes, it shouldn't be left out.
Second, map and for-each should apply also to strings and vectors.
Why should Scheme provide better treatment for list than for other
structured types?
Finally, do should be abolished altogether. Is far too complicated
operation compared to the rest of Scheme and seems like a relic from
ancient times.
--
Juha Heinanen
Tampere Univ. of Technology
Finland
jh@tut.fi (internet), tut!jh (UUCP)
∂23-Jan-88 1209 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Next R*RS meeting...
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 12:09:49 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 23 Jan 88 15:09:19 EST
Received: by iuvax.cs.indiana.edu; id AA11432; Sat, 23 Jan 88 15:07:16 EST
Date: Sat, 23 Jan 88 15:07:16 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8801232007.AA11432@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Next R*RS meeting...
At the last Scheme meeting (Boston, Summer 87) I volunteered to
organize the next Scheme meeting, to be held at Indiana sometime
this spring. I would still be pleased to do so, if people think
it would be a good idea, but we might want to consider getting
together at the Lisp conference this summer instead and perhaps
holding the Indiana meeting next spring. I think this was
suggested last summer, but I remember someone expressing concern
that people may not be able to make the Lisp conference, since
at that time it was expected to be overseas.
Comments?
Kent
PS. I'm hoping this is an issue we can reach a decision on!
∂25-Jan-88 0040 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET Next R*RS meeting...
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 00:40:09 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Jan 88 03:39:48 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07222; 25 Jan 88 3:39 EST
Received: from brandeis by csnet-relay.csnet id ab03817; 25 Jan 88 3:27 EST
Received: by brandeis.ARPA (5.51/4.7)
id AA00620; Sun, 24 Jan 88 16:52:15 EST
Date: Sun, 24 Jan 88 16:52:15 EST
From: James Miller <jmiller%brandeis.csnet@RELAY.CS.NET>
To: dyb%iuvax.cs.indiana.edu@RELAY.CS.NET
Cc: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET
In-Reply-To: "R. Kent Dybvig"'s message of Sat, 23 Jan 88 15:07:16 EST <8801232007.AA11432@iuvax.cs.indiana.edu>
Subject: Next R*RS meeting...
I'd prefer that the meeting coincide with the Lisp conference if
possible.
--Jim
∂27-Jan-88 0648 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA T a dialect of Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 06:48:25 PST
Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 27 Jan 88 09:36:37 EST
Received: by ATHENA.CS.YALE.EDU; Wed, 27 Jan 88 09:34:08 EST
Date: Wed, 27 Jan 88 09:34:08 EST
From: James Philbin <philbin-jim@YALE.ARPA>
Full-Name: James Philbin
Message-Id: <8801271434.AA06384@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-aac0/AAC0)
via WIMP-MAIL (Version 1.2/1.4) ; Wed Jan 27 09:26:49
Subject: T a dialect of Scheme
To: scheme@mc.lcs.mit.edu
The T Programming Language
T is a superset of Scheme developed at Yale University. T's extensions
to Scheme include:
multiple return values - a very efficient implementation,
objects - a simple and efficient object system,
debugger and inspector,
locales - first class environments,
macros - a syntax system,
unwind-protect,
dynamic binding,
structures - efficient and integrated into the object system,
tables - a generalize package
pools, weak pointers, and weak tables.
Although the default environment is the T programming language (a Scheme
dialect based on the Revised Report on Scheme), an environment comforming
to the Revised↑3 Report on Scheme is also available. T is intended for
use in education, systems programming, AI programming, and for programming
language design and development. The system and compiler are written almost
entirely in T.
A new version of T (version 3.0) was released in January 1987. This system
includes both an interpreter and a highly optimizing native code compiler
(described in a paper by Kranz et al. in the Proceedings of the 1986 SIGPLAN
Compiler Construction Conference) that compiles closures efficiently. This
compiler produces code that is competitive with the best C and Pascal
compilers. The following benchmarks from "Performance and Evaluation of
Lisp Systems" by Gabrial were run on a Sun 3/160 in the most optimized
mode of the compiler.
tak .22 rdiv2 .76 fprint 1.80
puzzle 2.40 destru .98 fread 3.08
triangle 79.18 deriv 2.44 tprint 1.46
idiv2 .50 dderiv 3.02
T is available via Internet FTP. Telnet to PREP.AI.MIT.EDU and log
in as user scheme, password scheme. The login shell is an FTP program.
Send one or more of the following files:
/t/readme.tar.Z
/t/hp.tar.Z executable image for HP-UX
/t/sun.tar.Z executable image for SUN
/t/aegis.tar.Z executable image for Apollo Domain
/t/vax_unix.tar.Z executable image for VAX running 4.2BSD, 4.2BSD or Ultrix
/t/sources.tar.Z source code for compiler and runtime system
If you can't get T this way, try to get it from someone who has it, or,
Yale will mail you a tape for $200 (outside US $250).
For more information contact Linda Abelli or Chris Hatchell at:
T Project
Yale University Dept. of Computer Science
PO Box 2158 Yale Station
New Haven, CT 06520
Email: t-project@yale.edu,
decvax!yale!t-project.uucp, or
tproj@YALECS.BITNET
Phone: (203) 432-2381
-------
∂27-Jan-88 0912 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Cleanup needed.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:11:54 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Jan 88 11:50:01 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 27 Jan 88 10:44:19 EST
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Received: from FRSAC11.BITNET (NETWORK@FRSAC12) by MITVMA.MIT.EDU (Mailer
X1.25) with BSMTP id 0745; Wed, 27 Jan 88 10:24:24 EST
Date: Wed, 27 Jan 88 16:18:31 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Subject: Cleanup needed.
+From: #Hein{nen Juha <jh@ohio-state.arpa>
+Subject: suggestions for the next revision of scheme
+..
+I have a couple of suggestions for the next revision of Scheme that
+all deal with orthogonality issues:
+..
+Second, map and for-each should apply also to strings and vectors.
+Why should Scheme provide better treatment for list than for other
+structured types?
+..
+Finally, do should be abolished altogether. Is far too complicated
+operation compared to the rest of Scheme and seems like a relic from
+ancient times.
+..
I do support the above remarks.
If there is generic math functions, list/vector/string generic
functions seems natural.
I was surprised too at the "do" construct, that is far from
usual scheme elegance. (I find the current "do" quite baroque.)
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@mitvma.mit.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂27-Jan-88 1933 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Versions of Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 19:30:51 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Jan 88 22:28:04 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA08001; Wed, 27 Jan 88 18:51:51 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 27 Jan 88 18:25:02 GMT
From: fowler@pyr.gatech.edu (FREDERICK C. FOWLER)
Organization: Georgia Institute of Technology, Atlanta
Subject: Parallel Versions of Scheme
Message-Id: <4883@pyr.gatech.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can anyone tell me if there are any versions of scheme designed for
parallel processing? I've heard of something called Multi-Scheme, and
I think that I saw a reference to a parallel Scheme in Computer Language,
but that's all I've been able to find out.
Fred Fowler
∂28-Jan-88 0842 @MC.LCS.MIT.EDU:allen@lisperanto.bbn.com Parallel Versions of Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 08:42:43 PST
Received: from BBN.COM (TCP 20026200172) by MC.LCS.MIT.EDU 28 Jan 88 11:23:07 EST
Received: from lisperanto.bbn.com by BBN.COM id aa10576; 28 Jan 88 11:05 EST
Date: Thu Jan 28 11:05:12 EST 1988
From: allen@BBN.COM
To: fowler@pyr.gatech.edu
CC: scheme@mc.lcs.mit.edu
In-reply-to: "FREDERICK C. FOWLER"'s message of 27 Jan 88 18:25:02 GMT <4883@pyr.gatech.EDU>
Subject: Parallel Versions of Scheme
we (bbn advanced computers) have implemented a version of scheme,
based on MIT cscheme, for the butterfly multiprocessor. see our paper
in the proceedings of aaai-87 -- "recent developments in butterfly
lisp" by seth steinberg, larry stabile, and myself, for a description
of the system. feel free to contact me if you have any questions not
answered by the paper.
/don allen
∂28-Jan-88 0951 @MC.LCS.MIT.EDU:SGR@STONY-BROOK.SCRC.Symbolics.COM Parallel Versions of Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 09:50:50 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 28 Jan 88 11:26:49 EST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330376; Thu 28-Jan-88 11:26:29 EST
Date: Thu, 28 Jan 88 11:26 EST
From: Stephen G. Rowley <SGR@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Parallel Versions of Scheme
To: fowler@pyr.gatech.edu, scheme@mc.lcs.mit.edu
In-Reply-To: <4883@pyr.gatech.EDU>
Message-ID: <19880128162634.3.SGR@GROUSE.SCRC.Symbolics.COM>
Date: 27 Jan 88 18:25:02 GMT
From: fowler@pyr.gatech.edu (FREDERICK C. FOWLER)
Can anyone tell me if there are any versions of scheme designed for
parallel processing? I've heard of something called Multi-Scheme, and
I think that I saw a reference to a parallel Scheme in Computer Language,
but that's all I've been able to find out.
Here's the reference (and the author) for MultiScheme:
Date: Wed, 14 Oct 87 16:13:06 EDT
From: James Miller <jmiller%brandeis.csnet@RELAY.CS.NET>
To: Scheme%MC.LCS.MIT.EDU@RELAY.CS.NET
Subject: MultiScheme
My dissertation, "MultiScheme: A Parallel Processing System Based on
MIT Scheme," is available from the MIT Lab for Computer Science
publications office (545 Technology Square, Cambridge, MA 02139), as
MIT/LCS/TR-402. It reports on an implementation of Scheme extended to
support the FUTURE construct and speculative computation. It has a
number of examples showing relationships to: embedding logic variables
in Scheme, McCarthy's AMB and fair merge, higher order streams
processing, data-flow parallelism, and so forth.
The current release of MIT CScheme contains a serial processor
implementation of the work reported in the thesis. BBN's Butterfly
Lisp product is based directly on the (truly parallel) implementation.
∂28-Jan-88 1633 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Some RRRS comments/corrections
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 16:33:44 PST
Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 28 Jan 88 19:32:40 EST
Date: 28 Jan 1988 19:31-EST
Sender: SUSSMAN@G.BBN.COM
Subject: Some RRRS comments/corrections
From: SUSSMAN@G.BBN.COM
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: allen@SOCRATES.BBN.COM, quigley@SOCRATES.BBN.COM
Cc: sas@BFLY-VAX.BBN.COM, amellor@BFLY-VAX.BBN.COM
Cc: sussman@G.BBN.COM
Message-ID: <[G.BBN.COM]28-Jan-88 19:31:32.SUSSMAN>
Here are a few things we noticed while documenting Butterfly Scheme:
CI in string and character procedure names:
You describe it as a suffix, and give its relationship to the ? suffix.
But it is generally embedded earlier in the name (not ...ci?). You probably
want to just say they have CI in their names.
DO:
The expressions after the <test> are optional according to the text,
but the template shows one or more expressions. Apparently it is the
template that is wrong.
TRUNCATE:
The description is incomplete -- note that it fails to specify
the sign of the answer.
Julie
∂29-Jan-88 1423 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Amiga?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 88 14:23:29 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Jan 88 17:19:43 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28785; Fri, 29 Jan 88 12:48:44 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Jan 88 04:25:00 GMT
From: kaplan@b.cs.uiuc.edu
Subject: Scheme for Amiga?
Message-Id: <189900003@uiucdcsb>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Several people on the net have indicated they are working on Scheme ports
for the Amiga. I am teaching a course using Scheme this semester and some
of my students have Amiga's and want to try get Scheme for it.
If anyone out there has a port they are prepared to make available, I would
be most grateful.
My best email addresses are:
kaplan@a.cs.uiuc.edu
{ihnp4, seismo, research}!uiucdcs!kaplan
Thanks in advance,
Simon Kaplan
∂30-Jan-88 0554 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU testing, please ignore
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 05:54:26 PST
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 30 Jan 88 08:53:33 EST
Received: by MURREN.AI.MIT.EDU; Sat, 30 Jan 88 08:59:15 est
Date: Sat, 30 Jan 88 08:59:15 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801301359.AA04713@murren>
To: rrrs-authors@mc.lcs.mit.edu
Subject: testing, please ignore
Reply-To: hal@ai.ai.mit.edu
∂30-Jan-88 0652 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU "Well, Stanley,here's another nice mess you've gotten us into."
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 06:51:54 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 09:43:09 EST
Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 09:45:47 est
Date: Sat, 30 Jan 88 09:45:47 est
From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801301445.AA04589@zohar>
To: rrrs-authors@mc.lcs.mit.edu
Subject: "Well, Stanley,here's another nice mess you've gotten us into."
Reply-To: hal@ai.ai.mit.edu
Over the past two months there have been a number of discussions, on
and off of this mailing list, concerning a proposed Scheme
standardization effort.
Clyde Camp has proposed standardizing Scheme through IEEE, but there
is apparently some sentiment for a closer connection with Common Lisp
and X3, and there is also sentiment for not standardizing Scheme at
all.
Many RRRS-AUTHORS (including me) have not contributed to this
discussion, presumably because we were confused/bored/indifferent. I
think that it's time for a real discussion to start.
1. People who have something to say about this issue should mail their
comments to all of RRRS-AUTHORS. Outrageous flammage is welcome,
as always. My main concern is that if (and I do mean IF) a
standardization process is to begin, then it should begin with a
proposal that is made on behalf of the RRRS-AUTHORS as a group.
2. I think we should have a meeting sometime during the next two
months, whose agenda is to discuss the standardization issue and to
produce a plan for standardization, if that is the decision of the
group. Given the political nature of this discussion, it is unlikely
that any technical work is going to get done, so this meeting should
be in addition to a technical meeting that would take place later,
presumably in conjunction with the Lisp conference in July.
Some issues to be discussed:
Do we want to endorse a Scheme standardization process?
What is the appropriate standards organization?
Who is going to do the work?
Would anyone like to volunteer to host the meeting?
∂30-Jan-88 1239 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU forwarded message from Dick Gabriel
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 12:39:40 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 14:32:00 EST
Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 14:34:37 est
Date: Sat, 30 Jan 88 14:34:37 est
From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801301934.AA04740@zohar>
To: rrrs-authors@mc.lcs.mit.edu
Subject: forwarded message from Dick Gabriel
Reply-To: hal@ai.ai.mit.edu
This is a message about Scheme standardization that was mailed to a
new people a few days ago. I think it needs to be mroe widely seen.
Please send comments to all RRRS-AUTHORS
-- Hal
From RPG@SAIL.Stanford.EDU Sat Jan 30 14:32:10 1988
Date: 30 Jan 88 1034 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Proposal to Handle All Possible Decisions on Scheme Standardization
To: hal@AI.AI.MIT.EDU
<HAl, I have not seen any reaction to my message, could you forward any?
I am on RRRS-AUTHORS.>
Gentlemen. I have talked with Bob Mathis regarding the standardization
of Scheme, and he and I agreed on the following remarks and suggestions.
1. To the outside world, Lisp and Scheme are not distinguishable. To
have separate technical working groups for them is not a sensible
situation, especially within 2 separate organizations.
2. ANSI recognizes X3J13 as the technical working group for Lisp in
the US. Therefore, an IEEE effort would have no standing or voice in
any ISO work relating to Lisp, which is regarded as including dialects
such as Scheme.
We understand that there is some anxiety about whether to standardize
Scheme, and if so on what schedule. We are in a position to suggest
several alternatives to you:
3. We can establish a subcommittee within X3J13 for Scheme under the
current X3J13 charter. That subcommittee can work at its own speed on
activities relating to Scheme. Whether that subcommittee ever reported
anything out would be up to it.
4. We can also broaden the charter of X3J13 to specifically include Scheme. A
committee or subcommittee on Scheme could be established with its own time
schedule.
This would accomplish several things for you:
5. You would have a vehicle for standardizing Scheme if and when you
choose. There would be no pressure regarding your decision on this matter.
That is, this can be a vehicle to prevent standardization without your
consent, and it can also be a vehicle for standardization when you
feel like it is appropriate.
6. You would have a voice and standing within any ISO process concerning
Lisp in which you were interested.
7. Any renegade IEEE efforts towards standardizing Scheme would be
officially disallowed through a petition from SPARC to IEEE.
8. The Common Lisp community could be exposed to the Scheme community
and vice versa, bringing benefits to both communities.
9. A rational approach within ISO towards Lisp could be more easily
achieved if the Scheme community was officially represented. We would not
be in a position of the US appearing to be completely Common-Lisp-oriented.
I sent this note to a smaller group than RRRS Authors in order to
keep the discussion among the leaders. Please feel free to distribute this
to people whom I have overlooked.
In order for Bob Mathis and me to file the petition from SPARC to IEEE, a
positive response from the Scheme community is needed. If you decide
for or against this proposal, please let us know.
-rpg-
∂30-Jan-88 1252 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU questions about X3 and Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 12:51:32 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 30 Jan 88 14:39:40 EST
Received: by ZOHAR.AI.MIT.EDU; Sat, 30 Jan 88 14:41:46 est
Date: Sat, 30 Jan 88 14:41:46 est
From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801301941.AA04743@zohar>
To: rpg@sail.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: questions about X3 and Scheme
Reply-To: hal@ai.ai.mit.edu
In your message about Scheme standardization, you wrote
2. ANSI recognizes X3J13 as the technical working group for Lisp in
the US. Therefore, an IEEE effort would have no standing or voice in
any ISO work relating to Lisp, which is regarded as including dialects
such as Scheme.
Could you elaborate on what this means? In particular,
(a) Who regards the X3 effort as including dialects such as Scheme?
(b) Does your comment imply that there could not be an ISO standard
for any Lisp dialect other than for Common Lisp?
∂30-Jan-88 1447 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Clarifications
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 14:47:33 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 30 Jan 88 17:46:59 EST
Date: 30 Jan 88 1445 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Clarifications
To: rrrs-authors@MC.LCS.MIT.EDU
My wording on this point is not good:
2. ANSI recognizes X3J13 as the technical working group for Lisp in
the US. Therefore, an IEEE effort would have no standing or voice in
any ISO work relating to Lisp, which is regarded as including dialects
such as Scheme.
Let me try again.
The charter for X3J13 specifically talks about Common Lisp. I will explain
below why that phrasing is used and how well the strategy behind that
phrasing is working.
ISO has established a Working Group for ISO Lisp. I will explain below why that
phrasing is used and how well the strategy behind that phrasing is working.
ISO has asked the US to participate in the ISO Lisp work, which means ANSI
was asked. ANSI in turn asked X3J13 whether it would participate - because
such participation was mentioned in the X3J13 charter - and X3J13 said it
would. Therefore all representatives to the ISO Lisp Working Group must be
X3J13 members.
The reason X3J13 talks about Common Lisp is because the members of X3J13
do not want to see a Lisp standard - they want to see Lisp be able to
continue to grow without the fetters of standardization. In particular,
they do not want to hamper the Scheme efforts. The pressure in the US that
drives X3J13 is to standardize Common Lisp, and the strategy is to work on
a specific dialect of Lisp to avoid the issue of standardizing Lisp as a
whole. In particular, X3J13 wanted to block an ISO standard Lisp. Hence
one could conclude that Scheme is free to do what it wants.
The reason ISO talks about Lisp is because the European community does not
like Common Lisp and wants to see the right thing become a standard.
Unfortunately from how things have turned out, they want to see a
Scheme-like dialect standardized. Therefore they have slanted things to
include Scheme as far as ISO is concerned, and thus ANSI will probably
view X3J13 as necessarily encompassing the Scheme community.
The history is that the ISO effort started in response to activities
towards starting X3J13. X3J13 was not actually formed when the ISO efforts
started, so X3J13 tried to calm down the ISO effort by writing ``Common
Lisp'' into its charter. The funny (or sad) situation is that each of the
groups behind the ISO effort and the X3J13 effort will point to the other
group as the reason they started their own standardization efforts!
However, the ISO effort went ahead, and the linkage at ANSI between
ISO Lisp and ANSI Common Lisp was made.
Many observers (Mathis and myself included) believe that if ANSI is
asked to recognize Scheme as a different language from Common Lisp, they
will not do so, but ask that X3J13 broaden its charter.
ISO will talk only to ANSI about Lisp, so an IEEE Scheme effort will not
have an official influence on the ISO work, and therefore X3J13 is
probably the only vehicle for ISO-level Scheme work.
Now, the situation has gotten a lot more complicated than what I just
painted. The situation I painted is that the US through X3J13 wants to
limit standardization to Common Lisp and specifically under that name.
The delegation to ISO from the US has as the first item on its agenda a
request to limit the scope of the ISO effort and to try to change the name
of the ISO effort from ISO Lisp to something else, possibly ISO Common
Lisp. However, I fear that the seeds have been planted at ISO - as they
were accidentally at ANSI - in such a way that Common Lisp is not
distinguishable from Lisp, and that the attempted change will not work
(due to ISO reluctance).
Meanwhile, a group of Europeans who had previously argued against Common Lisp
have now concluded that the pressing issue is time-to-draft, and that therefore
a cleaned-up Common Lisp is the only possibility, due to manufacturer pressure.
So we might face the situation of the European delegation asking that ISO
Lisp be Common Lisp while ISO refuses to change the charter for the
working group. If this situation were to prevail, we would have ISO Lisp
be Common Lisp. To prevent that, my response (as head of the US
delegation) would be to state the US position as being against Common Lisp
as ISO Lisp, and to propose a family of Lisp dialects, starting with an
ISO Common Lisp dialect and followed by a better standard for ISO Lisp
later. In this case, the Scheme community would have to be brought in -
in my opinion - and that can only happen through X3J13.
The best situation would be for ANSI to have ANSI Common Lisp and for
there not to be an ISO standard, but because the wheels are turning at
ISO, this cannot happen. The next best thing is there to be an ISO Common
Lisp, leaving open indefinitely the possibility of an ISO Lisp. If there
must be an ISO Lisp on the horizon, I believe there ought to be an ANSI
Common Lisp right away and a re-designed ISO Lisp in some years.
There is a fair amount of sympathy for an immediate ANSI Common Lisp
followed by a re-designed Lisp in some years among the X3J13 group. If this
were to come to pass, interaction with the Scheme community is imperative.
Therefore there is ample opportunity for there to be an ISO Lisp that is
not Common Lisp, and I believe the community of people who truly wish ISO Lisp
to be Common Lisp is small.
I hope this clarifies as best as can be done the rather bizarre Lisp
standardization situation. The first ISO Lisp meeting is February 24 or so
in Paris, and we ought to know more about things when we return. As you
may know, I asked Will Clinger to join me in hopes of making something
good of the situation, so you will get his report.
-rpg-
∂30-Jan-88 1517 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 15:16:50 PST
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 30 Jan 88 18:16:02 EST
Received: by MURREN.AI.MIT.EDU; Sat, 30 Jan 88 18:21:16 est
Date: Sat, 30 Jan 88 18:21:16 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801302321.AA05218@murren>
To: RPG@SAIL.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dick Gabriel's message of 30 Jan 88 1445 PST <8801302300.AA05207@murren>
Subject: ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
Reply-To: hal@ai.ai.mit.edu
Your story about Lisp standardization is truly bizarre. It does not
make me very receptive the idea of embroiling Scheme in such a mess.
Do you think it is too late for MIT to trademark the name "LISP" and
thus put an end to all of this nonsense?
∂30-Jan-88 1739 RPG ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
∂30-Jan-88 1515 hal@MURREN.AI.MIT.EDU ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
Received: from murren (MURREN.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jan 88 15:15:00 PST
Received: by MURREN.AI.MIT.EDU; Sat, 30 Jan 88 18:21:16 est
Date: Sat, 30 Jan 88 18:21:16 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8801302321.AA05218@murren>
To: RPG@SAIL.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dick Gabriel's message of 30 Jan 88 1445 PST <8801302300.AA05207@murren>
Subject: ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules
Reply-To: hal@ai.ai.mit.edu
Your story about Lisp standardization is truly bizarre. It does not
make me very receptive the idea of embroiling Scheme in such a mess.
Do you think it is too late for MIT to trademark the name "LISP" and
thus put an end to all of this nonsense?
∂30-Jan-88 1740 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Bizarre Story
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 88 17:39:54 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 30 Jan 88 20:39:22 EST
Date: 30 Jan 88 1738 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Bizarre Story
To: rrrs-authors@MC.LCS.MIT.EDU
Yes, it is quite bizarre, but you get to read about it while I get to live
it. The Common Lisp group tried to think of ways of trademarking ``Lisp''
or ``Common Lisp'' but we are way, way too late.
The only point to my story is that X3J13 can provide a safe haven
from Scheme getting involved in its own mess with standardization, strange
as that suggestion might sound. Essentially we can expand X3J13 to cover
Lisp/Scheme, form a subcommittee, and forget that subcommittee ever existed
(unless you want to standardize, in which case you can make your own schedule).
This would protect you from IEEE, and you can forget about the politics. If you
don't do this, someone can start an IEEE group without your consent and
press ahead in a haphazard way. Maybe you'll be able to stall or whatever
with IEEE, but I can guarantee you can stall forever with X3J13.
Hey, I want to save Scheme from all of this mess, and this looks like
the best way to me.
-rpg-
∂01-Feb-88 1550 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU test message
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 15:50:25 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Feb 88 18:46:59 EST
Date: Mon, 1 Feb 88 18:47:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: test message
To: scheme@MC.LCS.MIT.EDU
Message-ID: <319681.880201.JAR@AI.AI.MIT.EDU>
Test message -- weeding out bad addresses. Please ignore.
∂01-Feb-88 1753 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com re: Next R*RS metting...
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 17:53:14 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Feb 88 20:52:45 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab00539; 1 Feb 88 19:16 EST
Received: from csc.ti.com by RELAY.CS.NET id an27391; 1 Feb 88 19:00 EST
Received: from mips by tilde id AA14226; Mon, 1 Feb 88 17:24:59 CST
Received: by mips id AA00414; Mon, 1 Feb 88 17:20:19 CST
Date: Mon, 1 Feb 88 17:20:19 CST
From: David Bartley <bartley%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802012320.AA00414@mips>
To: rrrs-authors@mc.lcs.mit.edu
Subject: re: Next R*RS metting...
I expect to attend the Lisp conference this summer, so I would favor
the option of meeting there for R*RS discussions. If we do, let's
arrange to tack a day onto the front or back of the conference
schedule so we can allow ourselves enough time to do something
worthwhile.
Hal has suggested that we meet concerning the standardization issue
much sooner than that. Where should that meeting be? X3J13 will be
meeting in Palo Alto March 14-18, so I would expect that I, Will, rpg,
and perhaps Kent Pitman and others could talk things over then.
∂02-Feb-88 1809 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Re: ISO vs ANSI vs IEEE vs X3 vs The Sons of Hercules
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 18:09:28 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 2 Feb 88 21:08:43 EST
Received: from relay2.cs.net by RELAY.CS.NET id ai04566; 2 Feb 88 19:06 EST
Received: from tektronix.tek.com by RELAY.CS.NET id cl05041; 2 Feb 88 18:53 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA08886; Tue, 2 Feb 88 15:10:23 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA28377; Tue, 2 Feb 88 15:10:05 PST
Message-Id: <8802022310.AA28377@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: RPG@SAIL.STANFORD.EDU, willc%tekchips.crl.tek.com@RELAY.CS.NET,
adams%tekchips.crl.tek.com@RELAY.CS.NET
Subject: Re: ISO vs ANSI vs IEEE vs X3 vs The Sons of Hercules
Date: 02 Feb 88 15:10:03 PST (Tue)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
I believe that the formation of a Scheme standardization project within
X3J13 is the worst thing that could possibly happen to Scheme.
Gabriel observes, correctly, that most people confuse Scheme with Common
Lisp and vice versa. Placing the responsibility for Scheme with the
committee whose charter is to standardize Common Lisp could only increase
this particular confusion, while an entirely separate standardization
activity for Scheme would help to relieve the confusion.
Gabriel has suggested, correctly, that having Scheme standardization
under X3J13 would make it more convenient for technical experts from
the Common Lisp community to take part in the standardization of Scheme.
But it would also force technical experts from the Scheme community to
suffer the tedium of X3J13 meetings concerning a language that many of
them care nothing about, if they want any say in the future of Scheme.
Furthermore they would have to pay $200 annually in dues and $1000-$2000
in travel expenses for the privilege.
X3J13 is a committee formed for the purpose of standardizing Common Lisp,
not Scheme or any other dialect of Lisp. It is a committee of institutions,
not individuals. Though I have attended every X3J13 meeting, I will not
be eligible to vote at the next meeting in Palo Alto; Tektronix's
representative will vote, though he will be attending for the first time.
Representatives have made no bones about voting the financial interests
of their companies. Gabriel himself has on several occasions noted that
although he personally favors certain technical positions, he would have
to vote the contrary position in order to protect his company. (While
only a few of the companies that make up X3J13 have financial reasons
for hostility to Scheme, as few or fewer have reasons to be friendly.)
It is not surprising that X3J13 has found it difficult to make technical
progress in such a climate, so the leading technical experts have
essentially given up on all substantive changes (except possibly for
CLOS) and are concentrating their efforts on the cleanup and clarification
committee, ably led by Larry Masinter. The definition of Scheme is
already cleaner than the definition of Common Lisp will be when X3J13
finishes with it. What Scheme needs is some serious language design
work, which is precisely the sort of thing that X3J13 has been unable
to do for Common Lisp.
I believe the root of my disagreement with Gabriel is this: It sounds
to me like Gabriel thinks the Scheme community should get together with
the Common Lisp community and design the next iteration of Common Lisp
(which Fahlman calls Common Lisp 2000) *rather than* going off and
designing the next iteration of Scheme. There's nothing wrong with
working on Common Lisp 2000, but I think Scheme is more important because
Scheme still has a shot at becoming a good language and I don't think
Common Lisp does. Why doesn't it? Because most of the serious flaws
in Common Lisp are attempts to maintain compatibility with old-fashioned
dialects of Lisp. If the designers of Common Lisp were unable to resist
the demands of compatibility when in truth very little Lisp code of
lasting importance had been written in all of human history, then how
do they expect to resist demands that Common Lisp 2000 be compatible
with Common Lisp?
Better to start over. Scheme is one of the best places to start. That's
why I want to preserve it as a distinct entity, not submit it to the
whims of X3J13.
Concerning ISO, it is certainly true that the charter for ISO Lisp would
lead it to supersede all dialects of Lisp. Scheme will be able to escape
this only because of the fortunate historical accident that its name does
not include the word "Lisp", and because a significant number of people
(particularly Europeans) already claim that Scheme is not Lisp. It also
is true that the Scheme community will probably have no say in the
deliberations that lead to the ISO Lisp standard, since there is no formal
standardization effort for Scheme. Gabriel's story of how all this came to
be is accurate. He loses me, though, when he says that
Many observers (Mathis and myself included) believe that if ANSI is
asked to recognize Scheme as a different language from Common Lisp,
they will not do so, but ask that X3J13 broaden its charter.
If X3J13 really wanted to be helpful, it could easily pass a resolution
requesting that ANSI recognize a separate standardization activity for
Scheme, and allow the Scheme community to be represented at the ISO level
as well. (In my opinion, such a resolution would not be useful unless
the Scheme community had already initiated standardization through IEEE
or X3 (but not X3J13).) In my opinion, ANSI would probably listen to
such a resolution coming from X3J13. Even if ANSI did not, X3J13 could
refuse to act on its broadened charter, leaving the Scheme community
free to continue its informal efforts.
In fact, however, it is possible that ANSI (if we initiate standardization
through IEEE) or X3 (if through X3) would *insist* upon a separate
standardization activity for Scheme, even if X3J13 were to recommend
*against* such recognition. It is not unusual for one language
standardization group to claim that another is redundant. I have been
told that in the process of adjudicating such claims the standards
organizations usually get around to asking the users and implementors of
the allegedly redundant language what they think, and they occasionally
listen to the answer. I'm not saying this is likely, but I believe there
is good reason to be optimistic so long as X3J13 is supportive or remains
neutral.
Even if all goes against us, we can continue our work by simply ignoring
the whole matter of standards (which is what we have done so far) and we
probably would not get into a situation much worse than the one the Lisp
world is already in, through no fault of ours.
Peace,
William Clinger
Semantic Microsystems, Inc.
∂02-Feb-88 2101 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 88 21:01:06 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 3 Feb 88 00:00:23 EST
Date: 02 Feb 88 2059 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Scheme Standardization
To: rrrs-authors@MC.LCS.MIT.EDU
Because I made my suggestion with the intent of providing another
alternative for the Scheme community, I want to argue neither for nor
against it. I wish to clarify 2 factual errors Will made in his message:
1. Individuals belong to X3J13. Companies can belong and send some number
of representatives. All members vote as they wish, but many individuals
vote their company line for whatever reasons, possibly because they have
been told to do so. I vote as I wish, but I won't guarantee that my sense
of greed will not figure into my vote. I don't believe IEEE does things
any differently.
2. I never mentioned any such activity as ``Common Lisp 2000'' or the
``next Common Lisp'' to Will (we talked on the phone for an hour or so). I
mentioned that my own goal was to see the Common Lisp community and the
Scheme community working on the next rendition of Lisp. I explicitly
mentioned that there were few positive lessons from Common Lisp for such a
new language - the key contributions were negative (don't do this, don't
do that). I mentioned as the primary set of positive lessons the
experience that Common Lisp implementors had with programming
environments.
I suppose it might be natural for one who believes that association with
Common Lisp is the ``worst possible thing for Scheme'' to not wish to
associate with people involved with Common Lisp, but I see many of the
Common Lisp folks shaking their heads and wondering how such a weird and
depressing experience as Common Lisp standardization could have been
foisted on them. But, alas, such a dreamer am I to wish for co-operation.
-rpg-
∂03-Feb-88 0445 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA [jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK: Scheme standardization]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 04:45:02 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 07:44:45 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA12353; Tue, 2 Feb 88 09:13:42 EST
Posted-Date: Tue, 2 Feb 88 09:13:00 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA01745; Tue, 2 Feb 88 09:13:00 EST
Date: Tue, 2 Feb 88 09:13:00 EST
Message-Id: <8802021413.AA01745@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK: Scheme standardization]
I ask Julian Padget what he thought about Scheme standardization. I
thought his views would be interesting because of his work with
EuLisp. Here is his response.
John
Posted-Date: Mon, 1 Feb 88 22:23:13 GMT
To: ramsdell <@mbunix.arpa:ramsdell@linus>
Cc: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: ramsdell's message of Mon, 1 Feb 88 15:14:15 EST
Subject: Scheme standardization
Date: Mon, 1 Feb 88 22:23:13 GMT
From: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
I only heard today some rumour about Scheme standardisation (although
it does ring faint bells from something I heard a little while ago).
Who proposed it and what was their motive?
I am not enthusiastic about Scheme being standardised - you might
think that reaction is because it conflicts with the work I get
associated with (i.e. EuLisp). That is not so, although whether there
is room for an ANSI Lisp standard, an ISO Lisp standard and another
ANSI Lisp standard (given that Scheme is a dialect of Lisp), all
conflicting, is highly questionable. It also reflects badly on ANSI's
judgement if it is prepared to condsider this since it would then be
promoting the standardisation of dialects which is contrary to the
notional remit of a standards organisation.
My main reason for not being in favour of standardising Scheme is that
I have learnt a lot about the standards circus in the last few years,
the kind of people that get involved in standardisation and what
(standards) committees do to programming languages. I realise I am
pointing recriminating finger at myself too - in my defence I say that
I did not know what I was getting into...such is the naivete of youth!
Anyway, that would be a sad fate for a language that has been so
carefully thought out and refined (a few minor warts remain).
I presume you mean tail not tale regarding ISO Lisp vs. ANSI Common
Lisp, but I am not sure about the versus part. What has Dick been
saying?
Off to another EuLisp meeting tomorrow, back next Monday (short
holiday too).
--Julian.
∂03-Feb-88 0556 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA "Well, Stanley,here's another nice mess you've gotten us into."
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 05:56:21 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 08:56:07 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA27955; Wed, 3 Feb 88 08:55:30 EST
Posted-Date: Wed, 3 Feb 88 08:54:33 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA02798; Wed, 3 Feb 88 08:54:33 EST
Date: Wed, 3 Feb 88 08:54:33 EST
Message-Id: <8802031354.AA02798@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Sat, 30 Jan 88 09:45:47 est <8801301445.AA04589@zohar>
Subject: "Well, Stanley,here's another nice mess you've gotten us into."
In Hal's message, he suggested a meeting be devoted to the issue of
Scheme standardization. I volunteer to host such a meeting at The
MITRE Corporation. MITRE is located about twenty miles northwest of
Boston and has the facilities to host such a meeting.
John
∂03-Feb-88 0626 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Bizarre Story
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 06:26:07 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 3 Feb 88 09:25:33 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA28796; Wed, 3 Feb 88 09:24:36 EST
Posted-Date: Wed, 3 Feb 88 09:23:40 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA02828; Wed, 3 Feb 88 09:23:40 EST
Date: Wed, 3 Feb 88 09:23:40 EST
Message-Id: <8802031423.AA02828@darwin.sun.uucp>
To: RPG@SAIL.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dick Gabriel's message of 30 Jan 88 1738 PST <8801311332.AA04320@mitre-bedford.ARPA>
Subject: Bizarre Story
Dick writes:
>... The Common Lisp group tried to think of ways of trademarking ``Lisp''
>or ``Common Lisp'' but we are way, way too late.
Can we trademark the name ``Scheme''? I do not think it is too late
for that.
--------------------------
On the subject of confusing Scheme with Common Lisp, I follow the
practice of never mentioning Lisp while talking about Scheme unless
the person I am talking to asks about Scheme's relation to Lisp. This
practice avoids the AI baggage, as well as any negative impressions
the person has of Lisp. Of course, disowning our connection to Lisp
would be like disowning one's parents, but I see no need to tie our
fortunes to Lisp's. Thus I strongly oppose the idea of expanding
X3J13 to cover both Lisp and Scheme. If we choose to standardize
Scheme, let's do it independently of efforts to standardize other
dialects of Lisp.
John
∂03-Feb-88 1238 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu [camp@mips.csc.ti.com: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 12:38:07 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 3 Feb 88 15:36:08 EST
Received: by iuvax.cs.indiana.edu; id AA28733; Wed, 3 Feb 88 15:33:41 EST
Date: Wed, 3 Feb 88 15:33:41 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8802032033.AA28733@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [camp@mips.csc.ti.com: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization ]]
Clyde tried to send this to our notesfile, but it didn't work, so here
it is again.
Date: Tue, 26 Jan 88 16:40:13 CST
From: Clyde Camp <camp@mips.csc.ti.com>
To: chaynes@iuvax.cs.indiana.edu, gls@THINK.COM, jar@mc.lcs.mit.edu,
"hal@mc.lcs.mit.edu.gjs"@mc.lcs.mit.edu,
willc%tekchips.tek.com@RELAY.CS.NET, chaynes@iuvax.cs.indiana.edu,
dfried@iuvax.cs.indiana.edu
Subject: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization ]
I have invited Bob Mathis to get in touch with me, but have not at
this point heard from him. I would like to if someone would send me
his phone number.
The IEEE is recognized by ANSI at the same level as X3. Both are
standards generating entities - in fact, the IEEE is a little more so
in that it can actually adapt standards which are taken by ANSI more
or less as is. X3 cannot adapt standards and the documents it puts
forth to ANSI (through CBEMA) must be put through an additional
consensus gathering and balloting process. I believe that this is
because the IEEE is volunteer and open to anyone while X3 membership
requires that all members pay a service fee and as such it tends to
represent companies/organizations rather than individuals.
If you want Scheme to be associated with Common Lisp and held under
the same umbrella, then X3 makes sense. Otherwise, I believe the IEEE
is a better choice.
All of the IEEE/CS's standards activities were presented to X3's SPARC
committee on January 12. I was there, not Dick nor Bob. There was
interest by several people as to how Scheme and Common Lisp were
related, but absolutely no indication that there was a problem. Since
then there has been no official or unofficial problem. This
presentation to X3 is purely voluntary on the part of the IEEE in
order to identify potential standardization conflicts before things get
as far along as FORTH and PASCAL did. There is, I might add, no
reciprocal presentation by X3 to any IEEE entity.
So far, I'm the highest ranking officer in any of the organizations to
discuss this with you and I've tried to be open about it once I
recognized that everyone wanted to be informed. I would appreciate it
if people sending out non-RRRS-AUTHORS mail on this matter would copy
me so that I can address incorrect information if necessary before it
becomes gospel.
It is unclear to me whether Dick and Bob are speaking for X3J13 or
representing their own opinions. (Not to imply that either is bad, I
just don't know one way or the other.)
To address Dick's itemized list:
1) This is a suprise to me. Yes, they are both lisp and have lots of
closing parentheses but I don't consider them to be indistingishable
at all. Whether or not they belong in two separate organizations is a
separate issue. As I said in my previous message, there is something
to be said for a hierarchical tree of lisp dialects under some
organization. If this is indeed the desire of the RRRS-AUTHORS then
so be it. But I was under the distinct impression that smushing
Scheme in under common-lisp was a highly undesirable thing.
2) ANSI does recognize X3J13 as the technical working group for (a)
Lisp. There is no reason, rule, law, precedent which prohibits the
IEEE from starting up this effort if everyone agrees that it is the
right thing to do. There is also nothing which prohibits ANSI from
recognizing such an activity. X3J13 represents the status quo today,
not for all future time. It certainly does not "..include dialects
such as Scheme" as an absolute de facto state although without
contention that is where things would probably fall.
3) If you want. I would point out that the members & organizations
must pay a fee. X3 members can freely participate in IEEE workshops,
but not vice versa. With respect to speed and "whether anything comes
out" issues, the same applies to the IEEE. The document is ready when
the working group says it is. If the working group thinks that it
should be abandoned, it can be.
4) According to item #2, it's already included?!? In any case, if
Scheme==Common-lisp then I'm wasting my time.
5) The only pressure the RRRS-AUTHORS have seen is pressure to START
the process. This is the very thing I was trying to avoid in the
first place by giving the RRRS-AUTHORS first whack at being the
core of working group, thereby giving them significant control over
what was going on. X3J13 has had no interest in this until now.
6) The same is true with the IEEE as with X3. The ANSI US National
Committee appoints delagates to ISO and IEC. X3 and IEEE are both
represented.
7) Come on now!! I do, obviously, think it would be a mistake, but as
I've said before, if the RRRS-AUTHORS community wants to use X3J13
then that's the way it'll be - neither I nor the IEEE are going to
engage in a "renegade .. effort for standardizing Scheme." My
original goal was to get some standardization effort started and I
felt (and feel) that the IEEE was better suited. But you guys are the
ones doing the work and if you're not happy with that, then by all
means go with X3. In all honesty, I think that the row will be much
tougher to hoe.
But just to clear up things, such a petition to SPARC would NOT
"officially disallow" anything. Given the scenario that X3 and IEEE
both feel that they have legitimate activities in the same area
(meaning that there are blocks of people in both organizations who
adamently feel there is reason to continue), then both organizations
would carry the arguments to the ANSI Information Systems Standards
Board (ISSB) to arbitrate the case if it could be settled in no other
manner. (X3J13 might have to do it through SC22, but I'm not sure.)
This is analogous to two kids arguing over ownership of a toy and
going to daddy to settle it. Depending on the arguments, the
convictions of the organizations, precedent, sizes of working groups
and lots of other factors it could go either way. IEEE's "won" some,
X3's "won" some. In either case, it is often common to have (as in
the case of FORTH and PASCAL) some sort of joint ownership/control.
8) True. But this is happening anyway and any standardization effort
will tend to promote it.
9) Not necessarily true although there is some merit to this. Again,
the question is how closely do you guys want Scheme to be tied to
Common Lisp.
∂03-Feb-88 1537 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 15:36:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 3 Feb 88 18:35:37 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08575; 3 Feb 88 17:11 EST
Received: from csc.ti.com by RELAY.CS.NET id af11483; 3 Feb 88 16:59 EST
Received: from mips by tilde id AA07796; Wed, 3 Feb 88 14:09:59 CST
Received: by mips id AA23921; Wed, 3 Feb 88 14:09:46 CST
Date: Wed, 3 Feb 88 14:09:46 CST
From: David Bartley <bartley%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802032009.AA23921@mips>
To: rrrs-authors@mc.lcs.mit.edu
Cc: Camp%mips.csc.ti.com@RELAY.CS.NET, Bartley%mips.csc.ti.com@RELAY.CS.NET
Subject: Scheme Standardization
I've found the whole subject of standardization of Scheme mildy
distasteful, so I've held off expressing my views until now. As some
of you know, Clyde Camp occupies the office next to mine here at TI.
Clyde and I have had frequent debates in which I argued against any
efforts to formally standardize Scheme. Dick Gabriel's recent posting
advocating X3J13 jurisdiction over Scheme and Will's rebuttal have
finally brought it all into focus for me: Scheme is not Lisp, it
certainly is not Common Lisp, and we must not let the X3J13 or ISO
standardization of "Lisp" threaten our own efforts to make Scheme what
it wants to be.
The fallacy is that all those languages named on the cover of "Common
Lisp: The Language" (CLtL) are merely dialects of a single language,
Lisp, and that Common Lisp is the modern "mainstream" incarnation of
the Lisp language. The truth as I see it is that Lisp 1.5, Scheme,
and Common Lisp are distinct languages in the "Lisp Family" in the
same sense that Algol-60, Pascal, and Ada are distinct languages in
the "Algol Family." X3J13 has as little claim to jurisdiction over
Scheme as the Ada standardizers had over Pascal, Modula, or even PL/1.
Surely the genesis of Scheme and its subsequent evolution at MIT,
Indiana, Yale and elsewhere is as divergent and original within its
cultural context as the origins of Pascal and other "Algol-like"
languages are within theirs.
As a TI representative to X3J13, I'm acutely aware that my obligation
to promote TI's interests may occasionally conflict with my personal
opinions. I've never faced a conflict between the best interests of
Common Lisp and Scheme simply because the sense of X3J13 so far has
been that it is standardizing only Common Lisp, not other Lisp-like
languages. I think this attitude is widely and strongly held. It
would be a mistake to change it.
Whether X3's standardization process is less democratic than the
IEEE's is moot. X3J13 is totally inappropriate for standardizing
Scheme, and, if X3 were to decide that Scheme is covered by the Common
Lisp umbrella, then X3 would be inappropriate.
The remaining proposals are to continue standardizing informally or to
act through IEEE. My sentiments are to keep things informal.
Certainly Will is correct when he says "the definition of Scheme is
already cleaner than the definition of Common Lisp will be when X3J13
finishes with it." Despite sentiment, I'm now inclined to move
quickly to standardize a slightly cleaned up R3RS through IEEE
auspices if that will help bring Scheme out from under the shadow of
Common Lisp (and X3J13).
--db--
∂03-Feb-88 2039 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 20:39:25 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 3 Feb 88 23:25:55 EST
Received: by ZOHAR.AI.MIT.EDU; Wed, 3 Feb 88 23:27:53 est
Date: Wed, 3 Feb 88 23:27:53 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8802040427.AA07660@zohar>
To: bartley%mips.csc.ti.com@RELAY.CS.NET
Cc: rrrs-authors@mc.lcs.mit.edu, Camp%mips.csc.ti.com@RELAY.CS.NET
In-Reply-To: David Bartley's message of Wed, 3 Feb 88 14:09:46 CST <8802032009.AA23921@mips>
Subject: Scheme Standardization
Thank you. I have similar sentiments.
∂04-Feb-88 0649 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA I modify my vote on Scheme standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 06:49:14 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 4 Feb 88 09:48:40 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA08434; Thu, 4 Feb 88 09:47:47 EST
Posted-Date: Thu, 4 Feb 88 09:46:49 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA03808; Thu, 4 Feb 88 09:46:49 EST
Date: Thu, 4 Feb 88 09:46:49 EST
Message-Id: <8802041446.AA03808@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: I modify my vote on Scheme standardization
I have been convinced by recent discussions to modify my vote on
Scheme standardization. Much like David Bartley, and not
enthusiastically, I'm now inclined to move quickly to standardize a
slightly cleaned up R3RS through IEEE because I think it will help
bring Scheme out from under the shadow of Common Lisp (and X3J13).
John
∂04-Feb-88 0736 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 07:36:26 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 4 Feb 88 10:35:38 EST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 4 Feb 88 10:34:16 EST
Received: by kali.think.com; Thu, 4 Feb 88 10:34:13 EST
Date: Thu, 4 Feb 88 10:34:13 EST
From: gls@Think.COM
Message-Id: <8802041534.AA29148@kali.think.com>
To: bartley%mips.csc.ti.com@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu, Camp%mips.csc.ti.com@relay.cs.net,
Bartley%mips.csc.ti.com@relay.cs.net
In-Reply-To: David Bartley's message of Wed, 3 Feb 88 14:09:46 CST <8802032009.AA23921@mips>
Subject: Scheme Standardization
Date: Wed, 3 Feb 88 14:09:46 CST
From: David Bartley <bartley%mips.csc.ti.com@relay.cs.net>
The fallacy is that all those languages named on the cover of "Common
Lisp: The Language" (CLtL) are merely dialects of a single language,
Lisp, and that Common Lisp is the modern "mainstream" incarnation of
the Lisp language. The truth as I see it is that Lisp 1.5, Scheme,
and Common Lisp are distinct languages in the "Lisp Family" in the
same sense that Algol-60, Pascal, and Ada are distinct languages in
the "Algol Family." X3J13 has as little claim to jurisdiction over
Scheme as the Ada standardizers had over Pascal, Modula, or even PL/1.
I have been struggling to express a thought something like this.
I think Bartley has hit the nail on the head. From where I stand,
Pascal and Modula are practically the same language. Proponents of
those languages would deny it vociferously, and I think those who
use Scheme have equal standing in refusing to be lumped with other
Lisp dialects.
--Guy
∂04-Feb-88 1220 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 12:19:58 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 4 Feb 88 15:07:52 EST
Date: 04 Feb 88 1206 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Standardization
To: rrrs-authors@MC.LCS.MIT.EDU
As I've mentioned several times, my proposal was intended as yet
another alternative for the community, with no personal motivation
to see it decided one way or the other.
The only two remarks I have are these:
1.I would have chosen to not standardize Scheme at all, possibly to render
it different from Common Lisp in yet another way. I don't feel that there
is any need to take steps to accomplish unneccessary goals.
2. I am saddened by the animosity I see towards Common Lisp and by
implication towards the Common Lisp community. I made the proposal because
I thought the it might serve as a means of bringing two group together who
would seem to be naturally linked. In fact I have seen people who are my
friends attack me because they thought I was trying to destroy their
community. So, I withdraw my proposal, and I guess I withdraw from the
arena of bringing the Lisp/Scheme communities together.
Enjoy your battle.
-rpg-
∂04-Feb-88 1310 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Little Lisper
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 13:10:39 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Feb 88 16:06:42 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA22724; Thu, 4 Feb 88 12:35:42 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Feb 88 00:14:55 GMT
From: xanth!kahn@AMES.ARC.NASA.GOV (Gary I Kahn)
Organization: Old Dominion University, Norfolk Va.
Subject: Little Lisper
Message-Id: <3884@xanth.cs.odu.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Could someone please mail me the address of MIT Press, or one of its
outlets? I want to buy a copy of The Little LISPer, Trade Edition.
A local bookstore could only give me information about an earlier
(1978? or 1986) version of the book. I need the address from which
to order the book, and the price with any shipping charges. Thanks.
I'm buying either that book or The Scheme Programming Language. I've
already ordered Structure and Interpretation of Computer Programs from
a local bookstore. Thanks in advance for the information.
Gary I. Kahn kahn@odu.edu
∂04-Feb-88 1443 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu more from Clyde Camp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 14:43:47 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 4 Feb 88 17:43:36 EST
Received: by iuvax.cs.indiana.edu; id AA09089; Thu, 4 Feb 88 17:33:37 EST
Date: Thu, 4 Feb 88 17:33:37 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8802042233.AA09089@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: more from Clyde Camp
Not to say too much more, but basically I agree with Hal's
suggestions. The RRRS authors have two proposals before them, one by
me for IEEE sponsorship and one by Dick for X3J13 sponsorship. Either
is possible and there are pros and cons for going in either direction
(or no direction at all). The RRRS authors have a legitimate input to
the direction a Scheme standard takes -- that's why all the netmail --
and their opinions will certainly impact what happens next.
For your reference, my viewpoints are in article numbers 226, 228 and 239
while Dick's are in 234-236.
Regards,
Clyde
∂04-Feb-88 1449 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu from Clyde Camp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 14:48:47 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 4 Feb 88 17:45:41 EST
Received: by iuvax.cs.indiana.edu; id AA26053; Thu, 4 Feb 88 13:52:38 EST
Date: Thu, 4 Feb 88 13:52:38 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8802041852.AA26053@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: from Clyde Camp
Clyde also sent the following a while ago, but it didn't make it. - Chris
--------
I can't help but make the comment that dependence on E-mail to solicit
information obviously restricts inputs to those who have access AND who
actually read RRRS-AUTHORS on a timely basis. That is why I have to
balance RRRS-AUTHORS opinions against the opinions of x-thousand Scheme
users who have purchased a product from one of the three suppliers.
Unfortunately I have no way of accessing those people as a whole and my
sample is relatively small. For that matter, The sample of RRRS-AUTHORS
is relatively small.
The Scheme standard is, at this point, a proposal. There are pros and
cons, but to repeat Chris "..I feel the advantages of a standard clearly
outweigh the disadvantages, at least if we act reasonably soon so that
it does not get out of hand." I hope that I have also made clear my
feeling that the time is right for a standardization effort and that it
should begin early this year.
The existing red-book is pretty much in an acceptable format for a
standard already. Some wordsmithing and formatting may be necessary
(for example, the inclusion of the PAR number and DRAFT at the bottom of
each page) and the bug on page 30 removed but I would say that it is
90+% of the end product already (modulo whatever technical
changes/additions you wish to include). One thing I would strongly
suggest is that the summary be extended to justify Scheme as a
completely different philosophy from Common Lisp to head off trouble in
that direction to begin with - but that's up to you.
In view of the discussions which have been held over RRRS-AUTHORS and by
phone between various parties, let me suggest the following sequence of
events:
1) To continue at least net-mail discussions for the next month or
so and have this topic placed on the agenda for a meeting of the
RRRS group. Preferably this meeting should occur before May and
even more preferably before March. I will be glad to attend if
you so wish.
2) Assuming that the general (not unanimous) concensus is to proceed,
give me a recommendation for a chair and vice-chair as well as a
pair of alternates. At this point Chris and Will have been the
only two who meet the following requirements:
a) Is an IEEE or CS member
b) Believes that standardization is appropriate and who wants to
chair the working group.
c) Is competent technically and managerially
d) His employer also supports the activity and travel necessary
e) The working Group is willing to follow his leadership.
The actual appointment of a chair has not been made at this point
and will not formally be made until after the Project
Authorization Request (PAR) has been approved.
3) Have one or both of the proposed chairs (as well as anyone else
who is interested) prepare a short (<30min) presentation covering
Scheme uniqueness, community, importance, and proposed milestones.
Chris has some rough cuts that are not so rough and are the type
of thing the MSC likes to see.
4) Given that the MSC approves (and I wouldn't be going through this
if I though they would not) an interrum chair would be appointed
until the PAR was approved (which might get done the next week,
but probably would not get done until June due to a mismatch
between the meeting frequencies of the approving committees.)
Finally, let me thank Will Clinger and Chris Haynes for the work they
have already done in pulling all of this together.
Regards, Clyde
=========================
Optional Reading:
The following documentation is available to explain the details of the
standardization process. The chair will get these free from me (I'll be
sending a copy to Chris at least sometime this month).
Phone numbers are where the material can be ordered from if others want
a copy. While the chair must be aware of them, everybody else can
ignore the rest of this unless you're just interested (and it IS
interesting - most of the time)
IEEE Standards Manual (212/705-7091 Mrs. Louise Germani)
IEEE Standards Style Manual "
IEEE Bylaws - January 1987 "
IEEE Policy and Procedures Manual Jan, 1987 "
Computer Society Constitution
(includes the Bylaws and Policy and
Procedures manual) (714-821-8380)
∂04-Feb-88 1709 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 17:09:08 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 4 Feb 88 20:09:01 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa09980; 4 Feb 88 19:25 EST
Received: from csc.ti.com by RELAY.CS.NET id ac19474; 4 Feb 88 19:11 EST
Received: from mips by tilde id AA07292; Thu, 4 Feb 88 16:31:45 CST
Received: by mips id AA02277; Thu, 4 Feb 88 16:31:28 CST
Date: Thu, 4 Feb 88 16:31:28 CST
From: David Bartley <bartley%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802042231.AA02277@mips>
To: RPG@SAIL.STANFORD.EDU
Cc: rrrs-authors@mc.lcs.mit.edu, Bartley%mips.csc.ti.com@RELAY.CS.NET,
Camp%mips.csc.ti.com@RELAY.CS.NET
In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST <8802042108.AA05337@tilde>
Subject: Standardization
> As I've mentioned several times, my proposal was intended as yet
> another alternative for the community, with no personal motivation
> to see it decided one way or the other.
> [...]
> 2. I am saddened by the animosity I see towards Common Lisp and by
> implication towards the Common Lisp community. I made the proposal because
> I thought the it might serve as a means of bringing two group together who
> would seem to be naturally linked. In fact I have seen people who are my
> friends attack me because they thought I was trying to destroy their
> community. So, I withdraw my proposal, and I guess I withdraw from the
> arena of bringing the Lisp/Scheme communities together.
I have no animosity towards Common Lisp or the Common Lisp community
and I did not take your proposal as a threat. Perhaps I expressed
myself badly. I also had a positive message to convey---that Scheme
and Common Lisp have distinct roles to play and we must take care that
they not be conflated. Bringing the two groups together as you
suggest is indeed a natural and healthy linking. I respectfully
differ on whether it is in Scheme's best interests to be standardized
by the group standardizing Common Lisp. I did not anticipate that my
words could be read as an attack (and certainly not a personal
attack)! Please accept my apologies.
I favored your proposal when I first read it. It seemed to offer the
only way for Scheme proponents to participate in the ISO Lisp
standardization. Unlike some of the others on rrrs-authors, I know
that we have many friends of Scheme in X3J13. And your earlier
remarks about the folly (and crime) of excluding people really hit
home. I ended up opposing your proposal only because I concluded that
it wouldn't work out well.
Earlier, you wrote:
I suppose it might be natural for one who believes that
association with Common Lisp is the `worst possible thing for
Scheme' to not wish to associate with people involved with Common
Lisp, ...
I work with both Scheme and Common Lisp as do most of my coworkers
here at TI. I have lead the fight among Scheme implementors to avoid
"gratuitous" conflicts with established CLtL precedent (e.g., the
syntax of numbers). When asked for advice, I've recommended both
languages, depending on the specific needs of an application. I'm
truly in both camps. I see no reason they can't coexist, and I'm
helping to make it happen here. I imagine the same could be said for
Will. And I value my associations with both sets of people.
My experience has been that some users consider Scheme as merely an
alternative Lisp but others understand and appreciate its differences.
My wanting to "help bring Scheme out from under the shadow of Common
Lisp (and X3J13)" is merely that---Scheme and Common Lisp are equally
noteworthy and each deserves its own place in the sun.
> Enjoy your battle.
>
> -rpg-
Please don't give up on us. I appreciate the spirit in which your
proposal was made and I've always considered you one of us.
--db--
∂05-Feb-88 0053 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga, size constraints
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 00:53:48 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 5 Feb 88 03:49:39 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA07718; Fri, 5 Feb 88 00:32:10 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Feb 88 16:33:00 GMT
From: ah4h+@andrew.cmu.edu (Andrew Hudson)
Organization: Carnegie Mellon University
Subject: Re: Scheme for the Amiga, size constraints
Message-Id: <gW2-2wy00jWTMDQ0Gq@andrew.cmu.edu>
References: <518@acf3.NYU.EDU>,
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
>I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an
>easy thing to do. First of all,there is no way CScheme will work on a
>machine with only 0.5M of RAM.I have got it working with 2.5M, but it
>really wants 4M, heavy sigh...
I can hardly believe this! MacScheme ran well on a Mac with only 512k. What
does a Mac have that an Amiga doesn't? This is not a rhetorical question.
Here at CMU I tell people that CommonLisp is a pig for needing 6M and you are
saying 4M would be nice. Has anyone given consideration to a minimally sized
implementation?
- Andrew Hudson
∂05-Feb-88 0743 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU different lisp implementations confused.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 07:43:07 PST
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 Feb 88 10:12:24 EST
Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7)
id AA04013; Fri, 5 Feb 88 10:07:34 EST
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA24604; Fri, 5 Feb 88 10:13:44 est
Date: Fri, 5 Feb 88 10:13:44 est
From: gjc%bucsf.bu.edu@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8802051513.AA24604@bucsf>
To: scheme@mc.lcs.mit.edu
Subject: different lisp implementations confused.
CScheme is written in C and has a large library of code
written in Scheme loaded into it. Having seen the development
in progress I can say that there was not much attention paid
to size or time efficiency.
Macscheme was obviously written with efficiency in mind.
It should not be suprising that one implementation is much
larger or slower than another. (Perhaps I'm wrong, maybe it
should be suprising, since one would not expect to see such
large differences between, say, two FORTRAN implementations.
What is it about lisp that allows for such wide range of
qualities of implementation?)
Even a common-lisp implementation could be relatively small.
KCL, Kyoto Common Lisp, a c-coded implementation, even contains
a compiler and debugger, and checks in at about 1.7 megabytes
on an Encore MultiMax. (This is not a recommendation).
T from Yale checks in at 2.3 Meg on a SUN-III.
Gnu Emacs by comparison is 1.3 Meg on the same machine.
* As is well known to readers of the old LISP-FORUM mailing list,
and also to readers of PLAYBOY FORUM, *size* is not your
best measure of quality.
-gjc
∂05-Feb-88 1249 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu from Clyde Camp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 12:49:11 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Feb 88 15:48:41 EST
Received: by iuvax.cs.indiana.edu; id AA08965; Fri, 5 Feb 88 15:22:39 EST
Date: Fri, 5 Feb 88 15:22:39 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8802052022.AA08965@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: from Clyde Camp
In article <41288@ti-csl.CSNET> Dick Gabriel <RPG@sail.stanford.edu> writes:
>1. Individuals belong to X3J13. Companies can belong and send some number
>of representatives. All members vote as they wish, but many individuals
>vote their company line for whatever reasons, possibly because they have
>been told to do so. I vote as I wish, but I won't guarantee that my sense
>of greed will not figure into my vote. I don't believe IEEE does things
>any differently.
X3's brochures state that:
"Membership on X3 is by organization and is classified into three
groups - Producers, Consumers and General Interest. ... All members
pay a service fee to support the activity. ... Requests for waiver
of the fees are addressed and granted on a case by case basis."
Dick is correct in that individuals, as opposed to companies, make up
X3 committees and that they are free to vote as they please.
Individuals may attend one meeting free to determine whether or not
they want to join. In practice, however, the membership fee often
excludes small companies and individuals who cannot afford to pay it.
The result is that X3 membership is primarily by organization. It is
partially because of this weighting towards larger companies that the
documents from X3 committees must be passed through another balloting
body (representing a wider, more balanced group) before they are
adopted as a standard by ANSI.
With the IEEE, the working committee/group has no membership
restrictions placed on it by the IEEE other than the Chair must be a
member of the IEEE or one of its member societies (such as the
Computer Society). All interested parties may attend and participate
equally in working group meetings.
When the draft standard is declared done by the working group, it is
passed to the sponsor for balloting. The balloting body is made
individuals who are interested and technically competant to review the
document (basically, if you say you are, then you are). Like X3, it
must be balanced between manufacturers, users and general interest
groups. Although only IEEE or society members can actually vote, ALL
negative comments, from member and non-member alike, MUST be resolved
or responded to by the sponsor.
This meets ANSI's balloting rules for "fairness" and is why IEEE
adopted standards are generally taken as-is by ANSI.
- Clyde
∂05-Feb-88 1503 @MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 15:03:39 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 18:03:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa23848; 5 Feb 88 15:02 EST
Received: from northeastern.edu by RELAY.CS.NET id ak02236; 5 Feb 88 14:45 EST
Received: from helios.northeastern.edu by nuhub.acs.northeastern.edu; Fri, 5
Feb 88 07:37 5
Received: from corwin by helios.northeastern.edu id aa08367; 4 Feb 88 21:55 EST
Received: by corwin.ccs.northeastern.edu (5.51/SMI-3.2+CCS-main-2.3) id
AA07467; Thu, 4 Feb 88 21:51:40 EST
Date: Thu, 4 Feb 88 21:51:40 EST
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Subject: Standardization
To: RPG@SAIL.STANFORD.EDU
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id: <8802050251.AA07467@corwin.ccs.northeastern.edu>
In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST
Dear Dick,
I hope you will not choose to withdraw from the "arena of bringing the
Lisp/Scheme communities together." I, for one, found your explanation of the
(Common) Lisp standardization situation extremely enlightening and helpful,
and I am sorry to hear that some people think you are trying to destroy their
community. I did not observe any such sentiments in the recent net traffic.
There is a legitimate concern about the future of the Scheme community, but I
do not believe that this is a response to any perceived threat from the Common
Lisp community or from X3J13, etc. As Scheme matures and its user community
grows, it is no longer controlled by a group of 2 or 5 or 18 or 31. We
(meaning the members of any of these sets) can no longer control or direct the
growth of the language; such direction must be shared with other as yet
unknown persons or institutions which may or may not share the intellectual
goals of the original group.
Consequently there is understandable uncertainty about the the best way to
ensure orderly development of Scheme, that is, one which will preserve its
original intents. This uncertainty was reflected in the discussions of the
June 87 rrrs meeting and in the current interest in standardization.
[There is considerable irony in this analysis. Sussman has said on several
occasions that he was never interested in Scheme as a programming language; he
was just interested in writing some code. I'm not sure about Guy's feelings
on this. Thus most of the "community" in question consists of second and
third generation Schemers, programming-language-people who have long since
wrested control from the original 2!]
I hope we can endorse Bartley's characterization of the relationship between
Common Lisp and Scheme in the family of Lisp-like languages. I think it is
astute both intellectually (being factually close to true) and politically (as
a position to take in the standardization process). I think we have a good
deal to learn from each other, and I hope that the current brouhaha will not
prevent this from happening.
Dick, I thank you for explaining the ISO/X3J13 situation to us and explaining
how Scheme might fit into that scheme. Unfortunately, I find the argument for
participation in X3J13 (or maybe it's X3?) unconvincing: your description of
this looking-glass world seems more apt as an argument to run as fast as
possible in the other direction. I have not yet decided whether the correct
course is to participate in the IEEE standards process or to ignore the
standards process altogether. I hope that we will have some good discussion
on the net on this topic.
--Mitch
∂05-Feb-88 1612 @MC.LCS.MIT.EDU:gls@Think.COM Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 16:11:59 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 Feb 88 19:10:59 EST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 5 Feb 88 19:09:05 EST
Received: by kali.think.com; Fri, 5 Feb 88 19:09:01 EST
Date: Fri, 5 Feb 88 19:09:01 EST
From: gls@Think.COM
Message-Id: <8802060009.AA01135@kali.think.com>
To: wand%corwin.ccs.northeastern.edu@relay.cs.net
Cc: RPG@sail.stanford.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 4 Feb 88 21:51:40 EST <8802050251.AA07467@corwin.ccs.northeastern.edu>
Subject: Standardization
Date: Thu, 4 Feb 88 21:51:40 EST
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@relay.cs.net>
...
[There is considerable irony in this analysis. Sussman has said on several
occasions that he was never interested in Scheme as a programming language; he
was just interested in writing some code. I'm not sure about Guy's feelings
on this. ...]
I'm interested in writing code too. To the extent that it is easy and
convenient for me to use a machine to try out my code, so much the better.
One of the best things about Scheme is that the important parts can be
written down in one page--or carried around in my head. Not having
standard Scheme implementations has not bothered me too much, because
I can turn ANY Lisp into a Scheme with about half an hour of work.
(Usually I am trying out a language design idea by making a toy variant
of Scheme, so I am writing my own evaluator anyway.)
Scheme is small and clean and has a nice semantics.
The kernel of Lisp 1.5 had many of the same properties. Scheme differs
primarily in having better scoping rules, and in general a more carefully
thought out semantics, thanks to many people who have carefully discussed
the issues over the last 1.3 decades.
However, it is also useful to have standard libraries. I am happy to see
lots of useful numerical utilities in a Scheme, for example. It's great to
have ATANH and GCD. I wish factorial and choose (actually the generalized
gamma and beta functions) and Fibonacci were built in also.
I have recently had some experience in trying to write large systems
in Scheme. Where it differs from Common Lisp in fundamental structures
(such as control and binding), it is all to the good. What I miss from
Common Lisp are the little utility routines like STRING-TRIM that I must
reinvent.
Nevertheless, if Scheme is to be standardized I recommend that everyone
on the committee try to refrain from advocating their favorite ten
extra features. Scheme cannot withstand having n people add 10n
new features; the result would be a patchwork, not unlike another Lisp
dialect we all know. Perhaps the committee should agree to adopt a
Rule of One (cf. Lloyd Biggle's "The Still, Small Voice of Trumpets"):
each person gets to choose *one* new feature to propose. That makes
you sit and think carefully.
I have thought about it very carefully, and I choose for my One Feature
to propose that a function like Common Lisp's REDUCE be added (but with
not so many of the keyword-triggered options). I use that a lot.
Perhaps this is too draconian a rule for a committee, but I still suggest
it as a good personal discipline.
--Guy
∂05-Feb-88 1621 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 16:21:00 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 19:15:46 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab25269; 5 Feb 88 16:24 EST
Received: from tektronix.tek.com by RELAY.CS.NET id dt02632; 5 Feb 88 16:11 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA08543; Fri, 5 Feb 88 11:55:51 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA07984; Fri, 5 Feb 88 11:55:07 PST
Date: Fri, 5 Feb 88 11:55:07 PST
From: Norman Adams <adams%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET>
Message-Id: <8802051955.AA07984@tekchips.CRL.TEK.COM>
Subject: Standardization
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: rrrs-authors@mc.lcs.mit.edu
I am confused by your recent messages.
2 Feb 88:
I suppose it might be natural for one who believes that association with
Common Lisp is the ``worst possible thing for Scheme'' to not wish to
associate with people involved with Common Lisp, but I see many of the
Common Lisp folks shaking their heads and wondering how such a weird and
depressing experience as Common Lisp standardization could have been
foisted on them. But, alas, such a dreamer am I to wish for co-operation.
Will said that having a stardards organization for Scheme be part of X3J13
would be the worst possible thing for Scheme. Others have said they would
like to avoid Scheme and Common Lisp being closely associated. As I read
the above, you seem to say that advocating a clearly distinguished
standards effort for Scheme --as Will has advocated-- is uncooperative.
Why? You yourself characterize Common Lisp standardization (as embodied by
X3J13) as "a weird and depressing experience." So let the Scheme efforts
walk clear of that tar pit.
4 Feb 88:
2. I am saddened by the animosity I see towards Common Lisp and by
implication towards the Common Lisp community. I made the proposal because
I thought the it might serve as a means of bringing two group together who
would seem to be naturally linked.
A preference by the Scheme community to have the Scheme language clearly
distinguished from the Common Lisp language does not imply that the Scheme
community sees no value in Common Lisp. You say a distaste for Common Lisp
implies a distaste for the Common Lisp community. I do not understand the
basis for this implication.
...In fact I have seen people who are my
friends attack me because they thought I was trying to destroy their
community. So, I withdraw my proposal,
There must be something going on behind the scenes. I cannot understand
this in the context of what I have seen on the mailing list.
...and I guess I withdraw from the
arena of bringing the Lisp/Scheme communities together.
Enjoy your battle.
And now I am completely lost. Does the mutual influence of the Common Lisp
and Scheme communities hinge on some ANSI-contained relationship? I think
not. The Lisp and Scheme communities already interact on technical issues.
(Will I see you at the Lisp Conference?) More interaction is possible. I
would think that an X3J13 subcommittee (or whatever) on Scheme would
increase political interaction, while doing little for technical
interaction. And what battle? (I am still lost.)
4. We can also broaden the charter of X3J13 to specifically include
Scheme. A committee or subcommittee on Scheme could be established
with its own time schedule.
This would accomplish several things for you:
...
6. You would have a voice and standing within any ISO process concerning
Lisp in which you were interested.
7. Any renegade IEEE efforts towards standardizing Scheme would be
officially disallowed through a petition from SPARC to IEEE.
and in a later message
Many observers (Mathis and myself included) believe that if ANSI is
asked to recognize Scheme as a different language from Common Lisp, they
will not do so, but ask that X3J13 broaden its charter.
Certainly you did not intend make threats, but it seems to me a threat is
implied: "Play the X3J13 game or you can't participate in ISO Lisp; if ISO
asks X3J13 about Scheme, X3J13 will incorporate Scheme with or without the
Scheme community."
I find it strange that the committee that wrote "Common Lisp" into their
charter so as "not to hamper the Scheme efforts" would then broaden its
charter to include Scheme. From what I understand, ANSI could choose to
include an IEEE effort in ISO level activities if appropriate. Clyde Camp
says such cooperation is possible. Will also makes this point. Are
we naive to believe that cooperation between ANSI and IEEE is possible?
I have moved from being slightly against any formal standards effort
to slightly in favor of an effort organized under IEEE.
-Norman
-------
∂05-Feb-88 1912 @MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com Critical summary
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 19:12:09 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Feb 88 22:11:53 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa28007; 5 Feb 88 19:40 EST
Received: from csc.ti.com by RELAY.CS.NET id ap05375; 5 Feb 88 19:35 EST
Received: from mips by tilde id AA05055; Fri, 5 Feb 88 18:06:14 CST
Received: by mips id AA14165; Fri, 5 Feb 88 18:06:09 CST
Date: Fri, 5 Feb 88 18:06:09 CST
From: Clyde Camp <camp%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802060006.AA14165@mips>
To: ramsdell%linus@MITRE-BEDFORD.ARPA, rrrs-authors@mc.lcs.mit.edu
Cc: Camp%mips.csc.ti.com@RELAY.CS.NET
In-Reply-To: ramsdell%linus@mitre-bedford.arpa's message of Fri, 5 Feb 88 07:53:53 EST <8802051253.AA05013@darwin.sun.uucp>
Subject: Critical summary
Several people have pointed out that the message numbers I referred to
a while back don't mean anything. Sorry about that. I idiotically
assumed the whole network used the same numbering scheme. To
complicate matters, not everything of mine is getting through
(probably due to pilot error).
The messages I was referring to were as follows:
Two initial major ones from me:
"It is easier to kill a thing....." - a history
"I can't help but...." - a proposal
From Dick Gabriel:
"Gentlemen. I have talked with Bob..." - an alternate proposal
"My wording on this point.... " - an elaboration and history
From me:
"This is being belatedly posted ... " - a response to Dick's
message
If you have not received them I'll resend.
Clyde
∂06-Feb-88 1715 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU Can we standardize Scheme without killing it?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 88 17:15:09 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Feb 88 20:14:02 EST
Date: Sat, 6 Feb 88 20:13:34 EST
From: Hal Abelson <HAL@AI.AI.MIT.EDU>
Subject: Can we standardize Scheme without killing it?
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <322467.880206.HAL@AI.AI.MIT.EDU>
Like David Bartley and Norman Adams, I've decided to unenthusiatically
support standardizing Scheme through IEEE -- provided we can do it
with proper precautions (see below).
The reason is not so much to "get Scheme out from under the shadow of
Common Lisp", as someone (I forget who) wrote to this list. Rather, I
expect that as Scheme becomes more widely used, there will be
increasing pressure to standardize it. And I am sure that as time
goes on, it will be increasingly difficult to standardize it in "the
right spirit." Already, at our preevious R*S meeting, Scheme design
had become too much of a political process rather than a technical
one. People had begun to see themselves not as individual language
designers, but as representatives of various constituencies of Scheme
users. This can only get worse as time goes on. So let's face the
issue now. My fear is that it is already too late to avoid the politics.
I want to make a couple of suggestions
1) We meet very soon to decide whether we want to go ahead with
standardization, and if so, to figure out how to go about this. I
think that this meeting should not talk about technical issues.
2) However the politics goes, the technical content of the first
Scheme standard should be what we have already agreed upon in R*S with
the possible exception of correcting obvious blunders. I appreciate
Guy Steele's sentiment that we pass a rule saying that each person can
nominate at most one feature to be included. But I think that this is
one feature too many. (Guy's suggested REDUCE, which I think is a
wonderful thing, can be put in the Yellow Pages.) In general I would
like to see a VERY conservative and VERY minimal standard.
3) My biggest worry about standardizing Scheme is my belief that
language design ought to be an evolutionary process guided by those
people with the best ideas at the moment, as worked out in research
papers and in implementations. It should not be a political process
in which things are done by some offical set of empowered
representatives (whether empowered by ANSII, ISO, IEEE, God, or
whomever). That sort of approach stultifies research by making people
feel as if they need to go to some "official body" to get their ideas
seriously considered.
I am currently refereeing papers submitted to the 1988 Lisp and
Functional Programming Conference. If I simply count what Lisp
dialects people are writing about, then in 150 papers I have seen so
far, there are as many papers specifically about Scheme as there are
about Common Lisp. If I ignore papers of the form "I have implemented
a neat program in Lisp" and restrict to papers that are proposing
serious language extensions or investigations of semantics, then there
are about a dozen of these about Scheme and only two or three about
Common Lisp. I assume that some of this is because Scheme is a
cleaner language than Common Lisp. But I can't help thinking that
another reason is that any serious researcher would think it a waste
of time to work on an extension to Common Lisp unless he is one of the
"duly constituted representiatives" of the Common Lisp Community.
To put it another way, standardizing something is a good way to shut
off research in it. To my mind, much of the reason that Lisp is still
around after 30 years is that it never was standardized and so was
able to evolve in an informal way.
I think that Common Lisp is well on its way to being a dead language,
and I don't want the same thing to happen to Scheme. But it's going
to be hard to resist. Whatever group gets the power to make Scheme
"official" is going to be tempted to "satisfy the needs of all those
Scheme users out in the world" by making the standard more and more
complete and by arrogating more and more of the design process to
themselves. And they will do this with the best possible motives.
For example, I am very impressed with the work of Bobrow, Kiczales,
Gabriel, etc. in designing CLOS. But I think it is wrong for them to
do this under the auspices of X3. One result is that the ONLY paper I
have seen so far about objects in Common Lisp submitted to the L&FP
conference this year is by members of the CLOS subcommittee.
So I think we need to give some serious thought to setting up a Scheme
standardization process that will be immune to this kind of
temptation. For example, we might decide that extensions to the
Scheme standard will be adopted only in conjuction with some academic
conference (such as L&FP) and only after "the research community" is
satisifed that the issues have been fully explored and that some
concensus (NOT a vote) has been attained. I would like to hear
suggestions from Clyde Camp on whether such a thing would be
compatible with IEEE (or ANSII or ISO) standards policies.
In addition, I would like us to include specific language in the
Scheme standard that puts the standardization effort in this light.
Here are some suggested paragraphs. I am happy to have someone else
edit them and make changes, but I do want to include some such words
near the beginning of the report:
--------------------------------------------------
SUGGESTED PARAGRAPH FOR SCHEME STANDARD
Throughout its thirty-year life, Lisp has continually adapted to
encompass changing ideas about programming-language design.
Specifying a standard for Scheme is intended to encourage the
continued evolution of Lisp dialects by identifying a coherent set of
constructs that is large enough to support the implementation of
substantial Lisp programs, but also small enough to admit significant
extensions and alternate approaches to language design. For example,
the standard does not mandate the inclusion in Scheme of large run-time
libraries, particular user interfaces, or complex interactions with
external operating systems, although practical Scheme implementations
ordinarily provide such features.
In particular, there are important linguistic design issues that are
not discussed in the Scheme standard {\em precisely because} Scheme
has sparked fruitful new approaches in these areas, and the authors of
this report do not wish to discourage the further development of good
ideas by taking a position on issues under active investigation. Some
of these issues are:
Macros: The scope of identifiers in macros has traditionally been
problematic for Lisp. Scheme's adoption of lexical scoping and a
single namespace for identifiers has stimulated the development of
macro-expansion techniquies that are more elegant and robust than
those appearing in other Lisp dialects. Although this report does not
specify a macro-definition facility, most popular Scheme
implementations allow users to define macros. The research literature
[ references ....] contains numerous discussions of macro definition
in Scheme.
Packaging: Scheme's uniform naming conventions permit ordinary lexical
environments (in some Scheme implementations) or slight modifications
of these (in other implementations) to provide poerful support for
programming-in-the-large. This obviates the need for special-purpose
naming mechanisms (such as multiple obarrays) as adopted by other Lisp
dialects. References [.......] provide discussions of techniques for
packaging and module definition in Scheme.
Object-oriented programming: Scheme unadorned is nearly an
object-oriented language. [JAR and Adams: I hope you don't object to
my snarfing the first sentence of your paper. It's a wonderful
sentence.] With simple extensions (or even simple syntactic
conventions) Scheme becomes a powerful foundation for implementing a
panoply of object systems, with little of the conceptual baggage
adopted by other Lisp dialects. See [refs .......] for examples.
[feel free to add more examples of Scheme's wonderfulness and your
current research: parallelism, continuations, logic variables, type
inferencing, ...]
The authors of this report hope that future revisions of the Scheme
standard will be sensitive to the fact that good ideas need time to
mature, and that exploration can often be stifled by the premature
adoption of standards.
--------------------------------------------------
-- Hal
∂06-Feb-88 1957 @MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU Re: Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 88 19:57:33 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 6 Feb 88 22:55:40 EST
Date: Sat 6 Feb 88 19:49:54-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Standardization
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12372714364.17.ANDY@Sushi.Stanford.EDU>
I don't understand most of the responses to RPG's proposal. This may
be due to my lack of experience in standards activities or my
ignorance of IEEE/ISO/ANSI/X3/X3J13 politics. (BTW - what are the
latter two short for?) RPG mentioned a number of political problems
in the CL standardization process. Most of the messages that mention
these problems suggest that Clyde Camp's proposal avoids them but that
isn't obvious to me. RPG is offering whatever structural help the CL
standardizers can offer - under Camp's proposal, the Scheme community
has to do everything itself. In RPG's proposal, unlike Camp's, the
Scheme community doesn't have to fight the battles that the CL
standardizers have already won. What specific things does IEEE offer
that are less likely under RPG's proposal? Doesn't Camp's proposed
Scheme standardization have to jump through hoops that RPG's puts us
beyond?
I believe the "Scheme is a Lisp" dogma and that Common Lisp is also a
Lisp; I expect the next Lisp to appear soon (although it may not be
recognized for a 10-15 years). I want to provide substantial
cross-fertilization among the members of the Lisp family (although I
expect CL to provide most of the negative lessons) without sacrificing
the autonomy that they need. (What little I've heard from the logic
programming community suggests that they are taking this approach,
unlike the proponents of yet-another-algebraic-language.) Therefore,
I'd like to see a standardization structure that reflects that
relationship (I'll explain why I think it is now time to standardize
Scheme in a couple of paragraphs). In other words, I'd like to see
something along the lines of:
Lisp
/ | \
CL Scheme Future Lisps
Neither Camp's IEEE nor RPG's X3J13 sub-committee proposal match that
structure but I think that RPG's is easier to "subvert". I may be
naive, but if the CL people want this structure, it should be easier
to promote a sub-committee than it is to bring in an outside group.
Can we arrange for this to happen at the same time the initial Scheme
standard is approved? If we can't, RPG's proposal is obviously
inferior; if we can, that's a big point in its favor.
Why I think Scheme Standardization is Good:
A few weeks ago, John Ramsdell said that the current R↑nRS language
was not a good candidate for standardization because it was missing
eval, objects, macros, support for programming in the large, and
parallelism; others mentioned logic variables and type inferenceing.
I agree with something implied by Chris Haynes; he said that a
standard was an agreement on what was stable. I think we can push
this a bit further and use standardization as a framework for managing
the medium-term development of Scheme.
Note that I am not saying that the standardization process should
design Scheme; Kent Pitman among others is absolutely right when he
says that "the organizational structure of a standards committee is
not appropriate for design work." I would like to see the first round
of Scheme standardization result in the red book as a trial standard
and an agreement that the revision two years later would incorporate
eval and objects and possibly macros. If macros are ready by then,
then that standard could be a full standard to be followed in 5 years
by a revision than incorporated some support for programming in the
large and logic variables. If macros aren't ready in two years, then
there could be another interim standard until they are. Something
similar can be done for libraries. In each case, I expect to see
competing proposals based on experience.
In other words, I'd like to see a Scheme standard that is not only an
agreement on what is and what direction we're going but one that also
schedules revisions of both. I think that CL would have been better
now if they'd have started 10 years earlier and gone through the loop
a few more times with a similar plan.
One of the beneficial side effects of a planned series of standards is
that eventually Scheme development ends; it schedules the death of
Scheme. Either Scheme-2010 is the one true lisp used by all (except
for the fortran heretics) or, as I expect, we'll have something nice
to use while epitome is developed using the scheme experience.
If I'm completely confused, I'd appreciate E-mail; there's no need to
post what everyone else knows.
-andy
-------
∂06-Feb-88 2255 @MC.LCS.MIT.EDU:gls@Think.COM Can we standardize Scheme without killing it?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 88 22:55:27 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 7 Feb 88 00:56:06 EST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Sun, 7 Feb 88 00:55:18 EST
Received: by kali.think.com; Sun, 7 Feb 88 00:55:15 EST
Date: Sun, 7 Feb 88 00:55:15 EST
From: gls@Think.COM
Message-Id: <8802070555.AA03061@kali.think.com>
To: HAL@ai.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU>
Subject: Can we standardize Scheme without killing it?
2) However the politics goes, the technical content of the first
Scheme standard should be what we have already agreed upon in R*S with
the possible exception of correcting obvious blunders. I appreciate
Guy Steele's sentiment that we pass a rule saying that each person can
nominate at most one feature to be included. But I think that this is
one feature too many. (Guy's suggested REDUCE, which I think is a
wonderful thing, can be put in the Yellow Pages.) In general I would
like to see a VERY conservative and VERY minimal standard.
Hal's point is very well taken here, and I humbly retreat even further.
After distilling Hal's suggested introductory paragraphs, however, I find
that perhaps what many of want is not so much a standard programming
language, but a standard framework within which to investigate a family of
programming languages. I know we can standardize a programming language
within IEEE or X3, but can we properly standardize a philosophy?
I think that latter goal has already been served by the publication of
R↑3S. Had it not already appeared in SIGPLAN Notices, it might have been
a candidate for the Lisp Conference. Compare this to the appearance of
Milner's "A Proposal for Standard ML" in the 1984 Lisp Conference.
I agree with Hal that better ideas for language design come out of the
academic arena than out of standards committees--even when it is the same
people involved--because the processes are very different.
People continue to ask me (or tell me) whether X3J13 is really needed or
whether the mere publication of CLtL was sufficient. My reaction is
almost invariably "You're asking ME??"
I like Scheme. Scheme is nice. Scheme makes me happy. I want everyone
else to be happy too. Am I a sap?
--Guy
∂07-Feb-88 0849 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU can we properly standardize a philosophy?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 08:49:02 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 11:47:48 EST
Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 11:50:42 est
Date: Sun, 7 Feb 88 11:50:42 est
From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802071650.AA09808@zohar>
To: rrrs-authors@mc
Subject: can we properly standardize a philosophy?
Reply-To: hal@ai.ai.mit.edu
Guy's comment:
After distilling Hal's suggested introductory paragraphs,
however, I find that perhaps what many of want is not so
much a standard programming language, but a standard
framework within which to investigate a family of
programming languages. I know we can standardize a
programming language within IEEE or X3, but can we properly
standardize a philosophy? I think that latter goal has
already been served by the publication of R↑3S.
puts the issue very well. When the question of Scheme standardization was
first raised my opinion was that Scheme was already standardized in R*S and
that anything more "official" would be neither necessary nor desirable.
But serious concerns have been raised about (1) some other group
standardizing something called "Scheme" (2) Scheme getting overshadowed by
Common Lisp (3) Scheme not being viewed as a "real language". So I think
it is worthwhile to see if we can go the standards route without blowing
it.
"Blowing it" means setting up a situation where people feel that they
have to agree about large chunks of Scheme before they can work on
Scheme. That turns Scheme design into a political process rather than
an intellectual one. It also, unfortunately, is often the express
purpose of creating a standard.
I do think, however, that if we are careful, we could have our cake and it
too:
(1) We could satisfy the demands for standardization and the procedural
requirements of a standards organization by "standardizing" a small kernel.
Luckily, we have already adopted the idea of a spectrum ranging from
essential features to yellow pages, which makes this possible.
(2) We could satisfy ourselves that we are not overly politicizing
Scheme development by including appropriate philosophical statements
in the report, and by identifiying a process for evolving the standard
that will guard against this.
I am not at all secure that we can manage (2), which is why I think we
need to meet to discuss this, and to continue discussions on this
mailing list. In particular, we need to hear from Clyde Camp on
behalf of IEEE and from people familiar with X3 (by the way, what is
X3 ?) about whether such an approach would be compatible with the
frameworks of the various standards organizations.
-- Hal
∂07-Feb-88 0940 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu Minimal Standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 09:40:51 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 7 Feb 88 12:39:54 EST
Received: by iuvax.cs.indiana.edu; id AA10507; Sun, 7 Feb 88 12:38:22 EST
Date: Sun, 7 Feb 88 12:38:22 EST
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Message-Id: <8802071738.AA10507@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Minimal Standard
In conversations with Chris Haynes I have expressed my opinion that
if there is to be a standardization of Scheme it ought to be under
the auspices of the people who have Scheme's best interests at heart.
From my current perspective it appears that IEEE is our best hope.
Language design for human users is a constantly evolving process.
So it should be clear that at the outset only the smallest acceptable
subset of R↑n should be standardized.
--- Dan
∂07-Feb-88 0951 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu A vote for a minimal standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 09:51:42 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 7 Feb 88 12:49:48 EST
Received: by iuvax.cs.indiana.edu; id AA10771; Sun, 7 Feb 88 12:48:15 EST
Date: Sun, 7 Feb 88 12:48:15 EST
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Message-Id: <8802071748.AA10771@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: A vote for a minimal standard
In conversations with Chris Haynes I have expressed my opinion that
if there is to be a standardization of Scheme it ought to be under
the auspices of the people who have Scheme's best interests at heart.
From my current perspective it appears that IEEE is our best hope.
Language design for human users is a constantly evolving process,
so it should be clear that at the outset only the smallest acceptable
subset of R↑n should be standardized.
--- Dan
∂07-Feb-88 1554 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Yale T (compiling)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 15:54:08 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 7 Feb 88 18:49:58 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA14963; Sun, 7 Feb 88 15:44:53 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Feb 88 22:44:56 GMT
From: murthy@cu-arpa.cs.cornell.edu (Chet Murthy)
Organization: Cornell Univ. CS Dept. Ithaca NY
Subject: Yale T (compiling)
Message-Id: <13258@cornell.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I just ftp-ed a copy of Yale T from prep.ai.mit.edu, and
I can't figure out how on Earth to recompile it.
I would really like ot be able to build one from scratch, just so
I know that it really works (or at least, that there are no hidden
nulled out sections of the executable or anything). Does anybody
out there know how to do this?
I couldn't find build instructions anywhere.
--chet--
In Real Life: Chet Murthy
ARPA: murthy@svax.cs.cornell.edu
SnailMail: Chet Murthy
North Woods Apts #20-2A
700 Warren Road
Ithaca, NY 14850
Office: 4162 Upson (607) 255-2219
MaBellNet: (607)-257-2542
∂07-Feb-88 1839 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 18:39:02 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 21:37:47 EST
Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 21:40:18 est
Date: Sun, 7 Feb 88 21:40:18 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8802080240.AA10087@zohar>
To: gls@Think.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 5 Feb 88 19:09:01 EST <8802060009.AA01135@kali.think.com>
Subject: Standardization
Thank you GLS. As usual, we agree on lots of things. In particular,
the most wonderful part of R↑3RS is that it is less than 50 pages.
Let's keep R↑4RS that small!
By the way, the only features I would propose to add to "official"
Scheme are REDUCE and some kind of EVAL (note how it seems to be
almost EVIL in these prudish times), such as our ENCLOSE (which I
would now call LAMBDA->PROCEDURE) so that I can run code that I
construct on the fly.
Thus I think we have used up our quota.
∂07-Feb-88 1855 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Can we standardize Scheme without killing it?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 18:54:50 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 7 Feb 88 21:53:28 EST
Received: by ZOHAR.AI.MIT.EDU; Sun, 7 Feb 88 21:56:08 est
Date: Sun, 7 Feb 88 21:56:08 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8802080256.AA10107@zohar>
To: HAL@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU>
Subject: Can we standardize Scheme without killing it?
Modified rapture!
∂08-Feb-88 0637 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Scheme number notation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 06:37:02 PST
Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 8 Feb 88 09:35:53 EST
Date: 8 Feb 1988 09:35-EST
Sender: SUSSMAN@G.BBN.COM
Subject: Scheme number notation
From: SUSSMAN@G.BBN.COM
To: gjs@MC.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Cc: allen@SOCRATES.BBN.COM, quigley@SOCRATES.BBN.COM
Cc: sas@BFLY-VAX.BBN.COM, las@BFLY-VAX.BBN.COM
Cc: sussman@G.BBN.COM, amellor@BFLY-VAX.BBN.COM
Cc: ajc@BFLY-VAX.BBN.COM
Message-ID: <[G.BBN.COM] 8-Feb-88 09:35:01.SUSSMAN>
R3RS doesn't say what the meaning of E notation (for the exponent) is.
In MIT C/Scheme, apparently <stuff>e<exp> means <stuff>*10↑<exp>
regardless of the base. E.g. #b1e2 is 100 decimal, not 100 binary.
Worse yet, though the lexical grammar allows E<exp> with any base, it
can't work with hex, since E is a hex digit. Hence,
#b1E2 = #o1E2 = 1E2 = 100
but #x1E2 = 482
Julie
∂08-Feb-88 0649 @MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM Wording to fix for LETREC
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 06:49:04 PST
Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 8 Feb 88 09:46:56 EST
Date: 8 Feb 1988 09:46-EST
Sender: SUSSMAN@G.BBN.COM
Subject: Wording to fix for LETREC
From: SUSSMAN@G.BBN.COM
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: sussman@G.BBN.COM, quigley@SOCRATES.BBN.COM
Message-ID: <[G.BBN.COM] 8-Feb-88 09:46:03.SUSSMAN>
In 4.2.2 "Binding constructs" you need to add the word ALL as follows:
"...in a letrec expression, ALL the bindings are in effect while their
initial values are being computed..."
Otherwise it could mean that each binding is in effect while its
own initial value is being computed.
Julie
∂08-Feb-88 1449 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU !
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 14:49:06 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Feb 88 17:44:52 EST
Date: Mon, 8 Feb 88 17:44:38 EST
From: Alan@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
Subject: !
To: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU
Message-ID: <323426.880208.JAR@AI.AI.MIT.EDU>
(define (make-cell)
(call-with-current-continuation
(lambda (return-from-make-cell)
(letrec ((state
(call-with-current-continuation
(lambda (return-new-state)
(return-from-make-cell
(lambda (op)
(case op
((set)
(lambda (value)
(call-with-current-continuation
(lambda (return-from-access)
(return-new-state
(list value return-from-access))))))
((get) (car state)))))))))
((cadr state) 'done)))))
∂08-Feb-88 1552 @MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU Scheme number notation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 15:52:26 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 88 17:48:18 EST
Received: from MICKEY-MOUSE.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Feb 88 17:47-EST
Date: Mon, 8 Feb 88 17:47 EST
From: Mark A. Sheldon <DEATH@XX.LCS.MIT.EDU>
Subject: Scheme number notation
To: SUSSMAN@G.BBN.COM, gjs@MC.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <[G.BBN.COM] 8-Feb-88 09:35:01.SUSSMAN>
Message-ID: <880208174738.0.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>
R3RS doesn't say what the meaning of E notation (for the exponent) is.
In MIT C/Scheme, apparently <stuff>e<exp> means <stuff>*10↑<exp>
regardless of the base. E.g. #b1e2 is 100 decimal, not 100 binary.
You're right that R3RS leaves the notation for exponents underspecified. I
discovered this when I used some of the MIT Scheme number-parser code to
write my own reader. My reader now uses the radix specified in the prefix
(if any) as the radix for reading the exponent. Thus #b1e2 is 100 binary.
Worse yet, though the lexical grammar allows E<exp> with any base, it
can't work with hex, since E is a hex digit. Hence,
#b1E2 = #o1E2 = 1E2 = 100
but #x1E2 = 482
I also ran into the problem with E in hex: without thinking about it, I
formulated the test case 1.1E-2 and got reader errors (obviously). Since E
notation is really just a hold-over from FORTRAN, why not use ↑ instead?
It would look nicer and wouldn't conflict with any reasonable radix.
Another problem in implementing a reader in Scheme is that R3RS also
underspecifies the relationships among the return values of CHAR->INTEGER.
There is no guarantee that the numeric characters are together in the
character code. My reader (and the MIT Scheme reader) relies on this
anyway.
-Mark
∂08-Feb-88 1619 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com A Minimalist Standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:19:14 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Feb 88 18:55:59 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab28354; 8 Feb 88 18:38 EST
Received: from csc.ti.com by RELAY.CS.NET id ae24504; 8 Feb 88 18:34 EST
Received: from home by tilde id AA02672; Mon, 8 Feb 88 15:45:32 CST
Received: by home id AA03731; Mon, 8 Feb 88 15:43:39 CST
Date: Mon, 8 Feb 88 15:43:39 CST
From: Don Oxley <oxley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802082143.AA03731@home>
To: rrrs-authors@mc.lcs.mit.edu
Subject: A Minimalist Standard
I heartily concur with Hal's philosophy on the standard. Leaving
unsettled issues out of the standard and allowing good research to
take place is crucial. However, I have a concern.
If Scheme is to be a vehicle for research and experimentation, then I
forsee little problem, but as Scheme becomes more of a development
language for delivering other applications (eg., TI's Personal
Consultant), then there will be considerable pressure to "standardize"
the non-standard parts of the language. For example, many of us at TI
have succumbed to the use of multiple values as part of our Scheme
language - not to investigate multiple values but to use it in larger
efforts.
I don't have a solution to this problem, but I think that something
more than a minimalist approach will become necessary. The language
must be "sufficient" for significant development as perceived by the
users. Possibly we can address this with the R*S "optional" or
"extensions" parts of the language which commit definitions for
features which are not part of the standard. We might even adopt a
standard prefix (eg., #!@?) to avoid preempting names from a future
standard.
In any case, I think we should consider trying to develop an approach
to recognizing and allowing "registered" extensions which could help
in portability and future automated correction when a real standard is
developed. This could also be used to allieviate some of the pressure
to standardize a feature too early.
Comments??
--Don
∂08-Feb-88 1652 @MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU Scheme number notation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:52:03 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Feb 88 19:44:21 EST
Received: from MICKEY-MOUSE.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Feb 88 19:39-EST
Date: Mon, 8 Feb 88 19:40 EST
From: Mark A. Sheldon <DEATH@XX.LCS.MIT.EDU>
Subject: Scheme number notation
To: DEATH@XX.LCS.MIT.EDU, SUSSMAN@G.BBN.COM, gjs@MC.LCS.MIT.EDU,
JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <880208174738.0.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>
Message-ID: <880208194000.2.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>
Oops! I have to take back my complaint that R3RS underspecifies the
interrelationships among values returned by CHAR->INTEGER for numeric
characters. JAR pointed out to me that you can just compute a table in
which to look up the values (indexed by the CHAR->INTEGER result). It
wastes some space, but so what. Now my reader is completely (?) portable
under R3RS.
-Mark
∂08-Feb-88 1659 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com Scheme Standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 16:59:17 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 8 Feb 88 19:47:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa26766; 8 Feb 88 16:58 EST
Received: from csc.ti.com by RELAY.CS.NET id as23929; 8 Feb 88 16:50 EST
Received: from home by tilde id AA02132; Mon, 8 Feb 88 15:22:13 CST
Received: by home id AA03169; Mon, 8 Feb 88 15:20:29 CST
Date: Mon, 8 Feb 88 15:20:29 CST
From: Don Oxley <oxley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802082120.AA03169@home>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Scheme Standardization
[This is a little late - I sent it a week ago and went out of town -
when I returned I found that my message had also]
After reading rpg's arguments in support of working with the ANSI
effort, I wonder if it is really possible to allow a sub-committee to
sit as idly to the side as he suggests (I don't really purport to
know). If ISO is interested in Scheme and is active, would the US
effort not be compelled to join the fray. It seems a bit
disconcerting to me to sit in the midst of a swamp full of alligators
when my initial goal was a family picnic!
It seems to me that whether we work with the IEEE or ANSI, Scheme can
remain a reasonable language if the major implementors/researchers
continue to work together and will otherwise be abandoned. If alien
forces were to take control of an IEEE or ANSI effort and
significantly harm Scheme or make the process intolerable, I would
imagine that most researchers would ignore it and a new direction
would occur. This would indeed be unfortunate, but the most likely
result would be that the current implementations would define a dying
"standard" until a new language evolved.
If the current implementors continue working together, with or without
the support of a standards group, I think that we will continue to
develop a language which will gain substantial use.
It seems to me that participation in one of the standards efforts
*may* provide a vehicle to encourage more acceptance of Scheme and the
development of a broader community (which we need). If we keep a goal
of accepting only widely supported additions, then we ought to be able
to manage an evolution from the R3RS (maybe even R3RS itself).
Its not clear to me which is better, somehow it seems that the IEEE
may have the less burdensome process. Could the ANSI committee be
"formed" and sit idle as a placeholder and then maybe adopt/endorse a
successful effort through the IEEE?
I would vote to attempt a standardization effort - if only to
encourage discussion and dissemination of the concepts. If it becomes
too unwieldly, then just abandon it - there is no sense in
standardizing a competitor to Common Lisp that has nothing new to
offer - that would be damaging to the entire Lisp community. If
Scheme is to become a widely used language, it must be something we
are still proud of - otherwise it should remain a minor research tool.
--Don
∂08-Feb-88 1840 @MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU !
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 18:40:42 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Feb 88 17:44:52 EST
Date: Mon, 8 Feb 88 17:44:38 EST
From: Alan@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
Subject: !
To: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU
Message-ID: <323426.880208.JAR@AI.AI.MIT.EDU>
(define (make-cell)
(call-with-current-continuation
(lambda (return-from-make-cell)
(letrec ((state
(call-with-current-continuation
(lambda (return-new-state)
(return-from-make-cell
(lambda (op)
(case op
((set)
(lambda (value)
(call-with-current-continuation
(lambda (return-from-access)
(return-new-state
(list value return-from-access))))))
((get) (car state)))))))))
((cadr state) 'done)))))
∂08-Feb-88 2203 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU !
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 22:03:25 PST
Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 9 Feb 88 00:18:53 EST
Received: from RAVEN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 8 Feb 88 23:24:29 est
Received: by RAVEN.LCS.MIT.EDU (4.12/4.7); Mon, 8 Feb 88 21:51:32 est
Date: Mon, 8 Feb 88 21:51:32 est
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
Message-Id: <8802090251.AA01964@RAVEN.LCS.MIT.EDU>
To: Alan@AI.AI.MIT.EDU
Cc: PSRG@CLS.LCS.MIT.EDU, Scheme@MC.LCS.MIT.EDU
In-Reply-To: Alan@AI.AI.MIT.EDU's message of Mon, 8 Feb 88 17:44:38 EST <323426.880208.JAR@AI.AI.MIT.EDU>
Subject: !
Date: Mon, 8 Feb 88 17:44:38 EST
From: Alan@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
(define (make-cell)
(call-with-current-continuation
(lambda (return-from-make-cell)
(letrec ((state
(call-with-current-continuation
(lambda (return-new-state)
(return-from-make-cell
(lambda (op)
(case op
((set)
(lambda (value)
(call-with-current-continuation
(lambda (return-from-access)
(return-new-state
(list value return-from-access))))))
((get) (car state)))))))))
((cadr state) 'done)))))
What the hey is this?
∂08-Feb-88 2250 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com Can we standardize Scheme without killing it?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 88 22:50:01 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 01:08:04 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac29953; 8 Feb 88 20:39 EST
Received: from csc.ti.com by RELAY.CS.NET id aa25077; 8 Feb 88 20:32 EST
Received: from mips by tilde id AA05490; Mon, 8 Feb 88 17:33:59 CST
Received: by mips id AA10271; Mon, 8 Feb 88 17:33:55 CST
Date: Mon, 8 Feb 88 17:33:55 CST
From: David Bartley <bartley%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802082333.AA10271@mips>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Sat, 6 Feb 88 20:13:34 EST <322467.880206.HAL@AI.AI.MIT.EDU>
Subject: Can we standardize Scheme without killing it?
I can almost feel consensus in the air---although a number of people
have been conspicuously silent concerning standardization. I'm
prepared to go wherever and meet whomever may be necessary to help
resolve the non-technical aspects of Scheme standardization. Shall we
accept Ramsdell's invitation to meet at MITRE? When? If not, where?
How about the rest of you? Does silence means apathy or tacit approval?
(Despair?)
One problem with all standards efforts is the travel costs associated
with meetings. Are we likely to disenfranchise anyone on that basis?
If we were to agree in advance to stick closely to R3RS, could we get
by with fewer active participants doing most of the work?
--db--
∂09-Feb-88 0715 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Can we standardize Scheme without killing it?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 07:08:16 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 10:06:44 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07252; 9 Feb 88 9:54 EST
Received: from brandeis by csnet-relay.csnet id ac28762; 9 Feb 88 9:48 EST
Received: by brandeis.ARPA (5.51/4.7)
id AA13182; Tue, 9 Feb 88 08:44:47 EST
Received: by mephi.earth1.com (3.2/SMI-3.2)
id AA14967; Tue, 9 Feb 88 08:43:34 PST
Date: Tue, 9 Feb 88 08:43:34 PST
From: James Miller <jmiller%mephi%brandeis.csnet@RELAY.CS.NET>
Message-Id: <8802091643.AA14967@mephi.earth1.com>
To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET
In-Reply-To: David Bartley's message of Mon, 8 Feb 88 17:33:55 CST <8802082333.AA10271@mips>
Subject: Can we standardize Scheme without killing it?
I haven't entered the fray yet, and I don't want to do anything about
heating up the debate. My personal opinion is that I would prefer not
to standardize, but I suspect that we will have to do so for a large
variety of reasons.
I prefer the IEEE option as I understand it now over the ANSI option,
but I am afraid that costs *ARE* the single determining feature in my
ability to work on this. They are one reason I prefer IEEE. I'd hate
to get left out, but I am a new faculty member (first year) and have
no way to afford travel expenses. Thus, the MITRE meeting has
significant appeal to me; but that's very selfish.
One final note: I'm scared by Don Oxley's message regarding a
diversion from the minimalist standard. I'm not very much of a
minimalist myself, but I see absolutely no hope of getting a standard
we will all like if we don't strongly adopt a Steele-like stance
against new features. I suggest that we take a fairly strong line
that any proposed extension which can be implemented using Yellow
Pages style be kept out of the standard entirely. I also believe that
we *have* to finally agree on macros to make this philosophy reaonably
workable.
--Jim
∂09-Feb-88 1831 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com A Minimalist Standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 88 18:31:23 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 9 Feb 88 21:30:21 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa15125; 9 Feb 88 20:02 EST
Received: from csc.ti.com by RELAY.CS.NET id au01645; 9 Feb 88 19:56 EST
Received: from mips by tilde id AA02306; Tue, 9 Feb 88 17:45:33 CST
Received: by mips id AA21412; Tue, 9 Feb 88 17:45:27 CST
Date: Tue, 9 Feb 88 17:45:27 CST
From: David Bartley <bartley%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802092345.AA21412@mips>
To: rrrs-authors@mc.lcs.mit.edu
Cc: oxley%home.csc.ti.com@RELAY.CS.NET, Bartley%mips.csc.ti.com@RELAY.CS.NET
In-Reply-To: Don Oxley's message of Mon, 8 Feb 88 15:43:39 CST <8802082143.AA03731@home>
Subject: A Minimalist Standard
> If Scheme is to be a vehicle for research and experimentation, then I
> forsee little problem, but as Scheme becomes more of a development
> language for delivering other applications (eg., TI's Personal
> Consultant), then there will be considerable pressure to "standardize"
> the non-standard parts of the language. For example, many of us at TI
> have succumbed to the use of multiple values as part of our Scheme
> language - not to investigate multiple values but to use it in larger
> efforts.
>
> I don't have a solution to this problem, but I think that something
> more than a minimalist approach will become necessary. The language
> must be "sufficient" for significant development as perceived by the
> users.
I think we can reasonably hope to have our cake and eat it too. A
"minimalist" standard is necessary now because it's the only kind we
can hope to get agreement on any time soon. It also establishes what
kind of language Scheme is---a very important point to many of us who
are fearful of any standardization.
I also think it is sufficient, even for the case you mention (users
writing non-trivial applications who need more features than exist in
the minimalist standard). Such "features" need to be debated among
the implementors and alternatives placed before the user community as
parts of packaged Scheme products. They need to prove themselves
before they are considered for standardization. I think the informal
approach has worked so far, and should continue to be used. Macros,
opaque objects, etc., can and should be worked out informally and
incorporated in a later revision.
One of the problems with the Common Lisp standardization process is
that the existence of holes---like a real LOOP macro or a standard
Object programming paradigm---has resulted in *design* going on
instead of *ratification*. We don't need to do that.
I support the minimalist approach, which I take to mean (roughly)
blessing R3RS with minor fixup (e.g. the numbers proposal from last
June, but not macros (and throw out DO??)). The segregation of
essential, inessential, and "yellow pages" is already there.
--db--
∂10-Feb-88 0125 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization (meetings and relation to CL)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 01:25:36 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 10 Feb 88 04:24:52 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA26277; Mon, 8 Feb 88 10:02:23 EST
Posted-Date: Mon, 8 Feb 88 10:01:21 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA09128; Mon, 8 Feb 88 10:01:21 EST
Date: Mon, 8 Feb 88 10:01:21 EST
Message-Id: <8802081501.AA09128@darwin.sun.uucp>
To: RPG@SAIL.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dick Gabriel's message of 04 Feb 88 1206 PST <8802042023.AA01455@mitre-bedford.ARPA>
Subject: Standardization (meetings and relation to CL)
Given the number responses to the idea of MITRE hosting a meeting
about Scheme standardization, I conclude there is insufficient interest.
However, I got the details of hosting meetings at MITRE. I found
there are no problems, but one further constraint. Meetings held at
MITRE which include non-employees, must occur during normal working
hours. In other words, Saturdays and Sundays are out. For the
record, I would be happy to host other Scheme related meetings in the
future as long as they occur on a weekday.
Dick Gabriel:
>2. I am saddened by the animosity I see towards Common Lisp and by
>implication towards the Common Lisp community. ....
I guess Dick's comment was directed at part of one of my notes:
>On the subject of confusing Scheme with Common Lisp, I follow the
>practice of never mentioning Lisp while talking about Scheme unless
>the person I am talking to asks about Scheme's relation to Lisp. This
>practice avoids the AI baggage, as well as any negative impressions
>the person has of Lisp. Of course, disowning our connection to Lisp
>would be like disowning one's parents, but I see no need to tie our
>fortunes to Lisp's. Thus I strongly oppose the idea of expanding
>X3J13 to cover both Lisp and Scheme. If we choose to standardize
>Scheme, let's do it independently of efforts to standardize other
>dialects of Lisp.
My point was that Scheme and any other dialect of Lisp, such as Common
Lisp, should not be standardized by the same committee. Just as Ada
documents acknowledge the influence of Pascal, any document on Scheme
should acknowledge the influence of various Lisp dialects. I am told
Ada designers maintained extensive contact with the designers of other
languages. I encourage contact with the designers of other dialects
of Lisp, including the designers of Common Lisp. Never think I would
like to see Dick Gabriel and Guy Steele removed from this list because
they are too closely connected to Common Lisp!
I endorse Bartley's characterization of the relationship between
Common Lisp and Scheme being in the family of Lisp-like languages,
just as Ada and Pascal are in the Algol-like family. While Ada and
Pascal are in the same family, they maintain their own identity. Let
Scheme have its own. I hold a minority position which worries
about too much connection of the name Scheme with Lisp. I believe
excessive connection carries unnecessary baggage associated with AI,
and unnecessary baggage associated with other dialects of Lisp. I
know people who think all modern Lisp-like languages have PROG and GO.
While Common Lisp is often cited as the reason a Lisp-like language
is thought to be a large language, I don't single out Common Lisp as
the sole source of wrong ideas about Scheme. I think it is a mistake
to assume the average Lisp programmer is clear on the differences
between dialects, and we should aid that programmer when we can.
I respectfully oppose your proposal to broaden the scope of X3J13
because I think if Scheme is to be standardized, it should happen in a
committee independent of other efforts to standardize Lisp dialects.
I did not mean to imply the standardization effort should ignore the
work of other efforts. In fact, I read some of the Common Lisp
proposals, most recently, the CLOS proposal. I hope this clears
things up.
John
∂10-Feb-88 0641 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization (A conservative approach)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 06:41:44 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 10 Feb 88 09:28:44 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA29906; Wed, 10 Feb 88 09:25:37 EST
Posted-Date: Wed, 10 Feb 88 09:24:26 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA12394; Wed, 10 Feb 88 09:24:26 EST
Date: Wed, 10 Feb 88 09:24:26 EST
Message-Id: <8802101424.AA12394@darwin.sun.uucp>
To: gls@Think.COM
Cc: ramsdell@mitre-bedford.ARPA, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 5 Feb 88 19:09:01 EST <8802060009.AA01135@kali.think.com>
Subject: Standardization (A conservative approach)
Should Scheme standardization be approved, I propose the following
plan for the initial draft.
Limit changes to:
1) Adding Abelson's manifesto on Scheme evolution,
2) adding multiple values,
3) modifying the number syntax as previously agreed, and
4) wordsmithing.
Letting each person choose *one* new feature to propose could make the
standards process into a design process. I like the idea of
standardizing something close to R3RS Scheme.
My view is that informal Scheme design meetings, such as the Scheme
workshop of June 1987, are the places to talk about evolutionary changes
to Scheme. Are those meetings going to be replaced by formal
standards meetings, or are the standards meetings going to only codify
the time tested ideas that originated in workshops and other
locations?
John
∂10-Feb-88 0734 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com A Minimalist Standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 07:33:59 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Feb 88 10:22:37 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa22484; 10 Feb 88 9:27 EST
Received: from csc.ti.com by RELAY.CS.NET id ab05631; 10 Feb 88 9:17 EST
Received: from home by tilde id AA14501; Wed, 10 Feb 88 07:37:46 CST
Received: by home id AA08639; Wed, 10 Feb 88 07:36:05 CST
Date: Wed, 10 Feb 88 07:36:05 CST
From: Don Oxley <oxley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802101336.AA08639@home>
To: bartley%mips.csc.ti.com@RELAY.CS.NET
Cc: rrrs-authors@mc.lcs.mit.edu, Bartley%mips.csc.ti.com@RELAY.CS.NET
In-Reply-To: David Bartley's message of Tue, 9 Feb 88 17:45:27 CST <8802092345.AA21412@mips>
Subject: A Minimalist Standard
I fundamentally agree with the minimalist notions. My point is that I
would rather provide a mechanism to track "popular" but non-standard
features (such as multiple values) in such a way that users who use
such things have a reasonable method for learning their definition,
that there be only one, and that the chosen names not preempt the use
of that name in an eventual standard. In NCS today, we have preempted
"values", "eval", "syntax", "macro", ... to name a few. My point is
that something simple like a prefix (eg. ncs-values -
non-conforming-scheme-values) would avoid preempting the identifier
values and would give me a reasonable chance of writing an automatic
parser to repair the damage if a standard is ever reached.
It seems to me that the key is allowing Scheme to be widely used, but
somehow controlling the defacto standardization through widespread
usage. A purely minimalist approach seems unlikely to do that to me.
--Don
∂11-Feb-88 0758 @MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU call for standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 07:58:39 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 11 Feb 88 10:54:58 EST
Received: by ZOHAR.AI.MIT.EDU; Thu, 11 Feb 88 10:57:35 est
Date: Thu, 11 Feb 88 10:57:35 est
From: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802111557.AA12523@zohar>
To: rrrs-authors@mc
Subject: call for standardization meeting
Reply-To: hal@ai.ai.mit.edu
I would like to hold a one-day meeting of RRRS authors to address the
standardization question.
The purpose of the meeting would be to decide whether we want to go
ahead with standardization, and if so, how (what standards
organization, who should be responsible for doing the work, etc.).
I do not think we should make any technical decisions about Scheme at
this meeting, although we might review some of the suggested changes.
My bias is that if we do decide to go ahead with a standard, then the
standard itself should be essentially identical to the next version of
R*S. (But I would like to hear from people who have contrary
opinions.)
Actually producing the next version of R*S would happen at a meeting
held in conjuction with the L&FP conference this summer.
For purely selfish reasons, I would like to hold the meeting on a
weekend in the Boston area. I volunteer MIT to host it. Here are
three possible dates:
Saturday, March 12
Saturday, March 19
Saturday, March 26
Please send mail within a week (to RRRS-AUTHORS) with one or more of the
following responses:
* you can/will come (and which dates are OK)
* you don't want to have a meeting or can't come to one, but you think
that standardization is a good/bad idea; any thoughts on a preferred
standards organization (IEEE, X3, Better Homes and Gardens, etc.)
* you would prefer to have the meeting somewhere else, with suggested
place and dates.
* you are bored/sick of the whole thing
If there is enough response, I'll go ahead and schedule the meeting.
-- Hal
∂11-Feb-88 1020 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA call for standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 10:20:03 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 11 Feb 88 13:19:52 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA02654; Thu, 11 Feb 88 13:19:14 EST
Posted-Date: Thu, 11 Feb 88 13:18:02 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA13233; Thu, 11 Feb 88 13:18:02 EST
Date: Thu, 11 Feb 88 13:18:02 EST
Message-Id: <8802111818.AA13233@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Thu, 11 Feb 88 10:57:35 est <8802111557.AA12523@zohar>
Subject: call for standardization meeting
I will come and any Saturday in March is okay for me.
John
∂11-Feb-88 1101 @MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA Meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 11:01:27 PST
Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 11 Feb 88 14:00:55 EST
Received: by ATHENA.CS.YALE.EDU; Thu, 11 Feb 88 13:55:41 EST
Date: Thu, 11 Feb 88 13:55:41 EST
From: James Philbin <philbin-jim@YALE.ARPA>
Full-Name: James Philbin
Message-Id: <8802111855.AA19221@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-aac0/AAC0)
via WIMP-MAIL (Version 1.2/1.4) ; Thu Feb 11 13:47:35
Subject: Meeting
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson), Thu, 11 Feb 88 10:57:35 est
My bias is that if we do decide to go ahead with a standard, then the
standard itself should be essentially identical to the next version of
R*S. (But I would like to hear from people who have contrary
opinions.)
If we decide to standardize, then I agree that it should be identical
with the next version of R*S.
* you can/will come (and which dates are OK)
I will come. All the dates are fine with me.
- Jim
-------
∂11-Feb-88 1543 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 15:42:54 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 11 Feb 88 18:42:28 EST
Received: by iuvax.cs.indiana.edu; id AA08705; Thu, 11 Feb 88 18:20:20 EST
Date: Thu, 11 Feb 88 18:20:20 EST
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Message-Id: <8802112320.AA08705@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: meeting
The only weekend possible for me is March 26.
Dan
∂11-Feb-88 1558 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu is make-environment really necessary for packages?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 15:58:43 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Feb 88 18:54:35 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA06487; Thu, 11 Feb 88 15:23:19 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Feb 88 19:09:35 GMT
From: rochester!neal@rutgers.edu (Neal Gafter)
Organization: U of Rochester, CS Dept., Rochester, NY
Subject: is make-environment really necessary for packages?
Message-Id: <6722@sol.ARPA>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I do not understand the need for an explicit environment type in scheme.
It seems that lambda could serve the same purpose.
Suppose there were not an explicit environment type. In this case,
the procedure "eval" would take only a single parameter: the expression
to be evaluated (in the current environment).
Packages, which are currently created this way:
(define foo (make-environment
(define x ...)
(define y ...)
...
))
and used this way:
(eval '(expression) foo)
Could still be created this way:
(define foo (let ()
(define x ...)
(define y ...)
...
(lambda (_x) (eval _x))
))
and used this way:
(foo '(expression))
It would appear that environments are unnecessary. The Revised↑3
report does not include any description of "make-environment", "eval",
or "access".
Neal Gafter <neal@cs.rochester.edu>
--
Arpa: neal@cs.rochester.edu (Neal Gafter)
UUCP: ...{rocksvax|allegra|decvax}!rochester!neal
USnail: Department of Computer Science, U. of Rochester, N.Y. 14627
phone: (716) 275 - 1348 (office) or (716) 473 - 2361 (home)
∂11-Feb-88 1631 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu is make-environment really necessary for packages?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:31:16 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Feb 88 18:54:35 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA06487; Thu, 11 Feb 88 15:23:19 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Feb 88 19:09:35 GMT
From: rochester!neal@rutgers.edu (Neal Gafter)
Organization: U of Rochester, CS Dept., Rochester, NY
Subject: is make-environment really necessary for packages?
Message-Id: <6722@sol.ARPA>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I do not understand the need for an explicit environment type in scheme.
It seems that lambda could serve the same purpose.
Suppose there were not an explicit environment type. In this case,
the procedure "eval" would take only a single parameter: the expression
to be evaluated (in the current environment).
Packages, which are currently created this way:
(define foo (make-environment
(define x ...)
(define y ...)
...
))
and used this way:
(eval '(expression) foo)
Could still be created this way:
(define foo (let ()
(define x ...)
(define y ...)
...
(lambda (_x) (eval _x))
))
and used this way:
(foo '(expression))
It would appear that environments are unnecessary. The Revised↑3
report does not include any description of "make-environment", "eval",
or "access".
Neal Gafter <neal@cs.rochester.edu>
--
Arpa: neal@cs.rochester.edu (Neal Gafter)
UUCP: ...{rocksvax|allegra|decvax}!rochester!neal
USnail: Department of Computer Science, U. of Rochester, N.Y. 14627
phone: (716) 275 - 1348 (office) or (716) 473 - 2361 (home)
∂11-Feb-88 1948 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Yale T (compiling)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 19:48:27 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 11 Feb 88 22:45:08 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA11848; Thu, 11 Feb 88 19:37:11 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 Feb 88 16:14:19 GMT
From: broman@cod.nosc.mil (Vincent P. Broman)
Organization: Naval Ocean Systems Center, San Diego
Subject: Re: Yale T (compiling)
Message-Id: <976@cod.NOSC.MIL>
References: <13258@cornell.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Yale T v3.0 may be able to compile itself, but the method used is
an _undocumented_ feature of the system, seemingly not intended
for the unwashed masses. There seem to be various compile and load
scripts floating around in the source directories, but I couldn't
intuit the grand scheme intended.
Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA
Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
∂12-Feb-88 0357 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU KMP's reply to standardizaiotn meeting note
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 03:57:39 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Feb 88 06:57:18 EST
Date: Fri, 12 Feb 88 06:57:36 EST
From: Hal Abelson <HAL@AI.AI.MIT.EDU>
Subject: KMP's reply to standardizaiotn meeting note
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <325467.880212.HAL@AI.AI.MIT.EDU>
From KMP@STONY-BROOK.SCRC.Symbolics.COM Thu Feb 11 15:13:32 1988
Date: Thu, 11 Feb 88 11:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call for standardization meeting
To: HAL@AI.AI.MIT.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8802111557.AA12523@zohar>
I'm am terribly worried about the whole thing.
I'm interested in attending to lobby against a standard.
The week of Mar 14-18 several of us (me and Bartley anyway -- maybe
Will and a few others) will be at X3J13 in Palo Alto. I'd like to have
both weekends adjacent to that available for spending time there.
I have no times prior to that free. Mar 26 is my very strong preference.
∂12-Feb-88 1508 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com Re: call for standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 15:08:09 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Feb 88 18:07:51 EST
Received: from relay2.cs.net by RELAY.CS.NET id ad29909; 12 Feb 88 15:51 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ao06872; 12 Feb 88 15:46 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA10898; Fri, 12 Feb 88 09:00:37 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA10250; Fri, 12 Feb 88 09:01:06 PST
Date: Fri, 12 Feb 88 09:01:06 PST
From: Norman Adams <adams%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET>
Message-Id: <8802121701.AA10250@tekchips.CRL.TEK.COM>
Subject: Re: call for standardization meeting
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson <hal@zohar.ai.mit.edu>, Thu, 11 Feb 88 10:57:35 est
I can attend the 19th or 26th. -Norman
-------
∂15-Feb-88 0756 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU [hudak-paul@YALE.ARPA: Re: call for standardization meeting]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 07:56:09 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 15 Feb 88 10:55:02 EST
Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Mon, 15 Feb 88 10:56:15 est
Received: by MURREN.AI.MIT.EDU; Mon, 15 Feb 88 11:00:04 est
Date: Mon, 15 Feb 88 11:00:04 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802151600.AA10418@murren>
To: rrrs-authors%mc@KLEPH.AI.MIT.EDU
Subject: [hudak-paul@YALE.ARPA: Re: call for standardization meeting]
Reply-To: hal@ai.ai.mit.edu
Date: Mon, 15 Feb 88 10:43:06 EST
From: Paul Hudak <hudak-paul@YALE.ARPA>
Subject: Re: call for standardization meeting
To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson)
In-Reply-To: hal@ZOHAR.AI.MIT.EDU (Hal Abelson), Thu, 11 Feb 88 10:57:35 est
I would like to hold a one-day meeting of RRRS authors to address the
standardization question.
Hal, as you know I am not a super active member of the RRRS committee,
but am very interested in Scheme and its promotion. I won't be able
to attend the standardization meeting, but if you're interested, here's
my opinion about the whole matter:
I am morderately in favor of standarization for two simple reasons:
1) Historically the standardization of a language seems to have helped
the promotion of the language.
2) In the face of CL standarization, Scheme's NOT being standarized
may give the impression that the Lisp community is more confident
in CL and is thus endorsing it's use in production-quality software
systems, etc.
With regard to the latter comment, I must say that I've been somewhat
surprised by the amount of discussion about Scheme being as different
from CL as Pascal is from Algol, etc. etc. I certainly agree with
that argument, and it's a compelling argument against having the
standarization efforts combined, but in the context of how the "real
world" views things, it may be irrelevant. The fact is, "Lisps" in
general offer many common advantages, and when a programmer/manager/
whomever decides that Lisp is best for a particular application, they
will tend to look for the best-documented/supported/tried/standardized
etc. language available. (This same kind of reasoning will be used by
the software/hardware manufacturers when trying to decide what
languages to support.) Ok, so they'll also ask which is best from a
programming language standpoint, but my point is that there are many
other, often overriding, issues that they will consider as well.
The awkward conclusion I find myself making is that I think Scheme
needs to be standarized primarily because CL is. Otherwise, I think
(as everyone else apparently does) that it's too early. (The awkward
thing about this conclusion is that I also think it's too early to
standarize CL, so implicit in my conlusion is that one wrong justifies
another...)
-Paul
P.S. I have no opinion about which of the various means for standarization
is best (or worst).
P.P.S. If you think it's appropriate I don't mind if you cc this to RRRS.
-------
∂15-Feb-88 1012 NET-ORIGIN@MC.LCS.MIT.EDU Re: call for standardization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 10:12:50 PST
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 FEB 88 13:12:59 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09879@EDDIE.MIT.EDU>; Mon, 15 Feb 88 13:10:45 EST
Received: from purdue.UUCP by gatech.edu with UUCP (5.58/7.3.GT)
id AA12415; Mon, 15 Feb 88 13:05:17 EST
Received: by arthur.cs.purdue.edu; (5.54/3.16)
id AA01125; Mon, 15 Feb 88 12:55:16 EST
Message-Id: <8802151755.AA01125@arthur.cs.purdue.edu>
Date: Mon, 15 Feb 88 11:16:10 EST
From: R. Kent Dybvig <gatech!purdue!iuvax!dyb@EDDIE.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu.UUCP
Subject: Re: call for standardization
[Please excuse me if this note is duplicated---our arpanet link went
down Friday and hasn't come back yet, so I'm trying to send via uucp]
---------
* you would prefer to have the meeting somewhere else, with suggested
place and dates.
We would like to offer to hold the meeting here at Indiana University
on March 26. I will handle local arrangements.
Kent
∂15-Feb-88 1725 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com (rationalize x y)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 17:25:16 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Feb 88 20:06:20 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07509; 15 Feb 88 19:43 EST
Received: from csc.ti.com by RELAY.CS.NET id ak25765; 15 Feb 88 19:36 EST
Received: from home by tilde id AA10951; Mon, 15 Feb 88 17:43:05 CST
Received: by home id AA21446; Mon, 15 Feb 88 17:41:29 CST
Date: Mon, 15 Feb 88 17:41:29 CST
From: David Bartley <bartley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802152341.AA21446@home>
To: rrrs-authors@mc.lcs.mit.edu
Subject: (rationalize x y)
Ed Ferguson and I want to clarify some issues concerning the Scheme
procedure "rationalize", which is documented in R3RS as follows:
[...]
(rationalize x y) procedure
(rationalize x) procedure
These procedures create integers and rationals. Their
results are exact if and only if their arguments are exact.
[...] With two arguments, RATIONALIZE produces the rational
number with smallest denominator differing from X by no more
than Y. With one argument, RATIONALIZE produces the best
rational approximation to X, preserving all of the precision in
its representation.
(1) When Y is supplied and is non-zero, it would seem more proper to
return an inexact result (unless perhaps that result is `=' to X and X
is exact).
(2) Although the notation indicates that the argument X is real, would
it be frivolous to say that (RATIONALIZE Z Y), where Z is a non-real
complex number, is defined by
(make-rectangular (rationalize (real-part z y))
(rationalize (imag-part z y))) ?
Two objections come to mind: (2a) this discriminates against an
implementation that uses polar representation, and (2b) one might want
to interpret Y as a error term for the magnitude rather than for the
real and imaginary parts separately.
(3) Do we really want an absolute error test or is a relative error
test sometimes more appropriate?
(4) The wording ``rational number with smallest denominator differing
from X by no more than Y'' seems to rule out using Euclid's algorithm
and continued fractions. That is, suppose W is the first number whose
difference from X is less than Y in the continued fraction series of
successively better approximations to X. Euclid doesn't guarantee
that there is no number within Y of X with smaller denominator than
W's. Did the author of these words have a different algorithm in mind?
As an example, consider (RATIONALIZE 11/16 1/4). The successive
convergents to 11/16 using continued fractions are 0, 1, 2/3, and
11/16. The first number in that series which is within 1/4 of 11/16
is 2/3, but the value 1/2 is also within 1/4 of 11/16 and has a
smaller denominator.
Regards,
David Bartley
∂15-Feb-88 2019 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Amiga, size constraints
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 20:18:53 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 15 Feb 88 23:15:41 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA13502; Mon, 15 Feb 88 19:46:00 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 16 Feb 88 03:33:21 GMT
From: agate!eris!mwm@ucbvax.Berkeley.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Subject: Re: Scheme for the Amiga, size constraints
Message-Id: <6996@agate.BERKELEY.EDU>
References: <518@acf3.NYU.EDU>, <2194@bloom-beacon.MIT.EDU>, <gW2-2wy00jWTMDQ0Gq@andrew.cmu.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <gW2-2wy00jWTMDQ0Gq@andrew.cmu.edu> ah4h+@andrew.cmu.edu (Andrew Hudson) writes:
<
<>I have implemented scheme 6.1 on my Amiga. I'll tell you, it's not an
<>easy thing to do. First of all,there is no way CScheme will work on a
<>machine with only 0.5M of RAM.
<
<I can hardly believe this! MacScheme ran well on a Mac with only 512k. What
<does a Mac have that an Amiga doesn't?
The Mac has a Scheme written for the Mac, that's what! :-)
CScheme 6.1 is a large C program, with portability and readability
being more important than size (and speed?). As a result, you get
something very large that runs on a fair number of machine running
Unix.
MacScheme (and the TI PCScheme) are reimplementations from scratch for
the target machine. Knowing exactly what your target is, and not
needing to write in an HLL[+] helps a lot for size.
I finally decided that the only way I was going to get a serious LISP
of reasonable size on the Amiga was to write it myself (in that
mythical entity known as "spare time"). The result should be quite
happy on a 1Meg Amiga (the "defacto standard" these days), and
shouldn't be unusable on a 512K Amiga. Putting it on a 68020 is
another problem. Putting it on an 80*6 will be _very_ hard.
[+] If someone can tell me how to write a tail-recursive eval/apply in
a non-tr HLL that's more readable than the assembler code that does
the same, I'd appreciate it!
<mike
--
The handbrake penetrates your thigh. Mike Meyer
A tear of petrol is in your eye. mwm@berkeley.edu
Quick, let's make love before we die. ucbvax!mwm
On warm leatherette. mwm@ucbjade.BITNET
∂15-Feb-88 2156 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 21:56:20 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Feb 88 23:49:03 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa09662; 15 Feb 88 23:47 EST
Received: from tektronix.tek.com by RELAY.CS.NET id af26831; 15 Feb 88 23:43 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA08700; Mon, 15 Feb 88 16:37:05 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA10267; Mon, 15 Feb 88 16:37:33 PST
Message-Id: <8802160037.AA10267@tekchips.CRL.TEK.COM>
To: scheme@mc.lcs.mit.edu
Cc: scheme-librarian@mc.lcs.mit.edu, ayu%aquinas.csl.uiuc.edu@RELAY.CS.NET,
edh%HNYKUN52.BITNET@cunyvm.cuny.edu, net%tub.bitnet@RELAY.CS.NET,
dumas@SUMEX-AIM.STANFORD.EDU, mcvax!dutesta!brouw@uunet.uu.net,
nttca!Shasta!ll-xn!lll-crg!lll-tis!dgis!jkrueger@SHASTA.STANFORD.EDU
Subject: Gabriel benchmarks in Scheme
Date: 15 Feb 88 16:37:29 PST (Mon)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Someone asked for volunteers to collect/collate/report results for the
Scheme versions of the Gabriel benchmarks. I volunteer, but it would be
better if we had a volunteer who wasn't associated with a Scheme vendor.
If you're thinking of volunteering, please re-read the comments in Gabriel's
book so you'll know what you're getting into.
I'm sending copies of the Gabriel benchmarks in Scheme to those of you
listed in the "cc:" line. (If you don't receive a copy of this message,
then maybe I need a better address.) They will be arriving in four parts,
each about 20K bytes.
Because the benchmarks are so large, I would in the future prefer to send a
Macintosh- or IBM PC-compatible floppy disk to those of you who can use them.
Please send requests for the source code to:
Semantic Microsystems
4470 SW Hall Blvd Suite 340
Beaverton OR 97005
(503) 643-4539
I'd appreciate a donation of $5 or so to cover the cost of the disk and its
shipping. I suspect that's much less than it costs the network to transmit
these things.
William Clinger
∂16-Feb-88 0252 @MC.LCS.MIT.EDU:iuvax!dyb@ee.ecn.purdue.edu Re: call for standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 02:52:00 PST
Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 16 Feb 88 05:47:15 EST
Received: by ee.ecn.purdue.edu (5.54/1.12jrs)
id AA22845; Tue, 16 Feb 88 05:46:13 EST
Message-Id: <8802161046.AA22845@ee.ecn.purdue.edu>
Date: Sat, 13 Feb 88 10:57:19 EST
From: R. Kent Dybvig <iuvax!dyb@ee.ecn.purdue.edu>
To: hal@mc.lcs.mit.edu
Subject: Re: call for standardization meeting
Cc: rrrs-authors@mc.lcs.mit.edu
* you would prefer to have the meeting somewhere else, with suggested
place and dates.
We would like to offer to hold the meeting here at Indiana University
on March 26. I will handle local arrangements.
Kent
∂16-Feb-88 1242 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU (rationalize x y)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 12:42:17 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 14:09:23 EST
Date: Tue, 16 Feb 88 14:08:28 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: (rationalize x y)
To: bartley%home.csc.ti.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 15 Feb 88 17:41:29 CST from David Bartley <bartley%home.csc.ti.com at RELAY.CS.NET>
Message-ID: <327379.880216.ALAN@AI.AI.MIT.EDU>
Definition: A rational r1 is "simpler" than a rational r2, written
r1 <* r2, if r1 = p1/q1 and r2 = p2/q2 (both in lowest terms) and
|p1| <= |p2| and |q1| <= |q2|.
So 1/2 <* 1/3 and 1/2 <* 3/2 but 1/3 and 3/2 are incomparable. This
definition works for Gaussian rationals as well.
Theorem: The relation <* is a partial order on rationals. Also, zero is
simpler than any other rational (0 <* r for all r).
Theorem: For any two incomparable (under <*) rationals r < s, there exists
a rational t such that r < t < s, and t <* r and t <* s.
Theorem: Any interval of the real numbers (open, half-open, or closed)
contains a simplest rational number.
I think that the proofs of these theorems are all straightforward enough
that I don't need to give them here.
Date: Mon, 15 Feb 88 17:41:29 CST
From: David Bartley <bartley%home.csc.ti.com at RELAY.CS.NET>
Ed Ferguson and I want to clarify some issues concerning the Scheme
procedure "rationalize", which is documented in R3RS as follows:
[...]
(rationalize x y) procedure
(rationalize x) procedure
These procedures create integers and rationals. Their
results are exact if and only if their arguments are exact.
[...] With two arguments, RATIONALIZE produces the rational
number with smallest denominator differing from X by no more
than Y. With one argument, RATIONALIZE produces the best
rational approximation to X, preserving all of the precision in
its representation.
(1) When Y is supplied and is non-zero, it would seem more proper to
return an inexact result (unless perhaps that result is `=' to X and X
is exact).
The phrase "the rational number with smallest denominator" unfortunately
leaves RATIONALIZE slightly underspecified. (RATIONALIZE 3/2 1) is free to
be either 1 or 2, since they both have a denominator of 1. I presume that
what R3RS is trying to say is that (RATIONALIZE X Y) returns the simplest
rational number in the interval [X-Y, X+Y]. (When there is a unique
rational number with smallest denominator it is also the simplest.)
Since the theorem above guarantees the uniqueness and existence of a
simplest rational, it would seem to me that if X and Y are exact, then the
answer should be exact as well.
It is less clear to me what R3RS is trying to say that the one argument
case of RATIONALIZE is supposed to do. One possible interpretation seems
to be that (RATIONALIZE X) is the same as (RATIONALIZE X #E0), since then
in the case where X is an inexact floating point number, it might well return
the same (inexact) rational that the Common Lisp RATIONALIZE function
returns. (And if X was an exact floating point number, it might return the
same (exact) rational that the Common Lisp RATIONAL function would return.)
The description doesn't say what should happen if Y is negative...
(2) Although the notation indicates that the argument X is real, would
it be frivolous to say that (RATIONALIZE Z Y), where Z is a non-real
complex number, is defined by
(make-rectangular (rationalize (real-part z y))
(rationalize (imag-part z y))) ?
Two objections come to mind: (2a) this discriminates against an
implementation that uses polar representation, and (2b) one might want
to interpret Y as a error term for the magnitude rather than for the
real and imaginary parts separately.
I would object because the definition doesn't work.
(RATIONALIZE 2/5+1/5i 1/12) would return 1/3+1/4i. But in lowest terms
2/5+1/5i is 1/(2-i) and 1/3+1/4i is (4+3i)/12, so the input was a simpler
rational than the output!
(3) Do we really want an absolute error test or is a relative error
test sometimes more appropriate?
You can always construct the relative case given the absolute case. It's
just a way of letting you specify an interval.
(4) The wording ``rational number with smallest denominator differing
from X by no more than Y'' seems to rule out using Euclid's algorithm
and continued fractions. That is, suppose W is the first number whose
difference from X is less than Y in the continued fraction series of
successively better approximations to X. Euclid doesn't guarantee
that there is no number within Y of X with smaller denominator than
W's. Did the author of these words have a different algorithm in mind?
As an example, consider (RATIONALIZE 11/16 1/4). The successive
convergents to 11/16 using continued fractions are 0, 1, 2/3, and
11/16. The first number in that series which is within 1/4 of 11/16
is 2/3, but the value 1/2 is also within 1/4 of 11/16 and has a
smaller denominator.
What you do is compute the continued fractions of the two endpoints of the
interval in question. In this case 7/16 = 0+1/(2+1/(3+1/2)) and 15/16 =
0+1/(1+1/15). Since the continued fraction of the answer has the same
initial terms as the continued fractions of the endpoints, you stop the
continued fraction expansion as soon as you see that the next term will
differ. Then the final term is the smallest integer in the interval
between the two remainders. In this case 7/16 = 0+1/(2+2/7) and 15/16 =
0+1/(1+1/15), so since the smallest integer between 2+2/7 and 1+1/15 is 2,
the answer is 0+1/2 = 1/2.
Since you only need to compute the continued fractions until they differ,
and since you can accumulate the answer as you go, this computation isn't
all that expensive.
∂16-Feb-88 1440 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU DO in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 14:40:01 PST
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 16 Feb 88 16:18:38 EST
Date: Tue 16 Feb 88 15:23:51-EST
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: DO in Scheme
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12375254602.54.MKATZ@A.ISI.EDU>
A couple of times recently I have seen suggestions that DO be removed from
Scheme. I must concur in that I find DO to be one of the cruftiest and most
opaque constructs in the language (and would hate to see it become part of any
standard). However, it seems to me that before we can remove such constructs,
we need to agree on a macro standard so that they can be reintroduced as macros
through the Yellow Pages. There are undoubtedly many users within our
community who make extensive use of DO, and it seems unkind and unnecessary to
leave them high and dry. On the topic of macros, didn't we appoint a commity
at the last Scheme meeting composed, I believe, of Chris Hanson, Jonathan Rees,
et. al. to look into the macro question and report back to us. What ever
happened to this effort. It actually seemed to me that they had a starting
proposal which was reasonably close to being acceptable to nearly all parties
concerned.
At the risk of pushing my luck, I would suggest that with the death of DO we
reintroduce named-let to at least optional status. Having used all of DO,
named-let, and the equivalent letrec forms over several years, I have found
named-let to be by far the simplest to read and therefore the most elegant. It
is convenient to be able to specify the initial bindings of loop variables at
loop entry (an advantage of named-let over letrec) without being forced to go
to the more complex and convoluted form of DO.
Morry Katz
-------
∂16-Feb-88 1721 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU Standardization meeting on March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 17:21:05 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 Feb 88 20:14:29 EST
Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Tue, 16 Feb 88 17:31:44 est
Received: by MURREN.AI.MIT.EDU; Tue, 16 Feb 88 17:35:36 est
Date: Tue, 16 Feb 88 17:35:36 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802162235.AA11693@murren>
To: rrrs-authors%mc@KLEPH.AI.MIT.EDU
Subject: Standardization meeting on March 26
Reply-To: hal@ai.ai.mit.edu
The responses over the past week indicate a clear preference for
meeting on March 26th.
This will be a 1-day meeting to discuss standardization.
Both MIT and Indiana have volunteered to host the meeting.
Please respond within a week (to RRRS-AUTHORS, not only to me) saying
A. Will you come if the meeting is at Indiana?
B. Will you come if the meeting is at MIT?
--- if you answer yes to either of the above then ---
C. Given a choice, would you prefer to meet at MIT or at Indiana?
∂16-Feb-88 1756 @MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 17:56:11 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 20:21:58 EST
Date: Tue, 16 Feb 88 19:14:08 EST
From: Hal Abelson <HAL@AI.AI.MIT.EDU>
Subject: standardization meeting March 26
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <327556.880216.HAL@AI.AI.MIT.EDU>
The responses over the past week indicate a clear preference for
meeting on March 26th.
This will be a 1-day meeting to discuss standardization.
Both MIT and Indiana have volunteered to host the meeting.
Please respond within a week (to RRRS-AUTHORS, not only to me) saying
A. Will you come if the meeting is at Indiana?
B. Will you come if the meeting is at MIT?
--- if you answer yes to either of the above then ---
C. Given a choice, would you prefer to meet at MIT or at Indiana?
-- Hal
∂16-Feb-88 1839 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: DO in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 18:39:48 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 16 Feb 88 21:27:05 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 FEB 88 15:00:46 PST
Date: Tue, 16 Feb 88 15:00:27 PST
From: Pavel.pa@Xerox.COM
Subject: Re: DO in Scheme
In-reply-to: <12375254602.54.MKATZ@A.ISI.EDU>
To: Morris Katz <MKATZ@A.ISI.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880216-150046-4099@Xerox>
Morris Katz says:
``At the risk of pushing my luck, I would suggest that with the death of DO we
reintroduce named-let to at least optional status.''
Am I confused? It looks to me that the named version of LET is still in the
language. In fact, its description directly follows that of DO in R3RS.
Pavel
∂16-Feb-88 1910 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Standardization meeting on March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 19:10:32 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 Feb 88 22:00:10 EST
Received: from zohar (zohar.ai.mit.edu) by KLEPH.AI.MIT.EDU; Tue, 16 Feb 88 22:01:21 est
Received: by ZOHAR.AI.MIT.EDU; Tue, 16 Feb 88 22:02:32 est
Date: Tue, 16 Feb 88 22:02:32 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8802170302.AA03068@zohar>
To: hal@ai.ai.mit.edu
Cc: rrrs-authors%mc@KLEPH.AI.MIT.EDU
In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren>
Subject: Standardization meeting on March 26
March 26th is fine with me.
A. Reluctantly
B. Enthusiastically and cheerfully
C. I much prefer MIT because
1. To be in Indiania I have to find someone to cover my class on the 25th.
2. I will have spent altogether too much time on airplanes this year.
The cost to you of me coming to Indiana is that
I will be grumpy and unpleasant.
∂16-Feb-88 1923 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU DO in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 88 19:23:42 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Feb 88 22:16:32 EST
Date: Tue, 16 Feb 88 20:05:46 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: DO in Scheme
To: MKATZ@A.ISI.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 16 Feb 88 15:23:51-EST from Morris Katz <MKATZ at A.ISI.EDU>
Message-ID: <327582.880216.JAR@AI.AI.MIT.EDU>
I like DO. I don't think I need to repeat Steele's defense of it, which
was posted one of the previous times this came up.
Named LET is there in the report, under a separate heading from LET
(somewhere near DO, I think -- probably why you missed it, sorry).
The macro proposal still needs some work. For example, it lacks a user
interface.
∂17-Feb-88 0606 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU Standardization meeting on March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 06:05:37 PST
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 17 Feb 88 09:04:57 EST
Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 123312; Wed 17-Feb-88 09:03:48 EST
Date: Wed, 17 Feb 88 09:03 EST
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Subject: Standardization meeting on March 26
To: hal@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8802162235.AA11693@murren>
Message-ID: <880217090332.1.RHH@ASPEN.LCS.MIT.EDU>
This will be a 1-day meeting to discuss standardization.
I don't feel I have much to contribute to the process, nor do I have any
very strong feelings pro or con on the standardization issue; on the
other hand, it would be rewarding to have the opportunity to get
together with the RRRS authors again; on the other hand, there are
other things to be done and there are only so many days in a week.
Therefore,
A. Will you come if the meeting is at Indiana?
No, I don't think I can swing that.
B. Will you come if the meeting is at MIT?
This is a possibility, if I'm not too snowed under with other things.
C. Given a choice, would you prefer to meet at MIT or at Indiana?
I think the players more central to this issue should make this decision
based on their constraints, so I abstain from this decision. -Bert Halstead
∂17-Feb-88 0904 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 09:04:11 PST
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 17 Feb 88 12:03:35 EST
Date: Wed 17 Feb 88 12:00:40-EST
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Named-let
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12375479760.30.MKATZ@A.ISI.EDU>
I apologize for my oversight on named-let. Apparently, just references
to named-lambda were removed and named-let was moved from the let section of
RRRS to a location where I failed to find it.
Morry Katz
-------
∂17-Feb-88 1031 @MC.LCS.MIT.EDU,@RELAY.CS.NET:brooks@mips.csc.ti.com standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 10:31:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Feb 88 13:31:26 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa13759; 17 Feb 88 12:47 EST
Received: from csc.ti.com by RELAY.CS.NET id ap08439; 17 Feb 88 12:35 EST
Received: from mips by tilde id AA22231; Wed, 17 Feb 88 10:33:23 CST
Received: by mips id AA15838; Wed, 17 Feb 88 10:33:19 CST
Date: Wed, 17 Feb 88 10:33:19 CST
From: Gary Brooks <brooks%mips.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802171633.AA15838@mips>
To: rrrs-authors@mc.lcs.mit.edu
Cc: HAL@mc.lcs.mit.edu
Subject: standardization meeting March 26
Both Indiana and MIT are fine with me. As we decided at the last RRRS
meeting, I think we should meet in Bloomington.
-- brooks
∂17-Feb-88 1044 @MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 10:44:16 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Feb 88 13:35:22 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa13779; 17 Feb 88 12:48 EST
Received: from csc.ti.com by RELAY.CS.NET id aq08439; 17 Feb 88 12:35 EST
Received: from home by tilde id AA21514; Wed, 17 Feb 88 10:10:36 CST
Received: by home id AA23991; Wed, 17 Feb 88 10:00:07 CST
Date: Wed, 17 Feb 88 10:00:07 CST
From: David Bartley <bartley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802171600.AA23991@home>
To: HAL@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 19:14:08 EST <327556.880216.HAL@AI.AI.MIT.EDU>
Subject: standardization meeting March 26
A. Will you come if the meeting is at Indiana?
Yes.
B. Will you come if the meeting is at MIT?
Yes.
C. Given a choice, would you prefer to meet at MIT or at Indiana?
No preference.
-- Hal
--db--
∂17-Feb-88 1103 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:03:24 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Feb 88 13:51:51 EST
Date: Wed, 17 Feb 88 13:51:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: standardization meeting March 26
To: HAL@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 16 Feb 88 19:14:08 EST from Hal Abelson <HAL at AI.AI.MIT.EDU>
Message-ID: <327974.880217.JAR@AI.AI.MIT.EDU>
Date: Tue, 16 Feb 88 19:14:08 EST
From: Hal Abelson <HAL at AI.AI.MIT.EDU>
A. Will you come if the meeting is at Indiana?
Probably not.
B. Will you come if the meeting is at MIT?
Probably.
Not that I have anything against Indiana (I'm a midwesterner myself),
but the standardization issue isn't important enough to me one way or
another for me to go much out of my way for it; I'm confident that
someone else out there will express my views if I don't.
∂17-Feb-88 1806 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 88 18:06:02 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 Feb 88 21:06:18 EST
Received: by iuvax.cs.indiana.edu; id AA15956; Wed, 17 Feb 88 21:05:48 EST
Date: Wed, 17 Feb 88 21:05:48 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8802180205.AA15956@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: standardization meeting March 26
A. Will you come if the meeting is at Indiana?
Yes.
B. Will you come if the meeting is at MIT?
I'm not sure yet.
--- if you answer yes to either of the above then ---
C. Given a choice, would you prefer to meet at MIT or at Indiana?
Indiana.
Kent
∂18-Feb-88 0025 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for a 3B15/3B2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 00:25:15 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 18 Feb 88 03:22:25 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA12742; Thu, 18 Feb 88 00:09:50 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 17 Feb 88 18:22:08 GMT
From: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu (Stephen Corbesero)
Organization: CSEE Dept., Lehigh University
Subject: Scheme for a 3B15/3B2
Message-Id: <308@lehi3b15.CSEE.Lehigh.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I recently tried compiling the Scheme that comes with GnuEmacs on a
3B15, but ran into some run-time problems. If anyone has already
ported scheme to a member of the 3Bx (x>1) family, could you please
send me any pertinent info. please use E-mail as I am not a regular
reader of this list.
∂18-Feb-88 0057 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Standardization meeting on March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 00:56:55 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Feb 88 03:46:43 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa05707; 18 Feb 88 3:29 EST
Received: from brandeis by csnet-relay.csnet id ab13761; 18 Feb 88 3:21 EST
Received: by brandeis.ARPA (5.51/4.7)
id AA23825; Wed, 17 Feb 88 20:37:47 EST
Received: by mephi.earth1.com (3.2/SMI-3.2)
id AA01306; Wed, 17 Feb 88 20:36:25 PST
Date: Wed, 17 Feb 88 20:36:25 PST
From: James Miller <jmiller%mephi%brandeis.csnet@RELAY.CS.NET>
Message-Id: <8802180436.AA01306@mephi.earth1.com>
To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET
In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren>
Subject: Standardization meeting on March 26
I can attend only if the meeting is at MIT. I would attend there.
--Jim
∂18-Feb-88 0119 @MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 01:19:43 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Feb 88 04:20:11 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa05903; 18 Feb 88 3:51 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ag13818; 18 Feb 88 3:40 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA08019; Wed, 17 Feb 88 14:33:48 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA14162; Wed, 17 Feb 88 14:34:16 PST
Date: Wed, 17 Feb 88 14:34:16 PST
From: Norman Adams <adams%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET>
Message-Id: <8802172234.AA14162@tekchips.CRL.TEK.COM>
Subject: standardization meeting March 26
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: David Bartley <bartley%home.csc.ti.com@relay.cs.net>, Wed, 17 Feb 88 10:00:07 CST
A. Will you come if the meeting is at Indiana?
B. Will you come if the meeting is at MIT?
My attendance is equally likely (say about 60%) at either location.
C. Given a choice, would you prefer to meet at MIT or at Indiana?
If choosing a place to spend a weekend away from home next month, I would
prefer Boston to Bloomington.
-Norman
-------
∂18-Feb-88 0742 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu standardization meeting March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 07:42:28 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 10:42:42 EST
Received: by iuvax.cs.indiana.edu; id AA05198; Thu, 18 Feb 88 08:41:45 EST
Date: Thu, 18 Feb 88 08:41:45 EST
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
Message-Id: <8802181341.AA05198@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization meeting March 26
A. Will you come if the meeting is at Indiana?
Yes.
B. Will you come if the meeting is at MIT?
Yes.
C. Given a choice, would you prefer to meet at MIT or at Indiana?
Bloomington.
Dan
∂18-Feb-88 0756 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 07:54:09 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 10:52:29 EST
Received: by iuvax.cs.indiana.edu; id AA14812; Thu, 18 Feb 88 10:51:54 EST
Date: Thu, 18 Feb 88 10:51:54 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
Message-Id: <8802181551.AA14812@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization meeting
Cc: hieb@iuvax.cs.indiana.edu
In response to Hal's survey:
A: IU: yes
B: MIT: no, unless I receive unexpected funding
C: choice: IU
Bob Hieb
∂18-Feb-88 1055 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standardization meeting vote
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 10:55:07 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 18 Feb 88 13:52:16 EST
Received: by iuvax.cs.indiana.edu; id AA24978; Thu, 18 Feb 88 13:51:46 EST
Date: Thu, 18 Feb 88 13:51:46 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Message-Id: <8802181851.AA24978@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Cc: dyb@iuvax.cs.indiana.edu
Subject: Scheme standardization meeting vote
A. yes
B. yes
C. Indiana
∂18-Feb-88 1207 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Common Lisp functions for Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 12:07:10 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 18 Feb 88 14:50:08 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 FEB 88 11:00:06 PST
Date: 18 Feb 88 10:59 PST
From: Fischer.pa@Xerox.COM
Subject: Common Lisp functions for Scheme?
To: scheme@mc.lcs.mit.edu
Reply-to: Fischer.pa@Xerox.COM
Message-ID: <880218-110006-7381@Xerox>
I'm porting a Common Lisp application to Scheme (to be run on a Mac). In so
doing I've started to implement some Common Lisp semantics, notably its lambda
argument types. Anyone done this already? (I can't affored Allegro CL).
Also, is there any way to do the equivalent of macroexpand-1 in Scheme?
(ron)
∂19-Feb-88 0416 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Standardization meeting on March 26 and teleconferencing
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 04:15:51 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Feb 88 07:16:10 EST
From: ramsdell%linus@mitre-bedford.ARPA
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA29469; Fri, 19 Feb 88 07:14:47 EST
Posted-Date: Fri, 19 Feb 88 07:13:27 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA00841; Fri, 19 Feb 88 07:13:27 EST
Date: Fri, 19 Feb 88 07:13:27 EST
Message-Id: <8802191213.AA00841@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Tue, 16 Feb 88 17:35:36 est <8802162235.AA11693@murren>
Subject: Standardization meeting on March 26 and teleconferencing
A. I will try to make it to Indiana, but I just don't know yet.
B. I will come to a meeting at MIT.
C. MIT is preferable.
Maybe this is an issue we could decide using teleconferencing. Would
someone at both MIT and Indiana find out if a teleconference is an
option?
John
∂19-Feb-88 1431 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Common Lisp functions for Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:30:36 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Feb 88 17:25:55 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA28077; Fri, 19 Feb 88 13:52:11 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Feb 88 19:04:39 GMT
From: ah4h+@andrew.cmu.edu (Andrew Hudson)
Organization: Carnegie Mellon University
Subject: Re: Common Lisp functions for Scheme?
Message-Id: <UW78f6y00jWTykM11e@andrew.cmu.edu>
References: <880218-110006-7381@Xerox>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
excerpted message follows:
I'm porting a Common Lisp application to Scheme (to be run on a Mac). In so
doing I've started to implement some Common Lisp semantics, notably its lambda
argument types. Anyone done this already? (I can't affored Allegro CL).
I understand that BBN as part of the Butterfly project implemented some form
of CommonLISP in Scheme. Any takers on this, BBN?
- Andrew Hudson
∂20-Feb-88 0053 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp Innards Wanted!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 88 00:53:34 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Feb 88 03:50:19 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA09863; Sat, 20 Feb 88 00:18:18 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Feb 88 05:46:00 GMT
From: shebs@cs.utah.edu (Stanley Shebs)
Organization: PASS Research Group
Subject: Lisp Innards Wanted!
Message-Id: <5274@utah-cs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
As part of my dissertation, I've been collecting info on the internal data
representations of various Lisp systems. Lisp here is broadly defined as
any language ultimately based on Lisp 1.5, and includes Scheme. What I'm
looking for is the grungiest of machine-level details on the layout of cons
cells, type discrimination schemes, memory organization, and storage recovery.
Moon's description of the Symbolics architecture in the January 87 Computer is
an excellent example, especially the pictures. Not every single detail is
needed; just those that required conscious decisions by an implementor. (For
instance, if arrays are tagged with a 0 to avoid masking, that is interesting,
but if it was only because "array" is the first type name in the dictionary,
that is not interesting.) Implementations embedded in other Lisps (Scheme 84,
PCLS) are not of interest, but this does not exclude those written in other
high-level languages (as can be seen from the list below).
At present I have reasonably complete descriptions of the following systems,
mostly derived from published material, manuals, or source code:
7090 Lisp 1.5
M-460 Lisp
Q-32 Lisp
Lisp 1.6
UCI Lisp
MacLISP (PDP-10)
Interlisp (VAX, PDP-10)
LISP-11
Cambridge LISP (IBM)
Zetalisp
Franz Lisp
PSL
NIL
Spice Lisp
S-1 Lisp
Franz Extended Common Lisp
T
MIT Scheme
PC Scheme
XLISP
VT-LISP
Kyoto Common Lisp
On the other hand, I have only sketchy or no data on the following systems:
PDP-1 Lisp
PDP-6 Lisp
MacLISP (Multics)
muLisp
TLC-Lisp
Prime Lisp
Lisp F3
Lisp/370
Lisp/VM
Cambridge Lisp (ST)
Interlisp-D
Apollo Domain Lisp (the PSL deriv)
Rutgers Lisp-20
Rutgers DEC-20 Common Lisp
Golden Common Lisp
HP Common Lisp
VAXLisp
Pyramid Common Lisp
Lucid Lisp
There are certainly others I've forgotten or simply don't know about - any
info on these is quite welcome! Long-ago implementations are just as worth
knowing about as more recent ones.
Details received will go into my dissertation, and possibly into a separate
tech report; any contributor who wants one will get a copy when this work is
completed, perhaps in three months or so. The dissertation itself is about
Lisp data structure design in general, and how it might be formalized.
Of course, all contributions will be properly credited, not to mention
greatly appreciated!
stan shebs
shebs@cs.utah.edu
uunet!utah-cs!shebs
∂21-Feb-88 1021 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting -- vote early, vote often
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 88 10:21:24 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 21 Feb 88 13:22:17 EST
Received: from murren (murren.ai.mit.edu) by KLEPH.AI.MIT.EDU; Sun, 21 Feb 88 13:22:54 est
Received: by MURREN.AI.MIT.EDU; Sun, 21 Feb 88 13:26:57 est
Date: Sun, 21 Feb 88 13:26:57 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802211826.AA15904@murren>
To: rrrs-authors%mc@KLEPH.AI.MIT.EDU
Subject: standardization meeting -- vote early, vote often
Reply-To: hal@ai.ai.mit.edu
The following people (listed as authors on the published version of
RRRS) have not indicated their preference as to the meeting on March
26:
Kohlbecker Oxley Wand Pitman
Please let us know:
Will you come if the meeting will be at IU?
Will you come if the meeting will be at MIT?
Given a choice, would you prefer to meet at IU or at MIT ?
-- Hal
∂21-Feb-88 1124 @MC.LCS.MIT.EDU:rabin.pa@Xerox.COM Re: Lisp Innards Wanted!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 88 11:24:48 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 21 Feb 88 14:22:38 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 21 FEB 88 11:21:01 PST
Date: 21 Feb 88 11:20 PST
From: rabin.pa@Xerox.COM
Subject: Re: Lisp Innards Wanted!
In-reply-to: shebs@cs.utah.edu (Stanley Shebs)'s message of 20 Feb 88 05:46:00
GMT
To: shebs@cs.utah.edu
cc: scheme@mc.lcs.mit.edu
Message-ID: <880221-112101-10931@Xerox>
Some details on Lucid Lisp are given in papers in the 1986 Lisp and Functional
Programming Conference proceedings. The bignum implementation has a paper of
its own. I also recall an article on a RISC implementation in a recent (last
year and a half) IEEE Computer or Software.
Dan Rabin
∂22-Feb-88 1008 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU nonorthogonality among list/vector/string procedures
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 10:07:14 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Feb 88 13:08:02 EST
Date: Mon, 22 Feb 88 13:08:20 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: nonorthogonality among list/vector/string procedures
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <330081.880222.JAR@AI.AI.MIT.EDU>
The answer to the below question is that we made no attempt to make the
set of available sequence manipulation procedures uniform accross the
various sequence types. But this doesn't mean we shouldn't consider
making things more uniform, either by adding or removing procedures;
doing so would make the language easier to learn.
-Jonathan
Date: Sun, 21 Feb 88 23:15:45 est
From: Michael R. Blair <ziggy at VX.LCS.MIT.EDU>
To: jar
Re: More RRRS questions
Why are the following missing?
VECTOR-COPY
LIST-COPY
LIST-FILL!
LIST-SET!
(MAKE-LIST k)
~Ziggy
∂22-Feb-88 1756 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for Amiga
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 88 17:56:34 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Feb 88 20:53:44 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA05882; Mon, 22 Feb 88 17:30:20 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Feb 88 19:38:07 GMT
From: rlcarr@athena.mit.edu (Richard L. Carreiro)
Organization: Massachusetts Institute of Technology
Subject: Scheme for Amiga
Message-Id: <3088@bloom-beacon.MIT.EDU>
References: <2608@gryphon.CTS.COM>, <1771@phoenix.Princeton.EDU>, <3086@bloom-beacon.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anyone have, or know where to get, Scheme for the Amiga computer?
Please EMAIL or post to comp.sys.amiga.
Thanks in advance,
******************************************************************************
* Richard L. Carreiro GO CELTS! * "He gets it out deep and *
* rlcarr@athena.mit.edu * HAVLICEK STEALS IT!!" - J. Most *
******************************************************************************
∂23-Feb-88 0726 @MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM Lisp representation data.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 07:26:42 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 23 Feb 88 10:24:38 EST
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349234; Tue 23-Feb-88 10:19:54 EST
Received: by scrc-pegasus id AA09162; Tue, 23 Feb 88 10:00:52 est
Date: Tue, 23 Feb 88 10:00:52 est
From: Bernard S. Greenberg <bsg@scrc-pegasus>
To: shebs%cs.utah.edu@stony
Subject: Lisp representation data.
Cc: ed@stony, greenwald@stony, scheme%mc.lcs.mit.edu@stony, sgr@stony
Date: 20 Feb 88 05:46:00 GMT
From: shebs@cs.utah.edu (Stanley Shebs)
Organization: PASS Research Group
Subject: Lisp Innards Wanted!
Message-Id: <5274@utah-cs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
As part of my dissertation, I've been collecting info on the internal data
representations of various Lisp systems. Lisp here is broadly defined as
It has become profoundly difficult for me to edit and send computer mail.
If you (BSG@SYMBOLICS.COM) send me a paper address, I will send you all
the relevant representation data on Multics MacLisp, may its memory rest
in peace.
∂23-Feb-88 0803 @MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM As I was saying (superseding letter)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 08:03:21 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 23 Feb 88 10:24:51 EST
Received: from PEGASUS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349236; Tue 23-Feb-88 10:20:19 EST
Received: by scrc-pegasus id AA09170; Tue, 23 Feb 88 10:02:07 est
Date: Tue, 23 Feb 88 10:02:07 est
From: Bernard S. Greenberg <bsg@scrc-pegasus>
To: shebs%cs.utah.edu@stony
Subject: As I was saying (superseding letter)
Cc: ed@stony, greenwald@stony, scheme%mc.lcs.mit.edu@stony, sgr@stony
Date: 20 Feb 88 05:46:00 GMT
From: shebs@cs.utah.edu (Stanley Shebs)
Organization: PASS Research Group
Subject: Lisp Innards Wanted!
Message-Id: <5274@utah-cs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
As part of my dissertation, I've been collecting info on the internal data
representations of various Lisp systems. Lisp here is broadly defined as
It has become profoundly difficult for me to edit and send computer mail.
If you send me (BSG@SYMBOLICS.COM) a paper address, I will send you all
the relevant representation data on Multics MacLisp, may its memory rest
in peace.
∂23-Feb-88 1115 @MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu comments on recent remarks
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:15:29 PST
Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 14:16:11 EST
Received: by ee.ecn.purdue.edu (5.54/1.12jrs)
id AA20244; Tue, 23 Feb 88 14:14:01 EST
Message-Id: <8802231914.AA20244@ee.ecn.purdue.edu>
Date: Tue, 23 Feb 88 14:13:49 EST
From: Chris Haynes <iuvax!chaynes@ee.ecn.purdue.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on recent remarks
Hal concisely summarized the reasons I feel a standard is probably desirable.
... serious concerns have been raised about (1) some other group
standardizing something called "Scheme" (2) Scheme getting overshadowed by
Common Lisp (3) Scheme not being viewed as a "real language". So I think
it is worthwhile to see if we can go the standards route without blowing
it. ...
I expect that as Scheme becomes more widely used, there will be
increasing pressure to standardize it. And I am sure that as time
goes on, it will be increasingly difficult to standardize it in "the
right spirit."
My original attempt at making the later point was criticized, with some
justification, for sounding elitist. That was never my intent.
Mitch clarified it nicely:
As Scheme matures and its user community grows, it is no longer
controlled by a group of 2 or 5 or 18 or 31. We (meaning the members
of any of these sets) can no longer control or direct the growth of
the language; such direction must be shared with other as yet unknown
persons or institutions which may or may not share the intellectual
goals of the original group.
Hal continued:
"Blowing it" means setting up a situation where people feel that they
have to agree about large chunks of Scheme before they can work on
Scheme. That turns Scheme design into a political process rather than
an intellectual one. It also, unfortunately, is often the express
purpose of creating a standard.
You don't need a large standardized chunk of a language to do
teaching and research, which are still the main applications of
Scheme. These applications generally do not require a large
language, and because portability is not essential it need not be
completely standard. Political pressures of this sort become intense
when the language is being used for large commercial applications,
for which a significantly larger standardized chunk is often needed.
Part of my concern is that in a few years industrial applications of
Scheme will become important and standardization will then become
more political. Thus I think it will be possible for us to avoid
blowing it in this way if we proceed now, and much more difficult if
we delay several years.
In general I would like to see a VERY conservative and VERY
minimal standard.
I agree completely. I also like Hal's "manifesto".
From: ramsdell%linus@MITRE-BEDFORD.ARPA
Subject: Standardization (A conservative approach)
...
My view is that informal Scheme design meetings, such as the Scheme
workshop of June 1987, are the places to talk about evolutionary changes
to Scheme.
I agree.
Are those meetings going to be replaced by formal
standards meetings,
I sincerely hope not.
or are the standards meetings going to only codify
the time tested ideas that originated in workshops and other
locations?
John
Yes, that is the proper role of standardization (with emphasis on
"time tested").
From: Hal Abelson <hal@zohar.ai.mit.edu>
Subject: call for standardization meeting
...
My bias is that if we do decide to go ahead with a standard, then the
standard itself should be essentially identical to the next version of
R*S. (But I would like to hear from people who have contrary
opinions.)
I could live with this if the standards organizations would tolerate
it (which is questionable), but I'd rather give the working group
(and the report group) somewhat more scope. This scope should not be
license to add things to the language, but rather to change style and
perhaps remove doubtful features until we have had more confident of
them. For example, I'm glad the Reports include a formal semantics,
but its appropriateness for a standard is debatable; and I'd rather
we didn't allow improper formal parameter lists until Dybvig and
Heeb's optional argument proposal is seriously considered.
-- Chris
∂23-Feb-88 1142 @MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu standardization mtg agenda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:42:21 PST
Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 14:43:14 EST
Received: by ee.ecn.purdue.edu (5.54/1.12jrs)
id AA20183; Tue, 23 Feb 88 14:11:48 EST
Message-Id: <8802231911.AA20183@ee.ecn.purdue.edu>
Date: Tue, 23 Feb 88 14:11:38 EST
From: Chris Haynes <iuvax!chaynes@ee.ecn.purdue.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization mtg agenda
The following is offered as a tentative agenda for the proposed March
standardization meeting:
1) Presentation on standardization organizations and procedures
(IEEE, X3, ...).
2) Discussion of when should Scheme standardization begin.
I say when, not whether, because I believe it is inevitable sooner
or later, for better or for worse. If there are cogent arguments
for delaying a couple of years or so, we should here them.]
3) Discussion of which official standardization organization would be best
serve our purposes.
This discussion can't really be separated from 2); for example,
I suspect IEEE standardization would be a good thing, but doubt
we should proceed if that is ruled out.
4) Develop a charter for the standardization working group.
I suspect we should keep this group separate from the R*S author's group.
(To avoid confusion, I suggest we call the former the "working
group" and the later the "report group".) Clearly the working and
report group memberships should have a large intersection, and
their meetings might whenever possible be held back-to-back in
the interest of those participating in both. The purpose of the
charter is to clarify the respective roles of the two groups. For
example, we could agree that no language feature be in the standard
that is not in the report, but allow the documents to differ
somewhat in style and allow the reports to include experimental
features. I see the present report as somewhere in between these
two documents (some features might be left out in the standard and
some less tried features might be added to the report).
5) Choose officers (Chair, Vice Chair, others if necessary) for the
Working Group.
The umbrella standards organization actually appoints the officers
(at least in the IEEE), but presumably they will accept our suggestions.
6) Discuss location, time and agenda of first working group meeting.
This might be at the L&FP conference, or we might prefer to devote
all the available time there to the report group meeting.
6) Discussion of the next report group agenda.
6) and 7) will be included only as time allows after the above items
have been given adequate consideration.
7) Discuss possible changes to the R3RS for the standard.
This is clearly beginning the work of the working group, and should only
be undertaken if their is time (unlikely) or some item is thought
to be important enough that it will influence the decisions above.
I would rather discuss things to leave out of the standard (there
are several possibilities I can think of) instead of discussing
possible additions (which are more the business of the report group).
8) Final consensus on points 2)-5) above.
Since the points for discussion above are tightly interwoven, we
should probably conclude with a final motion for consensus.
(I hope voting is not necessary, and if it is a "clear majority",
not a simple majority, should be in favor of whatever action
we resolve on.)
-- Chris
∂23-Feb-88 1233 @MC.LCS.MIT.EDU:iuvax!duba@ee.ecn.purdue.edu standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 12:32:52 PST
Received: from ee.ecn.purdue.edu (TCP 20013500417) by MC.LCS.MIT.EDU 23 Feb 88 15:33:22 EST
Received: by ee.ecn.purdue.edu (5.54/1.12jrs)
id AA23645; Tue, 23 Feb 88 15:31:21 EST
Message-Id: <8802232031.AA23645@ee.ecn.purdue.edu>
Date: Tue, 23 Feb 88 15:30:12 EST
From: Bruce F. Duba <iuvax!duba@ee.ecn.purdue.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization meeting
A: (IU) yes
B: (MIT) no
C: definitely IU
∂23-Feb-88 1837 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Scheme as an introductory programming language
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 88 18:37:08 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 Feb 88 19:34:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa13913; 23 Feb 88 13:29 EST
Received: from ubc by RELAY.CS.NET id ac05109; 23 Feb 88 13:18 EST
Received: by ean.ubc.ca id AA26188; Tue, 23 Feb 88 10:04:52 pst
Date: 23 Feb 88 10:03 -0800
From: Vincent Manis <manis%instr.camosun.bcc.cdn%ean.ubc.ca@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <488*manis@instr.camosun.bcc.cdn>
Subject: Scheme as an introductory programming language
I'd like to get some information on the experiences of people who have
used Scheme as the programming language for introductory, first-year,
courses in Computer Science (at, e.g., the ACM CS-1/CS-2 level). I'm
particularly interested in building a list of institutions which offer
introductory programming courses using Scheme, but I'm also interested
in textbooks and other resources they use, or any other information
which might be available. Experience with in-class use of the various
Scheme implementations which are generally available would also be
helpful. If you looked at Scheme and then decided on Pascal or
something instead, I'd be interested in your rationale, too.
I'm well aware of Abelson and Sussman (with Sussman), as well as
the Friedman and Dybvig books. I've also used PC Scheme extensively and
MacScheme a little bit.
I'm less interested in other Lisp dialects than Scheme (though T would
certainly be of great interest).
I will of course post a summary of the replies.
AtDhVaAnNkCxE
Vincent Manis manis@instr.camosun.bcc.cdn
The Invisible City of Kitezh ihnp4 |
Camosun College seismo |!ubc-vision!instr.camosun.bcc.cdn!manis
3100 Foul Bay Road uw-beaver|
Victoria, BC V8P 4X8 manis%instr.camosun.bcc.cdn@ubc.csnet
(604) 592-1281 x480 manis%instr.camosun.bcc.cdn%ubc.csnet@relay.cs.net
∂24-Feb-88 1722 @MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com Standardization Mtg
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 17:21:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Feb 88 20:21:10 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa10317; 24 Feb 88 18:50 EST
Received: from csc.ti.com by RELAY.CS.NET id ao16956; 24 Feb 88 18:40 EST
Received: from home by tilde id AA00575; Wed, 24 Feb 88 17:11:02 CST
Received: by home id AA15961; Wed, 24 Feb 88 17:09:54 CST
Date: Wed, 24 Feb 88 17:09:54 CST
From: Don Oxley <oxley%home.csc.ti.com@RELAY.CS.NET>
Message-Id: <8802242309.AA15961@home>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Standardization Mtg
Sorry for the delay in responding. I'm not yet sure that I will
attend. This is a combination of personal conflicts, the (non)need for
additional representatives from TI, and confidence that my viewpoints
are already well represented by many others. If things work out, I
would like to come.
Either MIT or IU is fine. I have a slight preference for IU. They
have offered to host the Scheme group a number of times now and we
have not accepted the invitation. I think we do need to move around.
(besides I get to Boston frequently anyway, I would like to go to
Bloomington!).
--Don
∂25-Feb-88 0940 @MC.LCS.MIT.EDU:kempf@Sun.COM New Address
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 09:40:19 PST
Received: from Sun.COM (TCP 1201600002) by MC.LCS.MIT.EDU 25 Feb 88 12:39:07 EST
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA05538; Thu, 25 Feb 88 09:38:38 PST
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA02868; Thu, 25 Feb 88 09:40:05 PST
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
id AA01672; Thu, 25 Feb 88 09:32:11 PST
Message-Id: <8802251732.AA01672@suntana.sun.com>
To: rrrs-authors@mc.lcs.mit.edu
Subject: New Address
Date: Thu, 25 Feb 88 09:32:09 -0800
From: kempf@Sun.COM
Apologies for sending this to the entire list, but there doesn't seem
to be an rrrs-authors-request list for adminstrative details, as is
the usual convention.
Please change my e-mail address to jkempf@sun.com from kempf@hplabs.hp.com.
Thanks.
jak
∂25-Feb-88 1140 @MC.LCS.MIT.EDU:HAILPERIN@Sushi.Stanford.EDU SICP query lang. compiler
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 11:40:14 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 25 Feb 88 14:36:37 EST
Date: Thu 25 Feb 88 11:31:10-PST
From: Max Hailperin <HAILPERIN@Sushi.Stanford.EDU>
Subject: SICP query lang. compiler
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12377604308.11.HAILPERIN@Sushi.Stanford.EDU>
I want to assign some modest amount of logic programming in a class I'm teaching
using Structure and Interpretation of Computer Programs, and was stymied by
the molasses-like quality of the query-language interpreter. So I wrote a
99% compatable query-language compiler. It is ugly, and itself slower than
it should really be, but it beats the pants off the interpreter. It runs
undre CScheme version 5.3; I suspect it would take non-trivial but doable
effort to port it to a different scheme. In case anyone else is in the
same position, I'd be happy to send other instructors the code, on a
completely and utterly as-is basis.
-------
∂25-Feb-88 1244 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU New Address
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 12:44:04 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Feb 88 15:31:31 EST
Date: Thu, 25 Feb 88 15:33:38 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: New Address
To: kempf@SUN.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 25 Feb 88 09:32:09 -0800 from kempf at Sun.COM
Message-ID: <331882.880225.JAR@AI.AI.MIT.EDU>
Date: Thu, 25 Feb 88 09:32:09 -0800
From: kempf at Sun.COM
To: rrrs-authors at mc.lcs.mit.edu
Re: New Address
Apologies for sending this to the entire list, but there doesn't seem
to be an rrrs-authors-request list for adminstrative details, as is
the usual convention. ...
I have created RRRS-AUTHORS-REQUEST@MC.LCS.MIT.EDU.
∂25-Feb-88 1710 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lisp Innards Wanted!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 17:10:42 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 25 Feb 88 20:07:09 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA08693; Thu, 25 Feb 88 16:51:10 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Feb 88 06:25:39 GMT
From: pyramid!nsc!taux01!yuval@hplabs.hp.com (Gideon Yuval)
Organization: National Semiconductor (Israel) Ltd.
Subject: Re: Lisp Innards Wanted!
Message-Id: <492@taux01.UUCP>
References: <5274@utah-cs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Berkeley&Bobrow's book "The Programming Language LISP" (MIT press, ISBN
0-262-59004-2) has the full PDP-1 LISP interpreter listings, plus some
design documents (by Deutsch&Berkeley), on pp. 326-375.
--
Gideon Yuval, +972-52-522255 (work), -2-690992 (home), yuval@taux02.nsc.com
∂25-Feb-88 2323 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme book request
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 23:22:58 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 02:13:00 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA16535; Thu, 25 Feb 88 23:00:30 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Feb 88 18:31:02 GMT
From: sdcrdcf!csun!csuna!acphssrw@burdvax.prc.unisys.com (Stephen R. Walton)
Organization: California State University, Northridge
Subject: Scheme book request
Message-Id: <1079@csuna.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I'm new to Scheme, having just acquired version 0.3 of David Betz's
XSCHEME from BIX. (He is supposedly working on a compiler for it.)
While I'm pretty well aware of the good books on Lisp, I do not know
of any books for Scheme. Recommendations are wanted. As usual,
please e-mail responses and I'll summarize to the net if warrented.
In addition to the .signature file, {hplabs|ihnp4}!csun!csuna!acphssrw
works.
Stephen Walton, representing myself swalton@solar.stanford.edu
Cal State, Northridge rckg01m@calstate.BITNET
∂26-Feb-88 0002 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Info needed on scheme research
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 00:02:29 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 02:17:23 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA16422; Thu, 25 Feb 88 22:54:27 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Feb 88 17:37:03 GMT
From: otter!ange@hplabs.hp.com (Andy Norman)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Subject: Re: Info needed on scheme research
Message-Id: <1510009@otter.hple.hp.com>
References: <1510005@otter.HP.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
ange@otter.HP.COM (Andy Norman) writes:
>If anyone knows what work is being / has been done with _Scheme_ in the
>following areas, could they please _MAIL_ me, and I will summarise to the
>net.
>Modules.
>Formal definitions of both data types and language semantics.
>Type checking.
>Frames, OOPS, Active Values and Daemons.
Here is a summary of the replies that I have received:
--------------------------------------------------------------------------------
From: Will Clinger <willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET>
Mitch Wand has done a lot of work with denotational semantics expressed
in Scheme. I've done a little -- I wrote the semantics of Scheme itself
in Scheme in order to test it. I think Mitch is now working with formal
semantics of data types, objects, and inheritance. ML would undoubtedly
be a better language for this sort of thing than Scheme, but Scheme is
more widely available and the implementations are often better.
Mitch built an ML-style type checker for use with Scheme 311. It was
buggy and crude but useful because Scheme 311 had no debugger. David
Gifford and his students are currently working on FX, which is a statically
typed language with type inference that can be thought of as a dialect of
Scheme.
TI built an object-oriented system called SCOOPS for their PC Scheme that
was used in their Personal Consultant series of expert system shells.
They made the source code available, and there is at least one independent
implementation of SCOOPS for MacScheme. The T object system came earlier,
though, and is a more elegant system. Norman Adams of Tektronix has
recently been working on a system similar to the T object system.
There's someone at Carnegie Mellon who's applying flow analysis to the
type inference problem for Scheme.
That's about it for my knowledge, but I'm sure lots of other stuff has
been done.
--------------------------------------------------------------------------------
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Uwe Pleban's MESS system for building compilers from denotational
specifications uses Scheme as well as Turbo Prolog (for the code
generator) and an ML-like language (for the semantics; the ML-like
language is implemented in Scheme).
--------------------------------------------------------------------------------
Many thanks to Will for taking the time to reply.
ange
------------------------------------------------------------------
ange%anorman@hplabs.HP.COM | Andy Norman (ange) |
ange@hplb.csnet | Hewlett-Packard Labs, --+--
ange%hplb.csnet@csnet-relay.arpa | Bristol, U.K., |
...!mcvax!ukc!hplb!ange | England. BS12 6QZ |
∂26-Feb-88 0137 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Scheme for a 3B15/3B2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 01:37:03 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 Feb 88 04:32:13 EST
Received: by kleph.AI.MIT.EDU; Fri, 26 Feb 88 04:33:15 est
Date: Fri, 26 Feb 88 04:33:15 est
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8802260933.AA05803@kleph>
To: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Stephen Corbesero's message of 17 Feb 88 18:22:08 GMT <308@lehi3b15.CSEE.Lehigh.EDU>
Subject: Scheme for a 3B15/3B2
Reply-To: cph@mc.lcs.mit.edu
Date: 17 Feb 88 18:22:08 GMT
From: vu-vlsi!lehi3b15!flash@psuvax1.cs.psu.edu (Stephen Corbesero)
I recently tried compiling the Scheme that comes with GnuEmacs on a
3B15, but ran into some run-time problems. If anyone has already
ported scheme to a member of the 3Bx (x>1) family, could you please
send me any pertinent info. please use E-mail as I am not a regular
reader of this list.
Without more information I can't help you. Unfortunately, the Scheme
distributed with Emacs is an old version. I believe that the current
version has been ported to those machines without much trouble.
∂26-Feb-88 0938 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: !
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 09:38:02 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Feb 88 12:34:27 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA26726; Fri, 26 Feb 88 07:57:40 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Feb 88 21:14:00 GMT
From: duba@iuvax.cs.indiana.edu
Organization: Indiana University CSCI, Bloomington
Subject: Re: !
Message-Id: <56700001@iuvax>
References: <880208@<323426>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
;; This is how we would write the "set!-free" make-cell in Scheme
;; extended with the F-operator and prompts (see Felleisen POPL88).
(define (make-cell)
(# (rec state
(F (lambda (set-state)
(lambda (op)
(case op
[(get) state]
[(set) set-state])))))))
;; Now with just F
(define (make-cell)
(F (lambda (return-cell)
(rec state
(F (lambda (set-state)
(return-cell
(lambda (op)
(case op
[(get) state]
[(set) set-state])))))))))
;; Of course what this code shows is that in a language with call/cc or F
;; either rec and letrec must be considered side-effects, or they must
;; be fixed so that it is not possible to find out that they are
;; implemented with side-effects.
;; Bruce Duba and Matthias Felleisen
∂26-Feb-88 1944 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting, March 26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 19:43:56 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 Feb 88 22:35:07 EST
Received: from murren (murren.ai.mit.edu) by kleph.AI.MIT.EDU; Fri, 26 Feb 88 22:36:55 est
Received: by MURREN.AI.MIT.EDU; Fri, 26 Feb 88 22:41:04 est
Date: Fri, 26 Feb 88 22:41:04 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8802270341.AA21269@murren>
To: rrrs-authors%mc@kleph.AI.MIT.EDU
Subject: standardization meeting, March 26
Reply-To: hal@ai.ai.mit.edu
The standardization meeting will take place on March 26 at Indiana
University. Stay tuned to this station for further information from
our IU hosts about specific place and times.
∂26-Feb-88 2248 @MC.LCS.MIT.EDU:mcvax!crcge3.cge.fr!adams@uunet.UU.NET SICP query lang. compiler
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 88 22:48:31 PST
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 27 Feb 88 00:53:34 EST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA19643; Sat, 27 Feb 88 00:52:37 EST
Received: by mcvax.cwi.nl; Fri, 26 Feb 88 22:05:56 +0100 (MET)
Received: by inria.inria.fr; Fri, 26 Feb 88 20:40:37 +0100 (MET)
Received: from crcge3.cge.fr (crcge3.ARPA) by crcge1.cge.fr, Fri, 26 Feb 88 19:39:05 -0100
Date: Fri, 26 Feb 88 19:38:51 -0100
Received: by crcge3.cge.fr, Fri, 26 Feb 88 19:38:51 -0100
From: mcvax!crcge3.cge.fr!adams@uunet.UU.NET (Drew Adams)
Message-Id: <8802261838.AA09716@crcge3.cge.fr>
To: HAILPERIN@sushi.stanford.edu, scheme@mc.lcs.mit.edu
Subject: SICP query lang. compiler
I would be interested in your compiler code. Thank you.
∂27-Feb-88 0710 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 07:10:36 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Feb 88 10:07:06 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA23221; Sat, 27 Feb 88 06:39:04 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 Feb 88 14:23:12 GMT
From: mcvax!diku!daimi!zapp@uunet.uu.net (Michael Hoffmann Olsen)
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Subject: SCOOPS
Message-Id: <1330@daimi.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've heard about an object oriented extension of
Scheme called SCOOPS. Does anybody know where I can
find something about it?
Michael Olsen,
Computer Science Department, Aarhus University,
Ny Munkegade - DK 8000 Aarhus C - DENMARK
E-Mail: zapp@daimi.dk
∂27-Feb-88 1707 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu xscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 17:07:34 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Feb 88 20:03:15 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA01061; Sat, 27 Feb 88 15:54:40 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 27 Feb 88 23:10:46 GMT
From: csclea!medlin@ncsuvx.ncsu.edu (Todd Medlin)
Organization: Computer Science , NCSU, Raleigh NC
Subject: xscheme
Message-Id: <1538@ncsuvx.ncsu.edu>
References: <1079@csuna.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can someone out there post some information on xscheme ?
Thanks in advance.
---todd medlin (medlin@csclea.ncsu.edu)
I'm just an undergraduate, my opinion doesn't matter.
∂28-Feb-88 0857 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET Standards
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 08:49:27 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Feb 88 11:24:26 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08163; 28 Feb 88 11:26 EST
Received: from brandeis by csnet-relay.csnet id ab11679; 28 Feb 88 11:18 EST
Received: by brandeis.ARPA (5.51/4.7)
id AA12871; Sun, 28 Feb 88 08:18:22 EST
Received: by mephi.earth1.com (3.2/SMI-3.2)
id AA04308; Sun, 28 Feb 88 08:16:48 PST
Date: Sun, 28 Feb 88 08:16:48 PST
From: James Miller <jmiller%mephi%brandeis.csnet@RELAY.CS.NET>
Message-Id: <8802281616.AA04308@mephi.earth1.com>
To: RRRS-Authors%mc.lcs.mit.edu@RELAY.CS.NET
Subject: Standards
Since I won't be able to attend the meeting, I'd like to very briefly
state my feelings on the subject:
(1) I think standardization is now unavoidable.
(2) Because of the time and expense involved in the process, I will
not be able to participate except by network message. The people who
will directly be involved in the process should decide what
organization they would prefer to deal with.
(3) The R↑nS as it stands, after fixing bugs (as in numbers) is an
excellent starting point. I feel it should be issued as an "interim
standard" if there is such a thing.
(4) Before making a final standard, however, I strongly believe that
the language must have a standard and portable mechanism for extending
the syntax (macros). Without this the ability to experiment with
language changes and exchange code based on these changes will become
quite difficult; it is already fairly severe when dealing with widely
differing implementations with which one is not intimately familiar.
It would be well worth a two year delay, if necessary, to work out a
solution to this problem that is acceptable to the entire community.
--Jim
∂28-Feb-88 1211 @MC.LCS.MIT.EDU:mhs@HT.AI.MIT.EDU Info needed on Scheme research
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 12:10:53 PST
Received: from HT.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 FEB 88 15:06:58 EST
Received: by ht.ai.mit.edu; 28 Feb 88 15:01:07 est
Date: 28 Feb 88 15:01:07 est
From: Mark Shirley <mhs@ht.ai.mit.edu>
To: scheme@mc
Subject: Info needed on Scheme research
Quoting "From: otter!ange@hplabs.hp.com (Andy Norman)"
From: Will Clinger <willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET>
======================================================================
There's someone at Carnegie Mellon who's applying flow analysis to the
type inference problem for Scheme.
Will, do you mean Olin Shivers at CMU? Or is there someone else working on
flow analysis?
In a vein similar to Andy's question, What is the state-of-the-art in
optimizing compilers for Lisp / Scheme? If people would send references to
papers, e.g. something on Orbit, I'll collect and summarize the responses.
(Apologies to everybody if this question has been asked recently. I'm new to
this list and looking through the archives available to me didn't turn up
anything.)
- Mark Shirley
∂28-Feb-88 1857 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu standardization meeting---travel and local arrangements
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 18:57:49 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 28 Feb 88 21:57:39 EST
Received: by iuvax.cs.indiana.edu; id AA02446; Sun, 28 Feb 88 21:57:41 EST
Date: Sun, 28 Feb 88 21:57:41 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8802290257.AA02446@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization meeting---travel and local arrangements
The meeting to discuss standardization will be held on Saturday March
26, 1988 in Bloomington, Indiana. We plan to begin the meeting at 9:00
AM, so you should arrive by Friday evening. We plan to adjourn no
later than 5:00 PM on Saturday; this will allow those of you planning
to depart that evening to reserve a 7:00 or later flight out of
Indianapolis.
It is usually best to travel into the Indianapolis airport, which is
about one hour and 15 minutes from Bloomington. The Louisville airport
is sometimes a reasonable alternative at two hours and 15 minutes from
Bloomington. Sometimes there are nonstop flights into Louisville even
when there are no nonstop flights into Indianapolis (especially from
the South). Bloomington has an airport; flights connect through
Chicago or Indianapolis. We rarely use the Bloomington airport since
it usually takes longer to fly into Bloomington than to fly into
Indianapolis and drive to Bloomington.
From the Indianapolis airport, there are three possibilities: (1) rent
a car, (2) take a limo, or (3) have someone pick you up. From the
Louisville airport, only the first option is reasonable. The car
rental is as cheap as if not cheaper than the limo, but I've heard that
the limo is very nice. If you are interested in taking the limo, let
me know and I'll find out how to reserve it.
We have reserved a block of rooms at the Bloomington Ramada Inn. The
price for one night at the Ramada is around $50. Let me know if you
plan to stay at the Ramada and we will sign you up. We need to know by
March 10th at the latest).
We will arrange for coffee and donuts on the morning of the 26th, and
lunch around noon. We will also set up an informal gathering on Friday
night. On Saturday night, we're planning to have a dinner party.
Please let me know as soon as possible if you will be attending. Also,
we may be able to help with travel between Indy and Bloomington if we
have enough advance notice. So please let us know your flight plans as
soon as possible. If I can be of any assistance, don't hesitate to
send mail (dyb@iuvax.cs.indiana.edu) or call (812/335-6486).
Stay tuned...
Kent
∂28-Feb-88 2236 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu looking for Cscheme on 3b1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 88 22:36:20 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Feb 88 01:09:27 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA26358; Sun, 28 Feb 88 21:33:28 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Feb 88 03:44:07 GMT
From: oxtrap!sendai!rich@umix.cc.umich.edu (K. Richard Magill)
Organization: Digital Works Ltd, Ann Arbor
Subject: looking for Cscheme on 3b1
Message-Id: <172@sendai.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Could someone who is running C-scheme on 3b1/unix-pc please get in
touch with me? What version are you running? Can/will you share your
configuration?
∂29-Feb-88 2146 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu CScheme5.0 Availability (Was: Scheme for Amiga)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 21:46:27 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Feb 88 23:09:16 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA10082; Mon, 29 Feb 88 18:11:34 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Feb 88 20:23:29 GMT
From: rlcarr@athena.mit.edu (Richard L. Carreiro)
Organization: Massachusetts Institute of Technology
Subject: CScheme5.0 Availability (Was: Scheme for Amiga)
Message-Id: <3343@bloom-beacon.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have been told that CScheme5.0 is PD and will compile *as is* on the
Amiga. The same person said it was available via anonymous FTP on several
sites, but neglected to mention any. Can someone post or email where these
sites are? Thank you.
ARPAnet: rlcarr@athena.mit.edu
UUCP : rlcarr%athena@eddie(.mit.edu)
BITNET : rlcarr%athena@mitvma(.mit.edu)
*******************************************************************************
* Richard L. Carreiro "Havlicek stole the ball!!!!" *
* rlcarr@athena.mit.edu -- Johnny Most 4/15/65 *
*******************************************************************************
∂01-Mar-88 0056 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu does c scheme support X windows?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 00:56:33 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 Mar 88 02:22:35 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA09677; Mon, 29 Feb 88 17:46:59 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Feb 88 18:54:39 GMT
From: hao!umigw!angel@AMES.ARC.NASA.GOV (angel li)
Organization: University of Miami
Subject: does c scheme support X windows?
Message-Id: <131@umigw.MIAMI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I was wondering if C-scheme has support for X Windows, version 11.
--
Angel Li
University of Miami/RSMAS
Internet: angel@miami.miami.edu UUCP: hao!umigw!angel
∂03-Mar-88 1009 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU xscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 10:08:53 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 3 Mar 88 02:48:13 EST
Received: by ZOHAR.AI.MIT.EDU; Wed, 2 Mar 88 23:20:57 est
Date: Wed, 2 Mar 88 23:20:57 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8803030420.AA03247@zohar>
To: csclea!medlin@ncsuvx.ncsu.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Todd Medlin's message of 27 Feb 88 23:10:46 GMT <1538@ncsuvx.ncsu.edu>
Subject: xscheme
You said:
I'm just an undergraduate, my opinion doesn't matter.
Why do you feel that way? You have an unhealthy self-image problem.
Your opinion does matter, at least it does to me.
∂05-Mar-88 0717 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu moderator
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Mar 88 07:17:37 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Mar 88 09:38:12 EST
Received: by iuvax.cs.indiana.edu; id AA11037; Thu, 3 Mar 88 10:04:42 EST
Date: Thu, 3 Mar 88 10:04:42 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8803031504.AA11037@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: moderator
Since Mitch will not be coming to the March 26 meeting, I suggest
that Hal take Mitch's place as moderator. I asked Hal if he would
be willing, and he said that he would.
Kent
∂06-Mar-88 0647 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: SCOOPS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 06:47:14 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 6 Mar 88 08:49:42 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA25639; Sat, 5 Mar 88 23:52:30 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Feb 88 01:58:00 GMT
From: render@b.cs.uiuc.edu
Subject: Re: SCOOPS
Message-Id: <189900005@uiucdcsb>
References: <1330@daimi.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Steve Sherin at the Univ. of Penn. has an implementation of SCOOPS. His
e-mail address is sherin@linc.cis.upenn.edu. The code is also available via
anonymous ftp.
∂07-Mar-88 1603 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Scheme as an introductory programming language
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 16:03:05 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 7 Mar 88 18:03:24 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab08835; 7 Mar 88 15:04 EST
Received: from ubc by RELAY.CS.NET id ag02903; 7 Mar 88 14:51 EST
Received: by ean.ubc.ca id AA22993; Mon, 7 Mar 88 11:38:16 pst
Date: 7 Mar 88 11:35 -0800
From: Vincent Manis <manis%instr.camosun.bcc.cdn%ean.ubc.ca@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <568*manis@instr.camosun.bcc.cdn>
Subject: Scheme as an introductory programming language
About two weeks ago, I posted a request for information on the use of
Scheme in first-year computer science courses. I've had a sense for a
while that the Pascal paradigm isn't really suitable for introductory
students (BC post-secondary institutions generally report combined
failure/attrition rates of 30-40% in these courses, higher than for most
other non-honours courses), and that Scheme might provide a better
approach.
One obvious criticism of this approach is that not all students are as
smart as MIT students. (I quite often have to deal with students who
have completed Grade 12 Algebra/Trigonometry/Calculus yet are
functioning on about a Grade 9 or 10 level. Such students find
evaluating a Pascal expression such as 3 + 4 DIV 5 * 2 a challenge.) If
in fact such poorer students found Scheme completely mystifying, then it
could immediately be ruled out. (One might have extensive arguments
about whether such students should be in a post-secondary institution at
all, but probably not in this mailing list. A propos marginal students,
one of my colleagues said to me, "I only teach to that fraction of the
students which doesn't suffer from 100% rigor mortis.")
I did *not* receive any responses of the form "We tried it, and it was
an unmitigated disaster". A few respondents had a few qualms, but
nothing which argued that the use of Scheme was *worse* than the status
quo. Obviously, one should take the responses below with a grain of
salt: if anyone had found Scheme completely unsuitable, such a person
wouldn't be terribly likely to continue reading here.
I've edited the responses, mostly in the interests of brevity. On a few
occasions, I've combined two or more separate messages from the same
person.
One note: the books referred to in the following are:
Abelson, Harold, and Gerald Sussman, with Julie Sussman.
"Structure and Interpretation of Computer Programs". MIT Press,
1985. ISBN 0-262-01077-1 (MIT Press) or 0-07-000-422-6
(McGraw-Hill).
Dybvig, R. Kent. "The Scheme Programming Language", Prentice-Hall,
1987. ISBN 0-13-791864-X.
Friedman, Daniel P., and Matthias Felleisen. "The Little LISPer (2nd
ed.)". Science Research Associates, 1986. [This is also available
in a Trade Edition from some other publisher, but I don't know the
difference between the two editions.]
If I get any followup responses, I'll post a summary.
Vincent Manis manis@instr.camosun.bcc.cdn
The Invisible City of Kitezh ihnp4 |
Camosun College seismo |!ubc-vision!instr.camosun.bcc.cdn!manis
3100 Foul Bay Road uw-beaver|
Victoria, BC V8P 4X8 manis%instr.camosun.bcc.cdn@ubc.csnet
(604) 592-1281 x480 manis%instr.camosun.bcc.cdn%ubc.csnet@relay.cs.net
------------------------------------------------------------
From: Franklyn Turbak <lyn@basel.ai.mit.edu>
------------------------------------------------------------
In addition to using the Sussman and Abelson book in the core computer
course at MIT, several instructors have prepared a number of useful
class notes. (These notes introduce new models and examples, extend
and clarify some of the main themes of the book, and introduce some
new material.) I have prepared several such handouts and hope to
combine them with other instructor's materials to form a student workbook in
the not-too-distant future (i.e. this summer).
Other notes of interest (which you may or may not know):
* There is a (very useful) Instructor's Manual available for the
Sussman and Abelson book. [This book is published by McGraw-Hill,
not MIT Press. -- vm]
* You can obtain from MIT a data base of all the problem sets
ever used for the course (eight year's worth!).
* Mike Eisenberg (duck%oz.ai.mit.edu@xx.lcs.mit.edu) is in the final stages
of preparing a new book on programming in Scheme. (It's a gentler
introduction to Scheme than Sussman and Abelson, intended primarily for
a high school audience.)
* The Center for Advanced Engineering Study (CAES) at MIT offers the
whole 6.001 course on videotape (with Gerry Sussman and Hal Abelson as
lecturers). These tapes are excellent for seeing how well the course
can be taught; however, I hear they're expensive. Call CAES
Information at (617) 253-7400 to find out more information. (In
addition to the tapes, I believe that other course materials are also
available from CAES.)
------------------------------------------------------------
From: Martin Ward <martin@EASBY.DUR.AC.uk>
------------------------------------------------------------
I was involved (in 1986) in teaching a computing option to 2nd year
mathematicians at Oxford University (they choose 8 options from ↑25 for the
second year). T was the language used because of the simple semantics, the
ability to get started quickly (using the interpreter) and the ability
to write recursive functions, data directed programs etc. and not worry
about details of syntax, arithmetic overflow etc. Since 1987 there has been
a joint honours course in maths and computing, I rhink using T.
For more up to date information try:
Bernard Sufren,
Programming Research Group
Oxford University
8-11 Keble Rd
Oxford
------------------------------------------------------------
From: Simon Kaplan <uiucdcs!kaplan.cs.uiuc.edu!kaplan@ihnp4.uucp>
------------------------------------------------------------
I'm currently well into the first iteration of teaching scheme as an intro
language here for the first time. The course is an ``experiment'', open
only to selected students. The class size is around 35 students; we get
around 300 students taking our intro course for majors each semester.
The experience of the students ranges from >10 years programming to
nothing.
The students really seem to enjoy the course, I'm loving teaching it, and
the sort of work you can cover is just amazing. In regular Pascal courses,
you spend far too much time on the language and not enough on principles;
examples tend to illustrate language constructs, not concepts. With
Scheme, all that vanishes, and we focus on the concepts. Within 2 weeks,
students are writing fairly complex recursive routines, and after a month
are working with upward and downward funargs, and learned a lot about
control abstractions. Next I plan to cover data abstractions, and then
modules, object-oriented programming, and so forth. More or less I cover
the first 2.5 chapters of A,S&S, and a significant part of a data
structures text such as Reingold and Hansen (data structures in pascal
(except i dont use pascal)). Also a fair amount on orders of evaluation
and correctness.
Why scheme? because there are a small number of orthognal constructs out
of which almost all the programming structures the students need can be
built. This allows a focus on what I think is the single most important
message to give to the students, viz. the concept of building layuers of
abstraction. In an article in this month's byte, A&S call this ``adding to
the language'' or some such and they have a good point
I am using A,S&S as the text, primarily because there is nothing else
available right now (dybvig is a reference manual and doesnt count). It
is not a good book for an intro course. It covers too much, gets too cute,
and focuses too much on numeric examples. I think that the examples in
chapter 2 are a good example of this: while they are good examples, the
average student is likely to just be bored to death by them, not seeing the
relevence of all this number crunching. And thereby miss the entire point
of the chapter. Another problem is their use of the (define (name args) ...)
form in their examples, which makes iontroducing lambda awkward. I use the
form (define name (lambda (args) ...))
I built my own notes for the course. I follow A,S&S closely in the
beginning (was more nervous then) and then branch off. The skeleton of the
course resembles A,S&S but the details are mostly mine own. Specifically i
do a lot more on non-numeric data abstraction, and object-oriented
programming. And then there's a lot of stuff on data structures and
algorithms that they dont get into.
I believe that George Springer at Indiana is workking on a book, which
should be finished soon. I'm looking forward to seeing what he has done.
To conclude: I firmly believe that a better job of introducing students to
programming can be done in scheme. Just read A,S&S to see that this is
so!!
On the software side, we use MacScheme. I highly recommend this. It's
good, reliable, easy to use. The students would find operating system +
editor + language as we usually do with unix/pascal a bit of a mouthful;
using the macs obviates this. Some students use PC-scheme (this is just
ti-scheme) and like it, but of course have to learn the edwin editor,
almost emacs, and dos, almost unix. So the mac is the route of least
resistance for the students. DONT use mit scheme or T if you can avoid it,
mostly because their debuggers are just terrible. Mit scheme gives errors
in hex. T assumes you can program continuation-style to read the debugger.
while this might be true, the freshmen will get blown away...
MacScheme has a lovely debugger, and a good compiler also.
Some personal background: I am not an AI type; I work in programming
environments. And did all my work in C/pascal till last summer. I was put
on a committee to revise the 1st year courses and read abelson & sussman as
part of that, and came away a convert.
Would I use scheme in the future? you bet! I hope the rest of the
department agrees and adopts the experimental course.
------------------------------------------------------------
From: Richard Pattis <pattis@june.cs.washington.edu>
------------------------------------------------------------
Places that I know that use Scheme are Brandies, UC Berkeley, Univ of Oregon
(at Eugene). Contact Harry Mairson at Brandeis, Mike Clancy at Berkeley, and
I don't know who at Oregon.
I think off and on about teaching Scheme (we teach Modula-2 here) and would
be interested in getting the list that you make up of other people already
teaching it.
Rich Pattis
------------------------------------------------------------
From: Joel Spolsky <spolsky@eniac.seas.upenn.edu>
------------------------------------------------------------
The U. of Pennsylvania Computer Science and Engineering curiculum teaches
Abelson and Sussman Scheme (using TI Scheme on IBM-AT's and CScheme on a
VAX) as the *second* part of the introductory programming course; the first
semester is designated "Pascal and Data Structures". They also teach some
ML in this second course.
Of course, MIT uses A&S as their *first* course.
------------------------------------------------------------
From: Stephen Robbins <Stever@waikato.s4cc.symbolics.com>
------------------------------------------------------------
I learned SCHEME at MIT in 6.001, "The Structure and Interpretation of Computer
Programs." A year later, the course notes came out in now-famous book form.
6.001 is one of the most popular courses at MIT, and seems to give people an
excellent (though sometimes grueling) introduction to CS.
Now, I work at Symbolics as an instructor. Two weeks ago, I taught my first
Common Lisp One course.
The SICP approach is one I'm very fond of: use SCHEME as a vehicle for
teaching people to \think/. That you're learning SCHEME, in particular, is
secondary.
At Symbolics, we teach students a mental model for understanding the Lisp World
before they ever sit down at a terminal. That seems to work far better than
the approach that most Lisp texts (e.g. LISP by Winston & Horn) take.
Overall: teach students how to THINK. And SCHEME is flexible enough that it
doesn't get in your way a whole lot when you try to translate thought into
program.
[Stephen goes on to compare Scheme with C and Pascal as an introductory
language. I've omitted that in the interests of space, but would be
happy to forward the details to those interested. He argues that it's
possible to teach the basics of the language in about a day. -- vm]
------------------------------------------------------------
From: Erik Talvola <laba-5ac%widow.Berkeley.EDU@violet.berkeley.edu>
------------------------------------------------------------
At UC Berkeley, the introductory CS class for EE and CS majors is CS60A -
namely, Scheme. We use Abelson & Sussman for the textbook, and MIT Scheme
running on Sun 3/50's for the language. I found it to be an interesting
approach, since, as the teacher pointed out, everyone is pretty much equal
going into the class since nobody learns Scheme/Lisp in high school.
In A&S, we covered up to the Meta-Circular Evaluator and some of the logic
programming stuff. This year, they are doing the entire logic programming
section and are doing a little on the register-machine simulator. Who
knows? Maybe next year they will cover the whole book in CS60A. To
summarize, I enjoyed the class because I was expecting a boring Pascal
class (that is what the course catalog says about 60A!) - instead, I got
a chance to use a language I had virtually no experience with (I used
Lisp a little on an Apple II - but that was it).
The CS60A class at Berkeley is intended for incoming freshman in their
first semester. Math 1A (Calculus) is listed as a prerequisite, but no
math is really necessary in the course - maybe a little knowledge of
what integration and differentiation are, but that's it.
------------------------------------------------------------
From: Dan Grim <grim@louie.udel.edu>
------------------------------------------------------------
The Electrical Engineering Department at the University of Delaware uses
Abelson & Sussman (with Sussman) to teach our first-term freshman course
in programming concepts and algorithms. We did this for the first time
last fall and have not had sufficient experience to decide whether it has
been more successful than the Pascal programming course that we taught
previously. However, from the instructors point of view (mine), I found
it much easier to concentrate on the ideas of programs and algorithms
rather than the details of programming. We used CScheme on a Pyramid
98-XE for the associated lab!
I think that the student reaction was somewhat negative which was not
unexpected. However, the good students, who would have been bored
silly by Pascal were challenged by Scheme, while the poorer students
had to work harder. We made an explicit decision to try to challenge
the good students rather than cater to the poorer ones. Much of what
is in Abelson & Sussman is quite subtle and I was surprised how many
students got it!
------------------------------------------------------------
End of summary
------------------------------------------------------------
∂07-Mar-88 2003 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Eugene Kohlbecker's net address
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 20:03:44 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Mar 88 23:00:31 EST
Date: Mon, 7 Mar 88 23:00:18 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Eugene Kohlbecker's net address
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <337749.880307.JAR@AI.AI.MIT.EDU>
According to the postmaster at uriecl, the address I have for Eugene,
namely
ihnp4!uriecl!csc2::eek@ucbvax.berkeley.edu,
is not currently working, and hasn't been working for a while. If
there's something you need to tell him (e.g. about the upcoming
meeting(s)) you should probably use phone or US mail.
Does anyone have a different, possibly working, net address for him?
∂08-Mar-88 1605 @MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 16:05:43 PST
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Mar 88 18:51:54 EST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA21270; Tue, 8 Mar 88 18:50:48 EST
Received: by mcvax.cwi.nl; Wed, 9 Mar 88 00:22:53 +0100 (MET)
Received: by diku.dk (5.51/smail2.5/ease)
id AA22694; Tue, 8 Mar 88 20:16:12 +0100
Date: Tue, 8 Mar 88 20:16:12 +0100
From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy)
Message-Id: <8803081916.AA22694@diku.dk>
To: rrrs-authors@mc.lcs.mit.edu
Subject: standardization meeting
Hi,
I won't be able to participate to the next Scheme meeting at IU,
but will attempt to come to the one around the Lisp Conference.
(Coming from Europe is a bit of a long way for one Saturday.)
Could it be possible to communicate the schedule of events
the next 26th of March, for the absent participants?
What about, in particular, voting?
Olivier
∂08-Mar-88 1624 @MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET next report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 16:24:34 PST
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Mar 88 19:12:47 EST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA21254; Tue, 8 Mar 88 18:50:37 EST
Received: by mcvax.cwi.nl; Wed, 9 Mar 88 00:23:30 +0100 (MET)
Received: by diku.dk (5.51/smail2.5/ease)
id AA22809; Tue, 8 Mar 88 20:18:15 +0100
Date: Tue, 8 Mar 88 20:18:15 +0100
From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy)
Message-Id: <8803081918.AA22809@diku.dk>
To: rrrs-authors@mc.lcs.mit.edu
Subject: next report on Scheme
The denotational specification of Scheme in the r3rs does not
address the mappings of variables (car, cdr, etc.)
to functions (car, cdr, etc.) in the initial environment,
although these functions are described.
Should this be fixed in the next report?
In particular, it would cover how variables shadow each other,
as in
((lambda (car) (car '(1 2 3))) cdr) ---> (2 3)
Also, quote is not described, and it needs some precautions
because it realizes an upward connection: it translate a syntactic
construct to a semantic object.
Finally, has someone proposed already a
call-with-current-environment
similar in spirit to call-with-current-continuation?
(1) The environment could be a function
Variable --> Value
to model the evaluation of a variable
and/or
Bound-Variable * Value ---> Unspecified
to model set!
(2) Or it could be a function
Variable --> Location
although it would introduce the concept of location,
and of accessing and updating a location.
Similarly to define a new location, at the top level or internally.
Anyway it would functionalize the environments got from THE-ENVIRONMENT
in CScheme.
Olivier
∂10-Mar-88 0550 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu search for IBM-PC (compatible) scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 05:50:27 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Mar 88 08:46:55 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA13279; Thu, 10 Mar 88 04:37:54 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 Mar 88 22:39:36 GMT
From: ola@cs.duke.edu (Owen L. Astrachan)
Organization: Duke University CS Dept.; Durham, NC
Subject: search for IBM-PC (compatible) scheme
Message-Id: <11230@duke.cs.duke.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I would appreciate pointers to any version of scheme that will run on an IBM
pc or compatible. I have heard of pc-scheme (from TI?) but don't know
anything about it. Does it work well, how much does it cost, from where is
it obtainable, etc.
Any pointers to public domain (hah hah) schemes that run on such machines
would be appreciated as well.
Please respond via e-mail, I'll summarize if requested.
Thanks.
Owen L. Astrachan CSNET: ola@duke
Dept.of Computer Science ARPA: ola@cs.duke.edu
Duke University UUCP: {ihnp4!decvax}!duke!ola
Durham NC 27706 Phone (919)684-5110 Ext. 229
∂10-Mar-88 1722 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 17:22:37 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Mar 88 20:20:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id ad14661; 10 Mar 88 19:47 EST
Received: from tektronix.tek.com by RELAY.CS.NET id dc01153; 10 Mar 88 19:38 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA10652; Thu, 10 Mar 88 14:40:39 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA26765; Thu, 10 Mar 88 14:39:27 PST
Message-Id: <8803102239.AA26765@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: willc%tekchips.crl.tek.com@RELAY.CS.NET
Subject: false
Date: 10 Mar 88 14:39:25 PST (Thu)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
I would like to request that the next revision of the Scheme
report not specify whether the empty list counts as true or
as false.
I think we all recognize that the empty list counts as false
only because Scheme came out of a Lisp tradition in which NIL
served as both the empty list and as the false value. When
we decided to distinguish #f from the empty list, we felt
that we had to make allowances for existing implementations
that confuse the two. Since such implementations could not
possibly have the empty list count as true, we made it count
as false. This was a mistake; we should have left it
unspecified, just as it was unspecified whether the empty
list was distinct from #f.
The R3RS states quite explicitly that the reason the empty
list counts as false is "for compatibility with existing
programs and implementations that assume this to be the
case". As I explain later in this message, compatibility
can be maintained without requiring that all implementations
perpetuate this mistake; we did not realize this at the time.
Existing implementations would not have to change. They
could take advantage of the underspecification to have the
empty list continue to count as false, just as many
implementations take advantage of the loophole that lets
the empty list be identical to #f.
Five or ten years from now, after we've required the empty
list to be distinct from #f, perhaps we can require that the
empty list count as true. Not now.
REASONS FOR CHANGE
If we are thinking of formal standardization, we should keep
things out of the standard that we might regret later. The
fact that the empty list counts as false falls into that
category.
Having the empty list count as false makes it harder to do
type inference, because for example you can't tell whether
a procedure that returns the empty list is supposed to return
a boolean or a list.
That is why it is considered bad style for a programmer to
write '() when returning a boolean value, because this makes
it hard for human readers to do the "type inference". The
existence of implementation modes that detect the use of the
empty list as a boolean would help programmers to develop
better style. (For example, my translations of the Gabriel
benchmarks into Scheme have many such stylistic horrors,
but it was impractical for me to track them down because
I didn't have an implementation that would catch them for
me.)
The way that the R3RS is written encourages readers to believe
that the empty list is distinct from #f. So far as I know, it
goes out of its way to allow them to be the same only in the
English description of NULL?. This shows that we expected
future implementations of Scheme to distinguish #f from the
empty list.
People learning Scheme are confused if the empty list is the
same as #f (unless their brains have already been addled by
exposure to some other dialect of Lisp). This shows that
future implementations of Scheme should distinguish #f from
the empty list.
One of the things that discourages implementors from making
the empty list distinct from #f is the fact that the empty
list counts as false. On many architectures this makes it
slower to test a boolean value (unless the implementor
biases the representations to take this problem into account,
which would probably make other operations slower). In
MacScheme, for example, testing a boolean return value
currently looks like
cmp.l #F,RESULT
beq ---
but would look like
cmp.l #NULL,RESULT
beq ---
cmp.l #F,RESULT
beq ---
if #f were different from the empty list.
So the change is useful to preserve our flexibility for the
future, for type inference/checking, to encourage good
style, and to prevent implementations that work the way we
intended and the way users expect from paying a (very small)
performance penalty.
COMPATIBILITY
Suppose I want to build an implementation in which the empty
list does not count as false. (I do.) Won't I be breaking
a lot of code?
Surprisingly not. I can provide a compiler switch that
people can use to compile their code as though the empty
list counts as false. That will keep users of old code
happy without penalizing writers of new code.
What about the procedure library? The only standard Scheme
procedure affected by the change is the NOT procedure. I
will thus have to provide two versions of NOT, one for
compatibility with old code and another for new code, and
have the compiler switch arrange to compile in an environment
which differs from the standard environment only for NOT.
Not all implementors will want to take even this minimal
trouble to support a compatibility mode, and that's fine.
All I'm asking is that Scheme let me and like-minded
implementors support a "progressive" mode in which the
empty list counts as true, and let me and like-minded users
write code using that mode.
What do you say?
BOOKS
From glancing at S&ICP and TLL, I don't think they would be
significantly affected by this. Both are written as though
(= 3 4) returns the symbol NIL, so they would be no less
accurate than before. Abelson and Sussman early define
false as NIL and true as non-NIL, and use the terms "true"
and "false" throughout the rest of the book, so there are
only a couple of pages where a teacher would have to make
a correction, and teachers have to make a correction there
even now.
William Clinger
∂10-Mar-88 1747 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 17:47:21 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 10 Mar 88 20:46:03 EST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 88 17:45:27 PST
Date: Thu, 10 Mar 88 17:44:50 PST
From: Pavel.pa@Xerox.COM
Subject: Re: false
In-reply-to: <8803102239.AA26765@tekchips.CRL.TEK.COM>
To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Cc: Plass.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880310-174527-2808@Xerox>
I very much support this change. Cedar Scheme already has false not equal to
the empty list and it would certainly make our lives easier (and our code
faster) if we didn't have to treat them as though they were the same for the
purposes of testing predicates. Since we are intending to push very hard
towards a strong typing discipline, this will also help our type inference
engine, as pointed out by Will. Since we don't have to maintain compatibility
with any old Scheme/Lisp code, we are feeling free to make our implementation
maximally strict about all of the other undefined values and effects; this makes
it possible for code that runs in Cedar Scheme to run in any other
implementation. Will's change would be a fine addition to that set of
strictnesses.
Pavel Curtis
Xerox PARC/CSL
∂11-Mar-88 0910 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 09:10:04 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:09:41 EST
Date: Fri, 11 Mar 88 12:09:07 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: false
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 10 Mar 88 14:39:25 PST (Thu) from willc%tekchips.CRL%tektronix.tek.com at RELAY.CS.NET
Message-ID: <339858.880311.JAR@AI.AI.MIT.EDU>
I support this change. However:
Date: 10 Mar 88 14:39:25 PST (Thu)
From: willc%tekchips.CRL%tektronix.tek.com at RELAY.CS.NET
One of the things that discourages implementors from making
the empty list distinct from #f is the fact that the empty
list counts as false. On many architectures this makes it
slower to test a boolean value (unless the implementor
biases the representations to take this problem into account,
which would probably make other operations slower). In
MacScheme, for example, testing a boolean return value
currently looks like
cmp.l #F,RESULT
beq ---
but would look like
cmp.l #NULL,RESULT
beq ---
cmp.l #F,RESULT
beq ---
if #f were different from the empty list.
Unless I'm overlooking some vagaries of the way byte and word
instructions work on the 680x0, then I think you can do better than
this, if you can arrange that the low N bits (for N = 8 or 16) of #f and
() are the same, and different from the low N bits of every other
object. Then the false test becomes
cmp.w #NO,RESULT ;Or cmb.b
beq ---
where NO is the distinctive false bit pattern.
On the 680x0, if RESULT is not a register, then an offset of 2 or 3 must
be added to the effective address. On the little-endian VAX the right thing
happens automatically.
"Always looking for better kludges to promote inelegance."
And another nit:
Having the empty list count as false makes it harder to do
type inference, because for example you can't tell whether
a procedure that returns the empty list is supposed to return
a boolean or a list.
If type inference is a concern, then it seems to me that accepting, say,
the symbol T as a true value is just as much of a problem as accepting
the empty list as a false one; in either case you are going to have
trouble deducing that something is a boolean. Seems to me that the only
way to make type inference work well is to not only separate () from #f,
but make it be an error to allow anything other than a boolean as the
value of a test in an IF. I suspect this position would be too radical
to be accepted by most of us, perhaps even including me.
In spite of these objections: as stated above, I support making the
trueness or falseness of () be unspecified.
∂11-Mar-88 0953 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 09:53:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:50:18 EST
Date: Fri, 11 Mar 88 12:50:11 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (SYMBOL? #t) ==> ?
To: ziggy@VX.LCS.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 10 Mar 88 14:12:19 est from Michael R. Blair <ziggy at VX.LCS.MIT.EDU>
Message-ID: <339871.880311.JAR@AI.AI.MIT.EDU>
Date: Thu, 10 Mar 88 14:12:19 est
From: Michael R. Blair <ziggy at VX.LCS.MIT.EDU>
To: jar
Re: (SYMBOL? #t) ==> ?
Chris Hanson and I noticed a possible non-ideality in the
Revised↑3 report. Specifically,
(SYMBOL? #t) ==> ?
We think it should be #f but the manual does not specify?
I'm not sure why you single out the question of disjointness of the
boolean and symbol types; the report is also mute on the question of
what (pair? 3) returns. One might infer from the formal semantics that
the types explicitly listed in the domain equation for expressed values
are disjoint, but some uncertainty is in order since
(a) the semantics of the built-in type predicates aren't given,
(b) the text says that certain deviations from the domain equations are
allowed (e.g. characters needn't be a distinct type, and () possibly=
#f); so why not others?
My interpretation is that types must be disjoint except where explcitly
stated otherwise in the text of the report. In particular:
(number? 'a) => #f
(symbol? #t) => #f
(boolean? 't) => #f
(vector? #\c) => unspecified
(boolean? '()) => unspecified
Common Lisp: The Language addresses the question of type disjointness in
a brief section devoted to that purpose. The scheme report should also
say something explicit on this topic. Before the report can say
something comprehensive, however, the rrrs-authors will have to decide
some sticky, previously unraised questions:
- Are the input-port and output-port types distinct from the others?
[My opinion: yes, as long as all implementations already do this.]
- Is the procedure type disjoint from others?
[Yes.]
- Is the type of promises disjoint from the others?
[No, it's acceptable to implement them as procedures or vectors.]
- Is the type of eof-objects disjoint from the others?
[I don't care.]
From the above it's clear that we don't really have adequate terminology
to talk about this question. I want adjectives to apply to the word
"type" to distinguish the class of types that are known to be disjoint
from each other (and thus distinguishable using type predicates: (foo?
x) = (bar? x) iff foo = bar) from the class of types that
aren't (in which case you might have a foo? predicate but no claim about
what other predicates return for things for which foo? returns true).
Suggestions? Something like "latent" and "manifest", except that those
mean something different.
Fortunately, Scheme as it stands doesn't have subtyping like Common Lisp
does (except among number types, which are already dealt with), so it
should be possible to make the discussion tighter and less confusing
than that in CLtL.
∂11-Mar-88 1014 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [cmb%DERRZE0.BITNET: Clyde Camp's PC Scheme utilities?]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:14:44 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 12:58:35 EST
Date: Fri, 11 Mar 88 12:58:28 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [cmb%DERRZE0.BITNET: Clyde Camp's PC Scheme utilities?]
To: scheme@MC.LCS.MIT.EDU
Reply-to: cmb%DERRZE0.BITNET at CUNYVM.CUNY.EDU (Clemens Beckstein, IMMD VI - Uni Erlangen)
Message-ID: <339873.880311.JAR@AI.AI.MIT.EDU>
Date: Thu, 10 Mar 88 12:24:06 MET
From: cmb%DERRZE0.BITNET at CUNYVM.CUNY.EDU (Clemens Beckstein, IMMD VI - Uni Erlangen)
To: scheme-request at mc.lcs.mit.edu
Re: Clyde Camp's PC Scheme utilities?
Who can show me a way to the latest version of Clyde Camp's utilities
for PC Scheme (TI Scheme)? The version I have (from a colleague who is
unreachable for quite some time) has compatibility problems with the new
PC Scheme V3.0 (e.g. the utility package NEWSTL.FSL because of the changed
READ-LINE function of Version 3.0 and UTILITY.FSL because of changes to
the set of MACRO handling PC Scheme functions).
I'd prefer a way via email from my BITNET account but a floppy transfer
is OK too...
- Clemens Beckstein
c/o Dept. of Comp. Science #6
University of Erlangen
Martenstr. 3
D-8520 Erlangen, W.Germany
email: cmb@derrze0.bitnet (derrze zero .bitnet)
∂11-Mar-88 1053 @MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:53:06 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 13:00:54 EST
Date: Fri, 11 Mar 88 13:00:23 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: false
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 11 Mar 88 12:09:07 EST from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <339877.880311.ALAN@AI.AI.MIT.EDU>
Let me make sure I understand the proposal.
(define (false-test) (list (eq? '() '#F) (not '())))
Currently a conforming Scheme implementation may return either (#T #T) or
(#F #T) as the value of (FALSE-TEST). The proposal is to allow
implementations in which (#F #F) is returned.
It might be argued that (#T #T) and (#F #F) should be the only legal cases,
and (#F #T) should be eliminated. But that is not the current proposal.
Correct?
∂11-Mar-88 1132 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 11:32:38 PST
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 11 Mar 88 13:17:29 EST
Date: Fri 11 Mar 88 13:15:38-EST
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: false
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12381522718.29.MKATZ@A.ISI.EDU>
I agree in principle with Will's suggestion regarding #f and the empty list;
but, I would advocate going one step farther. I believe that it is important
semantically that (null? #f) return #f and therefore whether the empty
list is equivalent to #f cannot be left unspecified. While I understand
the desire not to become gratuitously incompatible with either Commonlisp
or old revisions of Scheme, I feel that the equivalence of #f and the empty
list is a serious semantic error which should no longer be propogated. If
we were able to decide that (car '()) would no longer be required to return
'(), then I see no reason why we can't make this improvement as well.
Morry Katz
-------
∂11-Mar-88 1203 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU next report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 12:03:20 PST
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 11 Mar 88 14:50:51 EST
Received: by CHAMARTIN.AI.MIT.EDU; Fri, 11 Mar 88 14:59:02 est
Date: Fri, 11 Mar 88 14:59:02 est
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8803111959.AA23113@chamarti>
To: mcvax!diku.dk!danvy@uunet.UU.NET
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Olivier Danvy's message of Tue, 8 Mar 88 20:18:15 +0100 <8803081918.AA22809@diku.dk>
Subject: next report on Scheme
Reply-To: jinx@zurich.ai.mit.edu
Finally, has someone proposed already a
call-with-current-environment
similar in spirit to call-with-current-continuation?
(1) The environment could be a function
Variable --> Value
to model the evaluation of a variable
and/or
Bound-Variable * Value ---> Unspecified
to model set!
(2) Or it could be a function
Variable --> Location
although it would introduce the concept of location,
and of accessing and updating a location.
Similarly to define a new location, at the top level or internally.
Anyway it would functionalize the environments got from THE-ENVIRONMENT
in CScheme.
This procedure has been proposed in the past. There are a few
problems with it, some political and some technical:
1) Not all implementations support first class environments.
Furthermore, some designers/implementors abhor them. It is therefore
unlikely that consensus will be reached on anything involving them.
2) The semantics of a procedural CALL-WITH-CURRENT-ENVIRONMENT are not
clear. In particular, which environment is handed to the receiver?
Many possibilities come to mind, including the following:
1: The environment where CALL-WITH-CURRENT-ENVIRONMENT is closed.
2: The environment where the variable CALL-WITH-CURRENT-ENVIRONMENT is
evaluated.
3: The environment where the combination which results in an
application of the value of CALL-WITH-CURRENT-ENVIRONMENT is
evaluated.
4: The environment where the receiver is closed.
5: The environment where the body of the receiver will be evaluated.
None of these are really adequate:
1: Pretty useless. May as well define it as a constant.
2: It makes some variables special, hard to handle by
compiler/interpreter. Furthermore, it probably does not have the
desired effect in cases like
(define (foo) call-with-current-environment)
(let ((x 3))
((foo) (lambda (env) env)))
3: This is probably the desired semantics. It has the nice
property that THE-ENVIRONMENT can expand trivially into
((absolute call-with-current-environment) (lambda (env) env))
Unfortunately, it forbids certain kinds of EVLIST tail recursion.
4: This is pretty good. The same expansion that works in 3 above
works here too. Unfortunately it forbids certain kinds of
environment optimization. For example in,
(call-with-current-environment (generate-proc 2 3))
GENERATE-PROC must return a procedure whose format can be
understood by CALL-WITH-CURRENT-ENVIRONMENT. Since GENERATE-PROC
might be compiled out of line, this forces the compiler to avoid
environment optimization in most environments.
5: This has the same problems that 4 does and it harms incremental
definition as well: The environment obtained is most likely not
the one where the definitions are desired (the parent environment
frame is the one the user probably wants).
The real issue is that by being a special form, the correct things
"happen":
The environment where the special form is evaluated is the environment
desired, so it is certainly available when the code is executed.
A convenient syntactic marker is provided so that optimizing compilers
can discriminate at compile time between environments used in a
"first-class" way, and those which cannot be examined by the user in a
similar way (modulo debuggers, etc, which are always special). The
compiler has full freedom to implement these other environments, since
only code generated by the compiler at that time (or the debugger)
will ever need to examine them.
In order to understand my point, please consider the following
(somewhat forced) analogy:
Eliminate LAMBDA as a special form from the language in favor of a
procedural constructor:
(lambda (x y z) <code>)
becomes
(make-procedure '(x y z) '<code>)
The "bad" cases arise from things similar to
(foo '<code>)
where FOO is compiled in a separate file and is defined as
(define (foo code)
(make-procedure '(a b c) code))
or
(make-procedure (generate-arg-list) '<some code>)
∂11-Mar-88 1326 @MC.LCS.MIT.EDU:andy%hobbes@ads.com Re: (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 13:26:13 PST
Received: from ads.com (TCP 20071200430) by MC.LCS.MIT.EDU 11 Mar 88 16:18:49 EST
Received: from hobbes.ads.com by ads.com (5.58/1.9)
id AA00697; Fri, 11 Mar 88 12:35:07 PST
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
id AA00448; Fri, 11 Mar 88 12:31:28 PST
Date: Fri, 11 Mar 88 12:31:28 PST
From: andy%hobbes@ads.com (Andy Cromarty)
Message-Id: <8803112031.AA00448@hobbes.ads.arpa>
To: JAR@ai.ai.mit.edu
Subject: Re: (SYMBOL? #t) ==> ?
Cc: rrrs-authors@mc.lcs.mit.edu
I am concerned that specifying type disjointedness gets us into the
very messy business of
(a) unintentionally and unnecessarily specifying implementation details and
(b) reinforcing the distinction between system-defined and user-defined types.
For example, it should be possible for an implementor to choose to implement
vectors as tagged lists, if lists happen to be unusually efficient in this
implementation (or vice-versa). It appears to me that we do not (yet)
subscribe to the TYPEP model, in which an object "has a type," and that it
is good that we don't. Instead, we treat types as attributes of an object
-- consider (INTEGER? 3) and (NUMBER? 3) -- allowing us to recognize more
cleanly in our code that (a) an object may have several attributes and
(b) there may (or may not) be important relationships between those attributes.
This suggests that if v is a vector and p a pair, then (VECTOR? v) and
(PAIR? p) should be true, but (VECTOR? p) and (PAIR? v) should be
undefined in the Report (i.e. considered to be implementation-dependent).
If there are important counterexamples where it is necessary to know what
an object's type is, as distinct from knowing whether it satisfies the
criteria of a given equivalence class, I suggest we bring out those examples
directly for public scrutiny and discussion. (They could lead to a more
Common LISP-like type model.) My intuition is that such a change is
unnecessary and that Scheme's type model gives the software more latitude
in defining the relationships between different types, given that
[BEGIN OPINION]
the computer science community still seems to be mired in this abstract
data practice of defining types in terms of other types
[END OPINION],
and that instead we might wish to protect and capitalize on Scheme's
apparent underspecification of the types of objects and the relationships
that obtain between those type classes.
asc
p.s. I suspect this represents an argument that (if '() #t #f)
should be undefined in the Report (i.e. implementation-dependent).
Of course, good programming practice would dictate the use of NULL?
where the test-object is a (possibly-empty) list in either case.
∂11-Mar-88 1543 @MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca Paging Simon Kaplan <kaplan@kaplan.cs.uiuc.edu>
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 15:42:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Mar 88 18:37:25 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa15932; 11 Mar 88 17:28 EST
Received: from ubc by RELAY.CS.NET id aa07824; 11 Mar 88 17:18 EST
Received: by ean.ubc.ca id AA01722; Fri, 11 Mar 88 13:54:23 pst
Date: 11 Mar 88 13:54 -0800
From: Vincent Manis <manis%instr.camosun.bcc.cdn%ean.ubc.ca@RELAY.CS.NET>
To: scheme@mc.lcs.mit.edu
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <585*manis@instr.camosun.bcc.cdn>
Subject: Paging Simon Kaplan <kaplan@kaplan.cs.uiuc.edu>
[Sorry about this folks, but...]
Simon, I've tried twice to send you mail at the above address, but both
times it was rejected. Could you please send me a message with a
workable return address? -- v
∂11-Mar-88 1855 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 18:55:31 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 21:55:21 EST
Date: Fri, 11 Mar 88 21:55:03 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (SYMBOL? #t) ==> ?
To: andy%hobbes@ADS.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 11 Mar 88 12:31:28 PST from andy%hobbes at ads.com (Andy Cromarty)
Message-ID: <340276.880311.JAR@AI.AI.MIT.EDU>
Date: Fri, 11 Mar 88 12:31:28 PST
From: andy%hobbes at ads.com (Andy Cromarty)
This suggests that if v is a vector and p a pair, then (VECTOR? v) and
(PAIR? p) should be true, but (VECTOR? p) and (PAIR? v) should be
undefined in the Report (i.e. considered to be implementation-dependent).
I knew this topic would spark a lively debate.
As I understand your message, you are saying that a Scheme
implementation in which, say, ALL type predicates returned #T ALWAYS,
would be a correct one. For example, it could be the case that (symbol?
'(a b)) => #t and (pair? 'a) => #t. (I guess it would also have to have
no type errors, but that's a detail.) It seems to me that this makes
the type predicates nearly useless. In that case, they should be
eliminated from the language, making Scheme more like ML (and C and
FORTRAN and ...). Then to make up for this absence, we should have
strong typing.
I think this would break a lot of programs and annoy many users.
I am not an opponent of subtyping or of abstract data types. I
certainly don't want to promote a notion of "the type of" an object,
since an object can have many types. All I am suggesting is that we
specify some set of circumstances in which the type predicates will
return false. We all make some assumptions implicitly now; I just want
the report to codify existing practice. Language like that in CLtL
would be fine -- take a look at it, you'll notice that some things are
left unspecified -- but I would hope for something a little tighter.
∂11-Mar-88 1920 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 19:20:08 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 11 Mar 88 22:19:55 EST
Received: from Salvador.ms by ArpaGateway.ms ; 11 MAR 88 19:10:32 PST
Date: Fri, 11 Mar 88 19:10:23 PST
From: Pavel.pa@Xerox.COM
Subject: Re: (SYMBOL? #t) ==> ?
In-reply-to: <340276.880311.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880311-191032-2412@Xerox>
Mind you, I'm not sure that I like Andy's proposal, but I thought that I should
correct one of Jon's statements.
Jon says: ``As I understand your message, you are saying that a Scheme
implementation in which, say, ALL type predicates returned #T ALWAYS, would be a
correct one. For example, it could be the case that (symbol? '(a b)) => #t and
(pair? 'a) => #t. (I guess it would also have to have no type errors, but
that's a detail.) It seems to me that this makes the type predicates nearly
useless.''
The type predicates are not useless in general, their use is simply unnecessary
in *that* implementation of Scheme. They are still necessary for the writing of
portable code. Some implementations, such as Cedar Scheme so long as I'm
involved with it, would have all of the disjointness properties you could ask
for and so code written to run under it would need all of those predicates.
Michael Plass here pointed out that one benefit of allowing the various types to
share members is that a very small conforming implementation could be written in
which, for example, all of lists, vectors and strings were implemented as cons
cells (vectors and strings would, of course, use some special marker in the
first CAR). I'm not particularly impressed with this argument, but it does seem
to be valid.
Pavel
∂11-Mar-88 1943 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 19:43:09 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Mar 88 22:42:27 EST
Date: Fri, 11 Mar 88 22:41:43 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (SYMBOL? #t) ==> ?
To: Pavel.pa@XEROX.COM
cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 11 Mar 88 19:10:23 PST from Pavel.pa at Xerox.COM
Message-ID: <340292.880311.JAR@AI.AI.MIT.EDU>
Date: Fri, 11 Mar 88 19:10:23 PST
From: Pavel.pa at Xerox.COM
The type predicates are not useless in general, their use is simply
unnecessary in *that* implementation of Scheme. They are still
necessary for the writing of portable code.
I must be missing something. How could a predicate that might always
return true be at all useful in portable code?
Tell me how to write a symbolic differentiation program, or an
evaluator, that operates on the "obvious" s-expression inputs
(e.g. the list (/ 1 (sqrt (+ 1 x)))) in a world where the types number,
pair, symbol are not disjoint.
∂11-Mar-88 2006 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 20:05:58 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 11 Mar 88 23:05:25 EST
Received: from Salvador.ms by ArpaGateway.ms ; 11 MAR 88 20:03:13 PST
Date: Fri, 11 Mar 88 20:03:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: (SYMBOL? #t) ==> ?
In-reply-to: <340292.880311.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: andy%hobbes@ADS.COM, rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880311-200313-1033@Xerox>
Jon asks: ``Tell me how to write a symbolic differentiation program, or an
evaluator, that operates on the "obvious" s-expression inputs (e.g. the list (/
1 (sqrt (+ 1 x)))) in a world where the types number, pair, symbol are not
disjoint.''
Suppose that my only two disjoint types are characterized by the predicates
NULL? and PAIR?. Then I can certainly define other types by making them lists
with various internal structures and unique, particular cons cells as ``tags''
in the car of the top-level cons-cell of the value. Then my other predicates,
SYMBOL? and NUMBER?, simply check for PAIR? first and then test that the CAR is
the special cons cell for that type. Thus, in such an implementation (please,
please keep in mind that I'm not necessarily in favor of the proposal and
certainly not in favor of this implementation; my reputation is at stake
here...) we would have the following implications:
(number? x) => (pair? x)
(symbol? x) => (pair? x)
(number? x) => (not (symbol? x))
(pair? x) => (not (null? x))
and no others not deducible from these. I claim that in such a system I could
write the code you describe by simply checking number? and symbol? before
checking pair? at each point.
Note however, that while I've written (in the sense of a mathematician) the code
you requested, that code would not be portable to an implementation in which any
of the implications above were reversed. In particular, if an implementation
represented symbols and pairs in terms of numbers (never mind about how they get
the right semantics for set-car!), my code would fail because I would be testing
for things in the wrong order.
Hmm. This is a very persuasive argument against all kinds of things not being
disjoint. I think I just firmly moved into the anti-proposal camp. I think
that the issue is unrelated to questions of ``the type'' of an object and is
much more related to the question of which types I want to be able to
distinguish and treat differently. In particular, Andy proposed that one
implementation might want to represent vectors by pairs and another might want
to do the reverse. By the kind of portability argument I've just given, the
Scheme spec would have to specify that at least one of these was not legal, so
that I could figure out the proper portable order in which to test things.
However, I can see no reason to prefer one of these representation choices to
the other, so I would be forced to forbid both of them, since I certainly want
to be able to distinguish pairs and vectors.
Hmm. I guess I'm really firmly in the disjointness camp. I hope no one gets
whiplash reading this note...
Pavel
∂11-Mar-88 2208 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: (SYMBOL? #t) ==> ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 22:08:12 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 00:05:40 EST
Received: by iuvax.cs.indiana.edu; id AA19307; Fri, 11 Mar 88 23:35:42 EST
Date: Fri, 11 Mar 88 23:35:42 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8803120435.AA19307@iuvax.cs.indiana.edu>
To: JAR@mc.lcs.mit.edu, Pavel.pa@XEROX.COM
Subject: Re: (SYMBOL? #t) ==> ?
Cc: andy%hobbes@ADS.COM, rrrs-authors@mc.lcs.mit.edu
I believe there are two uses for type predicates: (1) to determine
if an object is of a given type, and (2) to determine if an object is
*not* of a given type.
(1) is useful for writing type-safe code, since it allows us to verify,
for example, that an object is a pair before calling "car". In this
case it doesn't matter whether the object happens also to be a string
or symbol, so under Andy's proposal the type predicates would still be
useful. ("doesn't matter" may be a little strong---since it would
matter if I want to be sure not to apply "car" to a string represented
as a list of characters. Therefore, "useful" may be a little strong,
at least if a predicate such as "pair?" returns true for all objects.
The point is we can still use the predicates to write "type-safe" code,
though maybe not "type-sensible" code).
(2) is useful when the type itself determines what operation we want to
perform, as with "write" and "display". It would not be friendly if a
system printed all objects as integers, as it might if they were all
considered integers by "integer?". (I already dislike that I can enter
#\a and receive 97 back.) One might argue that printing objects is for
the system to worry about, but what if I want to write a portable pretty
printer or editor? Or a generic "sequence" mapping procedure, defined
something like:
(define gmap
(lambda (proc seq)
(cond
[(list? seq) ... code for mapping over lists ...]
[(vector? seq) ... code for mapping over vectors ...]
[(string? seq) ... code for mapping over strings ...]
[else 'error])))
I'm likely to get burned if vectors are represented as tagged lists.
If a "minimal" implementation is to be built from pairs using the first
element of the list as a tag, then it should have a tag for pairs as
well as for symbols, vectors, strings, etc. In this way, it can
maintain the illusion of disjoint types, even though the underlying
structure (at one level) is the same. The "pair?", "cons", "car", and
"cdr" procedures provided to the programmer would have to take account
of the tag, of course. This is no different from a standard tagged
object typing system at the machine level.
Kent
∂11-Mar-88 2218 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 22:18:20 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 00:07:17 EST
Received: by iuvax.cs.indiana.edu; id AA20531; Sat, 12 Mar 88 00:07:30 EST
Date: Sat, 12 Mar 88 00:07:30 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8803120507.AA20531@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: false
I agree with Will that we should make the falseness of () unspecified,
if we can't do better.
But why don't we go all the way on this one, and require that () be
distinct from #f and that only #t and #f be treated as booleans in
conditional expressions? Yes, it would affect a lot of code and a few
books, but only a fraction of what is yet to be written, unless we are
are wasting our time. It is a shame we didn't do it right a long time
ago. Surely it would have been less painful three years ago than now,
and surely it will be less painful now than in another three years.
If we can't agree that it is a good idea to treat only #t and #f as
boolean values, then maybe we can agree that it is a good idea to
require that () be distinct from #f.
∂12-Mar-88 0942 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme on IBM PC
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 09:42:27 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Mar 88 12:38:55 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA10602; Sat, 12 Mar 88 09:31:03 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Mar 88 10:07:57 GMT
From: mcvax!diku!daimi!cp@uunet.uu.net (Claus Pedersen)
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Subject: Scheme on IBM PC
Message-Id: <1357@daimi.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
We are interested in Scheme for IBM PC's. Please mail references to.
Claus H. Pedersen / cp@daimi.dk (..uunet!mcvax!diku!daimi!cp)
Computer Science Department, Aarhus University
Ny Munkegade 116, DK-8000 Aarhus C, DENMARK
phone: +45 6 12 71 88 / telefax: +45 6 13 99 19 / telex: 64767 aausci dk
∂12-Mar-88 1123 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu travel plans
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 11:23:22 PST
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 12 Mar 88 14:22:46 EST
Received: by iuvax.cs.indiana.edu; id AA12351; Sat, 12 Mar 88 14:00:58 EST
Date: Sat, 12 Mar 88 14:00:58 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-Id: <8803121900.AA12351@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: travel plans
Our arpanet link was down for four days last week, from Monday to
Thursday. If anyone tried to send me mail, and it bounced, please
resend. To be safe, you might want to send mail via uucp as well as
arpanet; my arpanet address is dyb@iuvax.cs.indiana.edu and my uucp
address is dyb@iuvax.
The following people have informed me that they are coming to the
meeting from out of town: Hal Abelson, Will Clinger, Gary Brooks, Clyde
Camp, and John Ramsdell. I have also heard that Gerry Sussman and Bill
Rozas are coming. So far I have Will, Gary, and John signed up for
rooms at the Bloomington Ramada Inn. I was supposed to tell the Ramada
Inn the list of names yesterday, but they are willing to give us a few
more days. Please let me know if you plan to attend and about your
travel plans.
If you are interested in sharing a rental car with others who are
travelling to Bloomington, please let me know your flight times and
I'll try to hook you up.
More later...
∂12-Mar-88 1459 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme and C
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 14:59:19 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 12 Mar 88 17:41:53 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA15685; Sat, 12 Mar 88 14:34:05 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Mar 88 19:37:34 GMT
From: tobias@locus.ucla.edu
Organization: UCLA Computer Science Department
Subject: Scheme and C
Message-Id: <10235@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am interested in a version of Scheme that will
run on an IBM PC/AT and will allow itself either to
be called by a C program or to call a C program.
I have a copy of TI Scheme, but nowhere in the
documentation does it refer to this issue.
Plese send any information by e-mail,
or if you can't reach me, feel free to post your
answer. I will summarize any findings.
Jay Tobias
tobias@cs.ucla.edu
∂14-Mar-88 0529 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme and C
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 05:29:19 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 14 Mar 88 07:50:48 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA22196; Mon, 14 Mar 88 01:21:15 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 Mar 88 06:32:38 GMT
From: ncc!alberta!calgary!jameson@uunet.uu.net (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Re: Scheme and C
Message-Id: <1456@vaxb.calgary.UUCP>
References: <10235@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
My version of TI Scheme came with lots of documentation for calling
between Scheme, along with actual examples for ASM, Pascal, and C
files.
∂14-Mar-88 1001 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Types in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:01:09 PST
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 14 Mar 88 12:40:59 EST
Date: Mon 14 Mar 88 12:38:07-EST
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Types in Scheme
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12382302321.36.MKATZ@A.ISI.EDU>
It is with some regret and with anticipation of a barrage of heated replies
that I make the following statements.
If the goals of our type predicates are to enable the writing of portable code
and to make the writing of some other forms of code easier, then I believe that
we really need two sets of type predicates: one based on the functionlity
intended for an object and the other based on its representation. I
will prefix the predicates of the latter type with the word primitive in the
following examples for expository purposes.
(symbol? 'a) ==> #t
(number? 'a) ==> #f
(primitive-number? 'a) ==> unspecified (depends on whether this implementation
represents symbols as numbers)
Such a type system allows complete flexibility in terms of implementation while
still supporting a maximum amount of type safety. It also allows the
programmer to specify exactly what he means when he uses a type predicate.
Does he care about how the object is being used or what its actual
representation is. These a two quite different things.
Morry Katz
-------
∂14-Mar-88 1037 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU false
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:37:21 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 14 Mar 88 12:50:50 EST
Received: by ZOHAR.AI.MIT.EDU; Mon, 14 Mar 88 11:59:15 est
Date: Mon, 14 Mar 88 11:59:15 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8803141659.AA26241@zohar>
To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Cc: rrrs-authors@mc.lcs.mit.edu, willc%tekchips.crl.tek.com@RELAY.CS.NET
In-Reply-To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET's message of 10 Mar 88 14:39:25 PST (Thu) <8803102239.AA26765@tekchips.CRL.TEK.COM>
Subject: false
I agree with Will that we no longer need to specify this crock.
∂14-Mar-88 1055 @MC.LCS.MIT.EDU:daniel@mojave.stanford.edu Types in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 10:54:53 PST
Received: from mojave.stanford.edu (TCP 4402400016) by MC.LCS.MIT.EDU 14 Mar 88 13:20:57 EST
Received: by mojave.stanford.edu; Mon, 14 Mar 88 10:11:20 PST
Date: Mon, 14 Mar 88 10:11:20 PST
From: Daniel Weise <daniel@mojave.stanford.edu>
To: MKATZ@a.isi.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Types in Scheme
It is with some regret and with anticipation of a barrage of heated
replies that I make the following statements. If the goals of our
type predicates are to enable the writing of portable code and to make
the writing of some other forms of code easier, then I believe that we
really need two sets of type predicates: one based on the functionlity
intended for an object and the other based on its representation.
I agree. This is the old intensional versus extensional dichotomy,
made clear by Andy's message in which pairs could be implemented as
vectors and vice versa. The portable type predicates want to be
extensional (does this object behave as a pair?), the unportable
type predicates are intensional (is this object a pair?). We obviously
want to ask both types of questions, and it is important that we keep
their differences clear.
Daniel
∂14-Mar-88 1917 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Types in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 19:17:08 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Mar 88 22:16:43 EST
Date: Mon, 14 Mar 88 22:15:54 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Types in Scheme
To: daniel@MOJAVE.STANFORD.EDU
cc: MKATZ@A.ISI.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 14 Mar 88 10:11:20 PST from Daniel Weise <daniel at mojave.stanford.edu>
Message-ID: <341753.880314.JAR@AI.AI.MIT.EDU>
Date: Mon, 14 Mar 88 10:11:20 PST
From: Daniel Weise <daniel at mojave.stanford.edu>
... The portable type predicates want to be
extensional (does this object behave as a pair?), the unportable
type predicates are intensional (is this object a pair?). We obviously
want to ask both types of questions, ...
I'm sorry, can you tell me again why you'd want to ask the unportable
("intensional") question in portable code, or in any code, for that
matter? As someone trying to write good code, I want my program to be
as insensitive as possible to the Scheme implementor's representation
decisions -- we all know how perverse implementors can be. Thus I
should never want to use the "intensional" predicates. It seems like
this is more of an argument for eliminating the CHAR? predicate (which
doesn't seem to mean much or me, since character is an "abstract type",
at least as the report stands) than an argument in favor of introducing
a PRIMITIVE-PAIR? predicate (which would be just as useless).
Abstract types may be good for static type checking and program
verification, but I assume we're not talking about that, we're talking
about the dynamic semantics of a dynamically typed language.
The only use I can think of for predicates like CHAR? and PRIMITIVE-PAIR?
is explicit run-time type checking in user code:
(if (not (char? x))
(error "X isn't a character" ...))
This kind of thing always seems kind of fishy to me; how does one decide
when to put these checks in and when not to? The Scheme programmer
can't really do this in any case, because ERROR isn't standard...
And speaking of CHAR?: I notice that CHAR? is an essential procedure.
To be consistent with my remarks above, I would like to suggest that if
characters are to remain not necessarily distinguishable from numbers,
pairs, etc., then this procedure should be made non-essential, and that
it should be present iff the implementation has a distinct
(extensional?) character type.
∂16-Mar-88 1201 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Re: false, (symbol #t), etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:01:09 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Mar 88 16:37:05 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab04828; 15 Mar 88 15:54 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aj05874; 15 Mar 88 15:43 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA16747; Tue, 15 Mar 88 11:41:36 PST
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA28467; Tue, 15 Mar 88 11:40:13 PST
Message-Id: <8803151940.AA28467@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: willc%tekchips.crl.tek.com@RELAY.CS.NET
Subject: Re: false, (symbol #t), etc
Date: 15 Mar 88 11:40:11 PST (Tue)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Reply to Alan Bawden:
In terms of Alan's (define (false-test) (list (eq? '() '#f) (not '()))), my
proposal was to allow (#F #F) as well as (#T #T) and (#F #T).
Reply to Jonathan Rees:
I was aware of the representation trick that Jonathan pointed out, but in the
implementation I am maintaining it is more important that Scheme fixnums have
the same representation as integers and pointers used by the Macintosh Toolbox
in ROM. Such is life.
Reply to Jonathan Rees and Kent Dybvig:
Type inference is a concern, but it will always be heuristic. (You can of
course restrict to the domain of the heuristics, which is how you obtain a
statically typed language). I think I could live with #t as the only true
value, and I might like it better. Regardless, the existence of two false
values seems more random than having all but one value count as true, and
that intuition is backed up by the complexity of implementation, so the
problem of two false values seems more urgent. Furthermore people seem
more confused about #f and the empty list than about #t, so non-#t true
values seem less troublesome in practice.
Reply to Morry Katz and Kent Dybvig:
The R3RS is generally silent on disjointness because we have never agreed on
what is disjoint, mainly because we wanted to "grandfather" existing
implementations of Scheme. It would have been embarrassing to have admitted,
for example, that pairs are not required to be disjoint from numbers, so the
R3RS was deliberately written in a way that encourages readers to jump to
possibly false but reasonable conclusions about disjointness. We expected
that implementations would take the hint and change over time so that we could
be more explicit in future reports. As I recall, the main reason we failed to
specify disjointness was that several implementations needed time to fix
problems such as:
1. vectors implemented as lists
2. characters implemented as integers or strings
3. #f implemented as the empty list
These "grandfather" provisions were discussed in October 1984, and sins #2
and #3, being the most widespread, were explicitly pardoned by the RRRS and
R3RS. I think five years is plenty of warning as well as a good round number,
so I think 1989 would be a good year to add disjointness to the report.
You should suspect my timetable, though, because it's awfully convenient
that while MacScheme currently has problems #2 and #3, I expect them to be
fixed early in 1989. I think the best way to get these changes made is for
users of Scheme to complain about implementations that haven't made them.
Implementors are likely to choose the status quo unless users' complaints
about their current system are much more serious than the complaints
feared from users whose code will break if the system changes.
That's why a number of very smart people designed something like Common Lisp
(which broke everyone's code anyway). Kent is right that the cost of
delaying a needed change is greater than the cost of making it. It's like
delaying a trip to the dentist.
Reply to Morry Katz and Daniel Weise:
(Weise may have been saying this.) I see no reason why the intensional,
implementation-dependent predicates deserve recognition as part of the
language.
Reply to John Ramsdell:
As Jonathan pointed out, the R3RS clearly prohibits the behavior you
abhor. The language designers can't do much about implementation bugs.
I think I speak for all implementors when I say: Please report bugs!
(While MacScheme handles your test case ok, its COND macro still
special-cases the variable t. This was a patch installed four years ago
to ease the transition from t to #t, and I thank you for reminding me
that I forgot to take it out. No one has ever reported it. I'm
surprised I haven't run across it myself, since I often use t as a
variable.)
Peace,
William Clinger
∂16-Mar-88 1201 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU t and nil
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:00:22 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Mar 88 10:58:05 EST
Date: Tue, 15 Mar 88 10:57:29 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: t and nil
To: ramsdell%linus@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 15 Mar 88 07:22:46 EST from John D. Ramsdell <ramsdell%linus at mitre-bedford.ARPA>
Message-ID: <342005.880315.JAR@AI.AI.MIT.EDU>
Date: Tue, 15 Mar 88 07:22:46 EST
From: John D. Ramsdell <ramsdell%linus at mitre-bedford.ARPA>
On another subject, I would like to see that the variables T and NIL
not be treated specially. In particular, a user should be able to
type:
(let ((t '#f)) t) ==> #f
You can already do this, and indeed I do it often. T and NIL are
treated no differently from CAR or LENGTH, which you can also rebind.
The report doesn't mention this case explicitly because it doesn't
really need to; I think it's implied. An example to this effect should
probably be added somewhere, though, perhaps under the description of
LAMBDA.
I don't particularly care whether T and NIL remain. The fact that you
thought NIL was initially bound to () instead of to #F is a good
argument in favor of flushing NIL.
∂16-Mar-88 1201 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Types in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:00:52 PST
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 15 Mar 88 12:41:19 EST
Received: by CHAMARTIN.AI.MIT.EDU; Tue, 15 Mar 88 12:49:29 est
Date: Tue, 15 Mar 88 12:49:29 est
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8803151749.AA27754@chamarti>
To: JAR@AI.AI.MIT.EDU
Cc: daniel@MOJAVE.STANFORD.EDU, MKATZ@A.ISI.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Mon, 14 Mar 88 22:15:54 EST <341753.880314.JAR@AI.AI.MIT.EDU>
Subject: Types in Scheme
Reply-To: jinx@zurich.ai.mit.edu
I'm sorry, can you tell me again why you'd want to ask the unportable
("intensional") question in portable code, or in any code, for that
matter? As someone trying to write good code, I want my program to be
as insensitive as possible to the Scheme implementor's representation
decisions
I think you are being too "nitpicky" here. Just because a piece of
code is not portable it does not mean it is not good. To get some
efficiency (or detailed control of precision and accuracy), it may be
necessary, for example, to inquire whether a number (which might
otherwise be COMPLEX?, REAL?, RATNUM?, and INTEGER?) is a FIXNUM? in a
particular implementation. I'm not advocating for
implementation-specific predicates in the language, but it is clear to
me that they are necessary for certain pieces of admittedly
non-portable code. Each implementation should provide a set of
predicates about representation because it MAY matter to someone, and
s/he may have a valid use for them.
∂16-Mar-88 1230 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA t and nil
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:00:05 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Mar 88 07:26:23 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.research (3.2/4.7)
id AA01458; Tue, 15 Mar 88 07:22:49 EST
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Tue, 15 Mar 88 07:22:46 EST
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA20533; Tue, 15 Mar 88 07:22:46 EST
Date: Tue, 15 Mar 88 07:22:46 EST
Message-Id: <8803151222.AA20533@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Cc: ramsdell@mitre-bedford.ARPA
In-Reply-To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET's message of 10 Mar 88 14:39:25 PST (Thu) <8803102239.AA26765@tekchips.CRL.TEK.COM>
Subject: t and nil
I support Will's suggestion to not specify whether the empty list
counts as true or as false. I think now is the time for making
(not '()) ==> #f.
On another subject, I would like to see that the variables T and NIL
not be treated specially. In particular, a user should be able to
type:
(let ((t '#f)) t) ==> #f
I like using a local variable named "T". Experience shows that it is
not portable to do so. I think it should be.
I'm not sure why the standard suggests that T and NIL may have initial
values. Those writing portable code which uses T and NIL should start
there code with
(define t '#t)
(define nil '())
I suggest r↑xrs drop any reference to the variables T and NIL. Let T
and NIL be special only in that they have the same name as some Lisp
dialects.
∂17-Mar-88 2338 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ML
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 88 23:38:22 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 18 Mar 88 02:33:19 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA08902; Thu, 17 Mar 88 21:52:45 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 18 Mar 88 05:42:55 GMT
From: iris!windley@ucdavis.ucdavis.edu (Phil Windley)
Organization: U.C. Davis - Robotics Research Laboratory
Subject: ML
Message-Id: <1478@ucdavis.ucdavis.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
It seems that I remember a discussion in this newsgroup about ML several
months ago. At the time, I wasn't interested enough to save the stuff,
but now I need to know...
Is there a public domain ML interpreter available somewhere?
Phil Windley
Robotics Research Lab
University of California, Davis
∂18-Mar-88 0525 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 05:25:30 PST
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 18 Mar 88 08:26:10 EST
Received: by MURREN.AI.MIT.EDU; Fri, 18 Mar 88 08:30:27 est
Date: Fri, 18 Mar 88 08:30:27 est
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8803181330.AA00533@murren>
To: rrrs-authors@mc
Subject: standardization meeting
Reply-To: hal@ai.ai.mit.edu
I have invited Dick Gabriel to attend the meeting this weekend.. I
think we need to understand what's been happening with the Lisp ISO
mess and what implications this has for Scheme. With Bartley,
Clinger, and Gabriel there, we should get a good idea.
∂18-Mar-88 0717 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU ML
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 07:17:06 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Mar 88 10:14:53 EST
Date: Fri 18 Mar 88 10:14:24-EST
From: Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>
Subject: ML
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12383324733.11.NIKHIL@XX.LCS.MIT.EDU>
Dave Macqueen at ATT Bell Labs, Murray Hill, is distributing his implementation
of Standard ML. It is not public domain (there is a token license fee), but
it is meant as a research tool, not a commercial product. Try contacting him
at: dbm.btl@relay.cs.net
or: dbm%research.att.com@relay.cs.net
Nikhil (nikhil@xx.lcs.mit.edu)
-------
∂18-Mar-88 0930 @MC.LCS.MIT.EDU:dbm%research@att.arpa ML compiler -- Standard ML of NJ
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 09:30:45 PST
Received: from att.arpa (TCP 1201200131) by MC.LCS.MIT.EDU 18 Mar 88 12:28:10 EST
From: dbm@research.att.com
Date: Fri, 18 Mar 88 11:23:56 EST
To: scheme@mc.lcs.mit.edu
Subject: ML compiler -- Standard ML of NJ
Glad you asked!
I am distributing copies of Standard ML of New Jersey, an incremental
compiler that is currently available for Sun and Vax/Unix. Licenses
are available only to academic institutions at the moment, and there
is no charge. Eventually licenses should be available to anyone, and
then there may be a small license fee.
The version we are currently distributing is a "beta" version (Version
0.18). Version 1.0 should be out by this summer. Standard ML of New
Jersey is being written by Andrew Appel of Princeton, Trevor Jim, a
former student of Andrew's who is now at Bell Labs, and myself.
To obtain a license contract, send me mail, including your name, phone
number, mail address, and email address. It would also be useful if
you would indicate whether you have arpanet ftp access.
Dave MacQueen
macqueen%research.att.com@relay.cs.net
...!research!macqueen
Room 2C-322
AT&T Bell Laboratories
Murray Hill, NJ 07974
(201) 582-7691
∂19-Mar-88 1104 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the PC
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 88 11:03:57 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Mar 88 13:59:36 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA16680; Sat, 19 Mar 88 07:15:17 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 18 Mar 88 19:12:12 GMT
From: dxs1521@acf3.nyu.edu (David Suyλλλλλλλλavid Suna)
Organization: New York University
Subject: Scheme for the PC
Message-Id: <607@acf3.NYU.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have seen discussions here of scheme for the pc.
How can I get it? ftp would be fine or someplace to
e-mail to for it.
Thanks in advance,
David Suna
dxs1521@acf3.nyu.edu
∂20-Mar-88 0847 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Scheme for the PC
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 88 08:47:42 PST
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 20 Mar 88 11:39:52 EST
Received: by ZOHAR.AI.MIT.EDU; Sun, 20 Mar 88 11:42:23 est
Date: Sun, 20 Mar 88 11:42:23 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8803201642.AA07040@zohar>
To: dxs1521@acf3.nyu.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (David Suyavid Suna's message of 18 Mar 88 19:12:12 GMT <607@acf3.NYU.EDU>
Subject: Scheme for the PC
PC Scheme is available from Texas Instruments for $95.
Call 1-800-TI-PARTS.
∂20-Mar-88 1224 @MC.LCS.MIT.EDU:dybvig@silver.bacs.indiana.edu meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 88 12:24:21 PST
Received: from silver.bacs.indiana.edu (TCP 30003147002) by MC.LCS.MIT.EDU 20 Mar 88 15:24:59 EST
Date: Sun, 20 Mar 88 15:22:26 est
From: R. Kent Dybvig <dybvig@silver.bacs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: meeting
I have sent a schedule for this weekend's meeting along with directions
from the airport to Bloomington to everyone I have heard from who is
planning to attend. If you do not receive this note and you are
planning to attend, please call me at 812/333-8653 or 812/335-6486.
Electronic mail to me is not reliable, but it will probably reach me if
you send it to both "dyb@iuvax.cs.indiana.edu" and
"dybvig@silver.bacs.indiana.edu".
Kent
∂21-Mar-88 0956 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 09:56:46 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 21 Mar 88 12:57:33 EST
Date: 21 Mar 88 0954 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Meeting
To: rrrs-authors@MC.LCS.MIT.EDU
The Chairman and Vice Chairman of X3J13 have asked me to attend the
upcoming Scheme meeting in Indiana. As some of you know, I am the
US representative to ISO/IEC JTC1/SC22/WG 16, which is the ISO Lisp
standardization working group. I was named US representative by ANSI
after nomination by X3. As the US representative, I am required to
represent the entire US Lisp community. Because I had no instructions
or direction from the Scheme community, my representation of it consisted
of these actions:
1. declaring to WG 16 that I had no instructions from the Scheme community
2. announcing my belief that the Scheme community was considering a
formal standardization process
3. declaring that the US had an interest in either Scheme or Common Lisp
as a departure point for ISLISP (the name of ISO Lisp)
4. lobbying against the use of the name ISO Common Lisp as the name of
ISO Lisp
5. lobbying against any actions or statements by WG 16 that would jeopardize
or constrain the activities of the Scheme community were they to pursue
standardization
The next ISO meeting will immediately follow the Lisp and Functional
Programming Conference, at Snowbird, Utah. At working group meetings I am
required to report on national standardization activities. Furthermore, if
there are any actions that the Scheme community wishes to take in the
working group, those actions must be taken by me. Therefore, my attendance
at this meeting is intended to accomplish the following:
1. I can report on the working group meeting
2. I can report on X3J13 activities and responses to the working group meeting
3. I can gather comments that you wish made at the next working group meeting
4. I can accept requests for attendance of the next working group meeting
(though I cannot guarantee such requests can be honored until there is an
ANSI-recognized standardization group for Scheme)
5. I can accept suggestions for the US position at the working group
meetings
6. I will takes notes and prepare a report to WG 16 on the activities at
the Scheme meeting
See you in Bloomington.
-rpg-
∂21-Mar-88 1503 NET-ORIGIN@MC.LCS.MIT.EDU Read Macros's in Scheme ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 15:03:22 PST
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 MAR 88 18:01:03 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA18545@EDDIE.MIT.EDU>; Mon, 21 Mar 88 17:57:09 EST
From: pierce@golfer.Dayton.NCR.COM
Received: by XN.LL.MIT.EDU; Mon, 21 Mar 88 17:58:07 EST
Posted-Date: Mon, 21 Mar 88 16:41:05 EST
Received: by SCUBED.ARPA (1.2/5.20b)
id AA08436; Mon, 21 Mar 88 14:25:56 pst
Message-Id: <8803212225.AA08436@SCUBED.ARPA>
To: scheme@mc.lcs.mit.edu
Date: Mon, 21 Mar 88 16:41:05 EST
Subject: Read Macros's in Scheme ?
Cc: gene.pierce%dayton.ncr.com@relay.cs.net
X-Mailer: Elm [version 1.5]
I would like to know if read macros are possible in Scheme.
(e.g. Symbolics uses the "setsyntax" function)
Any and all reponses are appreciated.
Thanks,
gene pierce
gene.pierce%dayton.ncr.com@relay.cs.net
--
∂22-Mar-88 0647 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [OMAHONY: Clyde Camp's Utilities]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 06:47:45 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Mar 88 09:46:14 EST
Date: Tue, 22 Mar 88 09:46:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [OMAHONY: Clyde Camp's Utilities]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <345723.880322.JAR@AI.AI.MIT.EDU>
...
Received: from IRLEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
7540; Mon, 21 Mar 88 08:01:25 EST
...
Date: 21-MAR-1988 12:54:07 GMT
From: <OMAHONY at CSVAX1.TCD.IE>
To: scheme-request at mc.lcs.mit.edu
Re: Clyde Camp's Utilities
A little while back, someone sent in a request for the latest version
of Clyde Camps Utilities for TI-Scheme. I have not heard of these
before - what are they?
Donal O'Mahony omahony@cs.tcd.ie or (older mailers) omahony@tcdcs.uucp
Computer Science Dept.,
Trinity College,
Dublin,
Ireland
∂22-Mar-88 0722 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU editing
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 07:22:12 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Mar 88 09:58:25 EST
Date: Tue, 22 Mar 88 09:58:55 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: editing
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <345726.880322.JAR@AI.AI.MIT.EDU>
This message is to inform everyone that I'm willing to edit the
Revised↑4 Report, even if it has to be put into a form constrained by some
standards organization. I'm keeping track of changes, typos, and other
edits that need to be made.
The main language changes on which I perceive consensus so far are
(1) addition of PEEK-CHAR
(2) changes to number syntax (GJS, GLS, and others have already made
appropriate edits to numbers section)
(3) changes to description & semantics of EQ? and EQV? to
allow multiple empty vectors & strings
Have I forgotten anything?
I also intend to add a more precise description of quasiquote, which of
course will have to be approved first.
∂22-Mar-88 1235 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: xscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 12:35:43 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 22 Mar 88 15:33:24 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA21491; Tue, 22 Mar 88 04:37:21 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Mar 88 23:31:20 GMT
From: hpcea!hpccc!ga@hplabs.hp.com (G.A. Gordon)
Organization: HP Corporate Computing Center
Subject: Re: xscheme
Message-Id: <160001@hpccc.HP.COM>
References: <1538@ncsuvx.ncsu.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
/ hpccc:comp.lang.scheme / gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman) / 8:20 pm Mar 2, 1988 /
You said:
I'm just an undergraduate, my opinion doesn't matter.
Why do you feel that way? You have an unhealthy self-image problem.
Your opinion does matter, at least it does to me.
----------
∂23-Mar-88 1510 NET-ORIGIN@MC.LCS.MIT.EDU How can you do things like ?X -> (*var* x) without Read Macros ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 15:10:38 PST
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 MAR 88 18:07:02 EST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA28724@EDDIE.MIT.EDU>; Wed, 23 Mar 88 18:03:43 EST
From: pierce@golfer.Dayton.NCR.COM
Received: by XN.LL.MIT.EDU; Wed, 23 Mar 88 15:00:06 EST
Posted-Date: Wed, 23 Mar 88 13:29:00 EST
Received: by SCUBED.ARPA (1.2/5.20b)
id AA16664; Wed, 23 Mar 88 11:41:57 pst
Message-Id: <8803231941.AA16664@SCUBED.ARPA>
To: scheme@mc.lcs.mit.edu
Date: Wed, 23 Mar 88 13:29:00 EST
Subject: How can you do things like ?X -> (*var* x) without Read Macros ?
Cc: gene.pierce%dayton.ncr.com@relay.cs.net
X-Mailer: Elm [version 1.5]
Sometimes it is very useful to hide some underlying implementation details
when writing systems such as inference engines. Since Scheme doesn't have
ability to handle read macros then is it possible to do
something like the following in a differnet way ?
where "x" is a variable and "?" is a read macro and the "?" read macro
reads the next character, which is "x" and transforms "?X" into
the following list structure (*var* x) . This representation
is useful to the underlying code and the "?x" is useful to
a user to designate unifiable variables in a backward or forward chaining
rule.
Any and all responses are appreciated.
thanks in advance,
Gene Pierce
--
∂24-Mar-88 0933 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [camp: [OMAHONY: Clyde Camp's Utilities]]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 09:32:54 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Mar 88 10:54:03 EST
Date: Thu, 24 Mar 88 10:54:36 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [camp: [OMAHONY: Clyde Camp's Utilities]]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <346781.880324.JAR@AI.AI.MIT.EDU>
Date: Wed, 23 Mar 88 13:26:18 CST
From: Clyde Camp <camp at mips.csc.ti.com>
Re: [OMAHONY: Clyde Camp's Utilities]
Organization: TI Computer Science Center, Dallas
The PCS utilities I began distributing some time back have been
upgraded to take advantage of some of the features of PC Scheme 3.0.
For those of you interested in PCS, a set of these utilities and
documentation is available (free) from:
Clyde R. Camp
Texas Instruments, Inc.
P.O.Box 655474, MS 238
Dallas, TX 75266
*=======================================================================*
Send two blank, FORMATTED disks and a SELF-ADDRESSED, STAMPED envelope.
*=======================================================================*
Although written primarily for the TIPC, everything except the
graphics should work on IBMs and IBM clones. The directories are:
UTILITY - Various text windowing, file printing and keyboard handlers
which simplify writing application programs (includes a file
pretty-printer and a new top-level read-eval-print loop which uses an
emacs-like line-editor with the capability to scroll through and edit
previous entries)
SWI - A convenient mechanism for invoking 8086 ASSY routines via SWI-INT.
HELP - A user-extendable on-line help facility which includes all of
the PCS functions and syntax as well as other information on PCS
specific quirks.
GRAF - A graphics package for creating graphics "windows" somewhat
analogous to text windows
PLOT - A general purpose function plotter
GAME1 - Self explanatory - non-graphics for IBM or TIPC
GAME2 - for TIPC graphics
ERR_STAT - more utilities for controlling the status window, testing
for directories and disabling the gc-message
MENUSHEL - two general purpose menu driven command shells handy for
application development.
∂24-Mar-88 1009 @MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU Re: Scheme as an introductory programming language
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 10:09:29 PST
Received: from UDEL.EDU (TCP 1200000140) by MC.LCS.MIT.EDU 24 Mar 88 13:05:34 EST
Received: from dewey.udel.edu by Louie.UDEL.EDU id aa00431; 24 Mar 88 12:53 EST
Received: from localhost by Dewey.UDEL.EDU id aa01681; 24 Mar 88 12:50 EST
To: Vincent Manis <manis%instr.camosun.bcc.cdn%ean.ubc.ca@relay.cs.net>
cc: scheme@mc.lcs.mit.edu
Subject: Re: Scheme as an introductory programming language
In-reply-to: Your message of 07 Mar 88 11:35:00 -0800.
<568*manis@instr.camosun.bcc.cdn>
Date: Thu, 24 Mar 88 12:50:07 -0500
From: David Saunders <saunders@UDEL.EDU>
Message-ID: <8803241250.aa01681@Dewey.UDEL.EDU>
I'm responding rather late to your inquiry on Scheme use.
We use scheme and SICP in our first course here at Delaware. We follow it
with a course which uses Modula2. Together, they seem to provide a good
basis for the rest of the program. We don't push extremely hard. From,
Ableson and Sussman we cover the first 3 chapters, and introduce the
interpreter of chapter 4 in the last week. Some of the students' mathematics
backgrounds are weak, but that has not been a major obsticle. Many take the
course concurrently with Calculus and that works fine. The use of "big O"
and logs gives trouble too, but that is essential CS and we regard it as
our job to build a modicum of skill with those things. Actually, I think
that scheme/lisp is much gentler in its mathematical demands on novices
than pascal. It allows them to get to the essence of programming without
having to fight past artificial distinctions about types of numbers.
The students program in C-scheme on a vax.
-david saunders
∂24-Mar-88 1213 @MC.LCS.MIT.EDU:bh@ernie.Berkeley.EDU How many Schemes can your Vax take?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 12:13:20 PST
Received: from ernie.Berkeley.EDU (TCP 20010104415) by MC.LCS.MIT.EDU 24 Mar 88 14:41:14 EST
Received: by ernie.Berkeley.EDU (5.58/1.26)
id AA20285; Thu, 24 Mar 88 11:40:26 PST
Date: Thu, 24 Mar 88 11:40:26 PST
From: bh@ernie.Berkeley.EDU (Brian Harvey)
Message-Id: <8803241940.AA20285@ernie.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu
Subject: How many Schemes can your Vax take?
At Berkeley we have been using Sun (3/50) systems to run
rather large introductory courses. Students use Emacs, C-scheme,
X-windows. While this is a noble experiment and has many
advocates, it is also money-intensive and slow. We are interested in
comparing this to various hypothetical alternatives. One
presumably lower-cost configuration for which others may have useful
experience is time-shared access to a (probably largish) VAX (ULTRIX).
Can you offer data points on how many users can be supported reasonably?
To make the data collection simpler, perhaps you could fill
in the following table:
VAX model #:
megs of memory:
Do you use Emacs? Jove? Vi?
Do you use C-Scheme, Chez Scheme, T, other?
Typical number of users for "good" response:
Typical number for "marginally acceptable" response:
Major advantages or disadvantages:
Any other comments or advice:
Please respond directly to me, rather than to the mailing list. I will
summarize responses.
Thanks.
∂24-Mar-88 1420 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: How can you do things like ?X -> (*var* x) without Read Macros ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 14:20:28 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Mar 88 16:41:47 EST
Received: from Salvador.ms by ArpaGateway.ms ; 24 MAR 88 13:37:00 PST
Date: Thu, 24 Mar 88 13:36:31 PST
From: Pavel.pa@Xerox.COM
Subject: Re: How can you do things like ?X -> (*var* x) without Read Macros ?
In-reply-to: <8803231941.AA16664@SCUBED.ARPA>
To: pierce@golfer.Dayton.NCR.COM
Cc: scheme@mc.lcs.mit.edu
Message-ID: <880324-133700-4063@Xerox>
You preprocess the input from the user, checking each symbol for a
first-character of "?" and transforming all such uses into the list you
mentioned. Alternatively, you write a parser/scanner for your input language
that has nothing to do with the Scheme function READ.
I prefer the latter idea myself. To my mind, READ's only legitimate purpose is
the reading of real Scheme programs and data.
Pavel
∂24-Mar-88 1616 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@buita.BU.EDU How can you do things like ?X -> (*var* x) without Read Macros ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 88 16:16:14 PST
Received: from buita.BU.EDU (TCP 20061212055) by MC.LCS.MIT.EDU 24 Mar 88 19:13:33 EST
Received: from BU-IT.BU.EDU by buita.BU.EDU (5.58/4.7)
id AA24397; Thu, 24 Mar 88 19:07:20 EST
Received: from bucsf (bucsf.bu.edu) by bu-it.bu.edu (3.2/4.7)
id AA28602; Thu, 24 Mar 88 19:10:12 EST
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA23522; Thu, 24 Mar 88 19:10:07 est
Date: Thu, 24 Mar 88 19:10:07 est
From: gjc%bucsf.bu.edu@buita.BU.EDU (George J. Carrette)
Message-Id: <8803250010.AA23522@bucsf>
To: pierce@golfer.Dayton.NCR.COM
Cc: scheme@mc.lcs.mit.edu, gene.pierce%dayton.ncr.com@relay.cs.net
Subject: How can you do things like ?X -> (*var* x) without Read Macros ?
(1) if you are implementing your own read/eval/print loop for a random
language you can write your own read, or use that CGOLREAD that
someone on this list may have already ported to scheme.
(1.5) you may be able to get away with a read/mung/eval/print loop.
Just mung the result of read before you pass it along.
I teach just this technique to transform ?x into the result of
(make-variable :name 'x) (common lisp, sigh...) in a problem
set on pattern matching and pattern compilation.
(2) If you have evaluation macros, you can always have them mung
the passed-in-structure without mercy, e.g. using the technique (1.5)
(assert (append ?x () ?x))
(assert (append ?x (?a . ?y) (?a . ?y))
(append ?x ?y ?y))
(3) If you dont have evaluation macros, big deal, just quote the arguments,
(assert '(append ?x () ?x))
as long as can call EVAL or COMPILE yourself there is no loss of
generality.
(4) In drastic situations use strings,
(fortran "FUNCTION F(X,Y)
F = X*Y+SIN(X)
RETURN
END")
Note that FORTRAN 77 uses 'FOO BAR' for strings, so this actually works
ok, without having to escape-quote internal double quotes.
-gjc
∂26-Mar-88 1627 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Saving a continuation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Mar 88 16:27:37 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Mar 88 19:25:18 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA19763; Sat, 26 Mar 88 01:28:42 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Mar 88 14:25:59 GMT
From: pacbell!att-ih!alberta!calgary!jameson@AMES.ARC.NASA.GOV (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Saving a continuation
Message-Id: <1488@vaxb.calgary.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
When a continuation is saved, what else must be preserved?
1) Surely the stack history prior to the save?
2) The environment at the time of the save (this is not done, as far as
I can figure out)
3) Anything else?
Thanks
Kevin ...!{ihnp4,ubc-vision}!alberta!calgary!jameson
∂26-Mar-88 1700 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MIT C-Scheme design info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Mar 88 17:00:12 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 26 Mar 88 19:26:55 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA19659; Sat, 26 Mar 88 01:23:12 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Mar 88 14:18:52 GMT
From: pacbell!att-ih!alberta!calgary!jameson@AMES.ARC.NASA.GOV (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: MIT C-Scheme design info
Message-Id: <1487@vaxb.calgary.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have just been looking through the source for C Scheme v4.1.1 (via the Gnu
distribution), and am almost overcome with the size of the task at hand (to
understand it so I can write my a simpler version for my pc). I recognize
that I could cut away code until I could isolate the major components, but
I would still be left wondering why things were done the way they were.
Did anyone write any design info down when it was being constructed? If so,
is there any way I could obtain a copy to read? Failing that, could anyone
post a design summary if they have one?
Could anyone in the know suggest a starting place and method toward
understanding this implementation?
Is 4.1.1 the latest version?
Thanks
Kevin ...!{ihnp4,ubc-vision}!alberta!calgary!jameson
∂27-Mar-88 1046 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: T operations, etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Mar 88 10:46:34 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 13:00:35 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA29063; Sat, 26 Mar 88 10:34:53 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 24 Mar 88 22:14:27 GMT
From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: Re: T operations, etc
Message-Id: <304@aiva.ed.ac.uk>
References: <574814312.20004@minster.york.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <574814312.20004@minster.york.ac.uk> martin@minster.york.ac.uk
writes:
>I've just discovered that T version 3 has an as-far-as-I-can-tell
>undocumented syntax for operations. [...]
> ((operation-name (self op-name next first) . args) . body)
I'd just noticed that myself. Perhaps it is "unreleased", as the T
2.8 release notes used to say of experimental things.
> How many other wonderful things are hiding in T3.0 that people
>don't know about because of the (lack of up-to-date) documentation?
It works the other way too: the LOCALE special form has stopped
working despite being documented in the manual and in Stephen Slade's
book. Nonetheless, I suspect the release notes cover most of the
changes (they cover the LOCALE one) and so expect that the number of
further surprises will be small.
>On a similar note... Has anyone succeeded in re-compiling & linking T3.0,
>or of suspending a T system?
I have not tried rebuilding T, but I have no trouble suspending it
with csh job control on a Sun.
> Has anyone else in Europe/UK got T3.0?
Why, yes: I have one, and I know of at least two others. We should
keep in touch.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂27-Mar-88 1202 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where can I get Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Mar 88 12:02:07 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 13:13:37 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA04295; Sat, 26 Mar 88 17:02:52 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 Mar 88 23:46:29 GMT
From: darrell@sdcsvax.ucsd.edu (Darrell Long)
Organization: University of California, San Diego
Subject: Where can I get Scheme?
Message-Id: <4806@sdcsvax.UCSD.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi there! Where can I get sources to Scheme? I can ftp, MILnet prefered.
Thanks, DL
--
Darrell Long
Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093
ARPA: Darrell@Beowulf.UCSD.EDU UUCP: darrell@sdcsvax.uucp
Operating Systems submissions to: comp-os-research@sdcsvax.uucp
∂27-Mar-88 1421 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu T operations, etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Mar 88 14:20:53 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 27 Mar 88 16:31:04 EST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA08205; Thu, 24 Mar 88 07:51:45 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Mar 88 22:38:32 GMT
From: mcvax!ukc!reading!onion!minster!SoftEng!martin@uunet.uu.net
Organization: Department of Computer Science, University of York, England
Subject: T operations, etc
Message-Id: <574814312.20004@minster.york.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've just discovered that T version 3 has an as-far-as-I-can-tell
undocumented syntax for operations. The documentation gives:
(object procedure . method-clauses)
where a method-clause is:
((operation-name self . args) . body)
well, it turns out that a method-clause can also be:
((operation-name (self op-name next first) . args) . body)
where 'self' is bound to the 'object' in which the method-clause was
defined, as before, 'op-name' is bound to the operation being carried out,
'next' is bound to the next 'object' in the 'join' which would have been
asked to field this operation if the present 'object' had not got it, and
'first' is bound to the first 'object' of the 'join' that was asked to
field the operation.
It seems obvious that these are intended to allow more control
over the inheritance of operations. 'first' is the Smalltalk equivalent
of self, and 'next' the equivalent of super! 'op-name' appears to allow
the forwarding of operations.
How many other wonderful things are hiding in T3.0 that people
don't know about because of the (lack of up-to-date) documentation?
On a similar note... Has anyone succeeded in re-compiling & linking T3.0,
or of suspending a T system? Whenever I try to compile things I get syntax
errors (or worse!), and whenever I try to suspend I get an indefinite
recursion in vgc! Help!
Martin
usenet: ...!mcvax!ukc!minster!martin
surface:
Martin C. Atkins
Department of Computer Science
University of York
Heslington
York Y01 5DD
ENGLAND
PS
I'm using the Sun-3 version of T
PPS
Despite the above gripes, I like T very much... It's just that I can't
use it for the things I want unless I can link in some more C routines!
PPPS
Has anyone else in Europe/UK got T3.0?
∂28-Mar-88 0728 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU T discussion and newsgroups
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 88 07:28:13 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 88 10:23:41 EST
Date: Mon, 28 Mar 88 10:24:22 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: T discussion and newsgroups
To: mcvax!ukc!reading!onion!minster!SoftEng!martin@UUNET.UU.NET
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 19 Mar 88 22:38:32 GMT from mcvax!ukc!reading!onion!minster!SoftEng!martin at uunet.uu.net
Message-ID: <348649.880328.JAR@AI.AI.MIT.EDU>
Discussion pertaining T can be carried out on the T-Discussion
mailing list. Send mail to t-discussion-request@MC.LCS.MIT.EDU to
be added. Similarly for C Scheme; info-cscheme-request%OZ@MC.LCS.MIT.EDU.
... unless you do not have access to the Internet, as I understand many
Usenet people do not. In that case, please carry on the conversation
here (or on comp.lang.scheme), as there is no "comp.lang.t" newsgroup to
my knowledge. Or lobby Berkeley to create one. The same goes for C
Scheme (I have repeatedly requested that they create a C Scheme
newsgroup, but they say they are too busy).
And speaking of comp.lang.scheme: please correct me if I'm wrong, but
it's my understanding that messages sent to the Scheme mailing list on
the Internet are forwarded to comp.lang.scheme on Usenet, but not vice
versa. It's possible that there is interesting discussion happening on
comp.lang.scheme that us Internet users are missing out on, but I
wouldn't know. I hear rumors that there exist mailing lists for which
there is mutual forwading between Internet and Usenet (without infinite
loops), but I don't know how to set one up. If anyone would like to
volunteer to do so, please speak up by sending a message to me at
scheme-request@mc.lcs.mit.edu.
- humble moderator.
∂28-Mar-88 1117 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU CLOS Error Terminology
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 88 11:17:04 PST
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 28 Mar 88 14:12:26 EST
Date: 28 Mar 88 1039 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: CLOS Error Terminology
To: rrrs-authors@MC.LCS.MIT.EDU
The following is the current section on error terminology in the CLOS
document. I should point out that this section is currently
under debate. The areas of debate are the definitions of ``undefined''
and ``unspecified,'' along with the general philosophy that extensions
are disallowed by default (which is the opposite to Common Lisp):
\beginSection{Error Terminology}
The terminology used in this document to describe erroneous
situations differs from the terminology used in {\it Common Lisp:
The Language}, by Guy L. Steele Jr. This terminology involves {\bit
situations}; a situation is the evaluation of an expression in some
specific context. For example, a situation might be the invocation of
a function on arguments that fail to satisfy some specified
constraints.
In the specification of the \CLOS, the behavior of programs in all situations
is described, and the options available to the implementor are defined. No
implementation is allowed to extend the syntax or semantics of the \OS\ except
as explicitly defined in the \OS\ specification. In particular, no
implementation is allowed to extend the syntax of the \OS\ in such a way that
ambiguity between the specified syntax of \OS\ and those extensions is
possible.
``When situation $S$ occurs, an error is signaled.''
This terminology has the following meaning:
\beginlist
\item{\bull} If this situation occurs, an error will be signaled in
the interpreter and in code compiled under all compiler safety
optimization levels.
\item{\bull} Valid programs may rely on the fact that an error will be
signaled in the interpreter and in code compiled under all compiler
safety optimization levels.
\item{\bull} Every implementation is required to detect such an error
in the interpreter and in code compiled under all compiler safety
optimization levels.
\endlist
``When situation $S$ occurs, an error should be signaled.''
This terminology has the following meaning:
\beginlist
\item{\bull} If this situation occurs, an error will be signaled at
least in the interpreter and in code compiled under the safest
compiler safety optimization level.
\item{\bull} Valid programs may not rely on the fact that an error will be
signaled.
\item{\bull} Every implementation is required to detect such an error
at least in the interpreter and in code compiled under the safest
compiler safety optimization level.
\item{\bull} When an error is not signaled, the results are undefined (see
below).
\endlist
``When situation $S$ occurs, the results are undefined.''
This terminology has the following meaning:
\beginlist
\item{\bull} If this situation occurs, the results are unpredictable. The
results may range from harmless to fatal.
\item{\bull} Implementations are allowed to detect this situation and
signal an error, but no implementation is required to detect the
situation.
\item{\bull} No valid program may depend on the effects of this
situation, and all valid programs are required to treat the effects
of this situation as unpredictable.
\endlist
``When situation $S$ occurs, the results are unspecified.''
This terminology has the following meaning:
\beginlist
\item{\bull} The effects of this situation are not specified in
the \OS, but the effects are harmless.
\item{\bull} Implementations are allowed to specify the effects of
this situation.
\item{\bull} No portable program can depend on the effects of this
situation, and all portable programs are required to treat the situation
as unpredictable but harmless.
\endlist
``The \CLOS\ may be extended to cover situation $S$\negthinspace.''
The meaning of this terminology is that an implementation is free to treat
situation $S$ in one of three ways:
\beginlist
\item{\bull} When situation $S$ occurs, an error is signaled at least
in the interpreter and in code compiled under the safest compiler
safety optimization level.
\item{\bull} When situation $S$ occurs, the results are undefined.
\item{\bull} When situation $S$ occurs, the results are defined and
specified.
\endlist
In addition, this terminology has the following meaning:
\beginlist
\item{\bull} No portable program can depend on the effects of this
situation, and all portable programs are required to treat the situation
as undefined.
\endlist
``Implementations are free to extend the syntax $S$\negthinspace.''
This terminology has the following meaning:
\beginlist
\item{\bull} Implementations are allowed to define unambiguous extensions
to syntax $S$\negthinspace.
\endlist
The \CLOS\ specification may disallow certain extensions while allowing others.
\endSection%{Error Terminology}
∂28-Mar-88 1240 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM More for R4RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 88 12:40:47 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Mar 88 14:27:22 EST
Received: from Semillon.ms by ArpaGateway.ms ; 28 MAR 88 10:43:39 PST
Date: Mon, 28 Mar 88 10:43:18 PST
From: Pavel.pa@Xerox.COM
Subject: More for R4RS
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880328-104339-3618@Xerox>
A little while ago, Jon asked for any other subjects to be included in R4RS.
Jon, did you mention Will's proposal to make the empty list (optionally) true?
Also, as a new proposal, I'd like to see the functions
CHAR?, INTEGER->CHAR, and CHAR->INTEGER
renamed to
CHARACTER?, INTEGER->CHARACTER, and CHARACTER->INTEGER.
The reason has to do with the contrast between predicate names like BOOLEAN?,
INTEGER?, and RATIONAL? (as opposed to BOOL?, INT?, and RAT?) and the name
CHAR?.
I had a bit of trouble recently trying to find a predicate for character-ness
because I naturally wanted to use the full name of the type, consistently with
the rest of Scheme. I was mildly disgusted when I discovered that the name was
actually the abbreviation, not the full name.
I don't suggest changing the names of the other character operations because
they don't seem to be naming the type itself as explicitly. I know this sounds
fuzzy, but it seems alright to me to have the names CHARACTER->INTEGER and
CHAR-NUMERIC? side-by-side.
Comments?
Pavel
∂30-Mar-88 1005 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT C Scheme design info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Mar 88 10:05:02 PST
Received: from ucbvax.berkeley.edu (TCP 1200400116) by MC.LCS.MIT.EDU 30 Mar 88 08:39:13 EST
Received: by ucbvax.berkeley.edu (5.59/1.26)
id AA02604; Tue, 29 Mar 88 14:15:20 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Mar 88 00:17:52 GMT
From: att-ih!alberta!calgary!jameson@gargoyle.uchicago.edu (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Re: MIT C Scheme design info
Message-Id: <1499@vaxb.calgary.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
The following is a list of most C files used in the MIT C Scheme
interpreter, along with a brief statement of function. Most of the
information is gleaned from the short comment at the beginning of each
file. This list gives a flavor of how the interpreter is organized,
and should help new readers of the code to find their way around.
Note that much (half?) of C Scheme is written in Scheme, and is not
listed here. The microcode interpreter files below actually
interpret many runtime functions which are written in Scheme (such
as the main read-eval-print loop). The Scheme runtime files + the
host interpreter below offer a complete system to the user.
Of course some of the information below may be wrong, though to
the best of my knowledge it is correct. Any mistakes are my own.
- Kevin Jameson, 28 March 88
..!{ihnp4,ubc-vision}!alberta!calgary!jameson
FILE Brief Function
============= ==================================================
scheme.h defs for the interpreter in interpre.c
config.h configuration file describes stk size,heap size, etc
const.h global named constants
fixobj.h format (offsets) of fixed object vector
extern.h extern machine and many other interface dcls
scode.h describes byte code format
sdata.h describes user data object formats
types.h list of object type codes TC_xxx
returns.h list of return codes used by interpreter RC_xxxx
errors.h list of error codes
prims.h list of ids and names (PC_xxx) for all system primitives
object.h defs & access macros for scheme objects
primitive.h macros for defining and handling primitives
boot.c main boot program for scheme interpreter
interpre.h macros for interpreter
zones.h time zones for performance metering
hooks.c hooks into the interp - apply,catch,throw, etc
storage.c prim, arg count tbls, global storage allocs
interpre.c byte code interp coded in continuation passing style
utils.c utils used by interpreter (backout_of_primitive,etc)
lookup.c symbol lookup and manipulation
usrdef.c table of external primitives produced by findprim
extern.c external primitives defined by user
findprim.c builds table of external prims from users files
nihil.c defines unimplemented primitives reqd by scheme
default.h unimplemented default hooks not def'd by user in config.h
cross.doc some doc on the cross syntaxer (byte code compiler)
readme.unx tells where things are in unix version
MATH CODE
generic.c mostly generic math funs for various numeric types
missing.c math utils which wouldn't fit anywhere else
mul.c portable fixnum multiplication
flonum.c floating pt funs, mostly superceded by generic.c
flonum.h defs for flonum.c
fixnum.c fixnum (24 bit) funs, mostly superceded by generic.c
bignum.c bignum arithmetic functions
bignum.h bignum arithmetic declarations
bitops.c extended bitops for infinite precision arithmetic
bitstr.c bitstring functions
DEBUGGING CODE
step.c support for the debugger stepper
xdebug.c useful prims for scheme memory prim debugging
bkpt.c debugger breakpoint functions
bkpt.h debugger breakpoint definitions, macros
debug.c printing and listing functions used by debugger
GARBAGE COLLECTOR
purify.c much like gc, only purifies (whatever that is) instead
daemon.c two gc daemons (obj hash tbl & file closer)
gc.h macros for all gc code (and maybe others)
gccode.h macros for code which does gc-like loops
gcloop.c low level gc stuff
gctype.c maps type codes into gc object type codes
PRIMITIVE FUNCTIONS
fetchpar.c makes implementation parms available to scheme
file.c file i/o primitive scheme functions
hunk.c funs to handle triplet hunk3's for file blocks
io.c scheme io primitives, channel grabbing, etc
list.c list manipulation functions (memq, cons, car, etc)
prim.c primitives which won't fit elsewhere
string.c string primitives, cv strings to/from lists
vector.c vector handling and conversion (to lists) code
FASTLOADER (FASL) FUNCTIONS
translate.h macros for psbtobin, bintopsb (psb=portable scheme binary)
schloader.c standalone prog to load a dumped scheme core?
load.c common code for reading fasl files
bintopsb.c converts fasl files to portable ascii
breakup.c used for fasl conversion?
ppband.c pretty prints fasl files in human format
psbtobin.c converts portable ascii files to fasl format
dump.c common code for dumping fasl files
dumpworld.c core save routine, calls gnu unexec
fasdump.c holds fasdump, fasload, and bandload functions
fasl.h defs for fasl file format
fasload.c reads fasl files, relocates and interns symbols
SCHEME CODE (not related to the Scheme runtime stuff)
chapter1.code from Structure and Interpretation of Computer Programs
chapter2.code from SICP (Abelson & Sussman)
chapter3.code from SICP
chapter4.code from SICP
chapter5.code from SICP
MISCELLANEOUS
ChangeLog only two entries
install main installation notes
Install.unx unix installation notes
Install.vms vms installation notes
Makefile main makefile
Makefile.200 for the 200 series of some machine
Makefile.500 for the 500 series of some machine
Makefile.ind for some other operating system
Makefile.unk for an unknown operating system
Makefile.vax for vax
Readme.vms tells where things are in vms version
TO_DO a wish list
UPGRADE diffs between CScheme release 3 and 4
Wsize.c tests out compiler/machine for bit & math ops
athena.c athena graphics primitives for special terminals
bobcat.c bobcat graphics interface for starbase package
config.dst same as config.h
locks.h for locking heap, etc
os.c selects appropriate operating system file for build
process.c utils to fork inferior processes in unix
regblock.c defines registers used by compiler
unexec.c from gnu-emacs. dumps core on unix systems
unix.c unix specific prims (completed version of unknown.c)
unknown.c os specific blank prim stubs for unknown op system
valret.c emulates ITS valret on a unix system
vms.c vms specific prims (completed version of unknown.c)
vmsall.com vms batch file for compilation
<several other vms batch files have been omitted>
SPECIAL CODE (to handle Scheme language features)
future.c support code for futures
futures.h macros for futures code
history.h defines history data structures
intercom.c single process simulation of futures stuff
∂31-Mar-88 0022 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu availability of Scheme on Atari STs
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Mar 88 00:21:54 PST
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 31 Mar 88 03:19:28 EST
Received: by ucbvax.Berkeley.EDU (5.59/1.26)
id AA27837; Wed, 30 Mar 88 19:21:19 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 Mar 88 18:54:22 GMT
From: trwrb!aero!venera.isi.edu!saus@ucbvax.Berkeley.EDU (Mark Sausville)
Organization: Information Sciences Institute, Univ. of So. California
Subject: availability of Scheme on Atari STs
Message-Id: <5148@venera.isi.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anybody know if there is a version of Scheme available
for the Atari ST? I know there's something called MacScheme
and it seems like those people could adapt there product
without too much trouble.
thanks,
Mark.
∂31-Mar-88 0619 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MIKEMAC@UNB.BITNET Porting Scheme to our IBM3090 running MVS/XA
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Mar 88 06:19:45 PST
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 31 Mar 88 09:15:21 EST
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Thu, 31 Mar 88 09:12:57 EST
Received: from UNB by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1391; Thu, 31
Mar 88 09:12:52 EST
Received: by UNBMVS1 (Mailer 1.04.14) id 8112; Thu, 31 Mar 88 10:10:45 AST
Date: Thu, 31 Mar 88 10:10:51 AST
To: SCHEME@MC.LCS.MIT.EDU
Subject: Porting Scheme to our IBM3090 running MVS/XA
From: "Michael J. MacDonald" <MIKEMAC%UNB.BITNET@MITVMA.MIT.EDU>
Message-ID: <ID3536.D880331.T101052.MIKEMAC@UNB>
We are considering porting Scheme to our IBM3090-180/VF. I am seeking
information on a number of items. We currently have the source from MIT
Scheme Version 4.1.1 microcode version 8.2.
What is the latest release of Scheme?
What problems can I expect?
Has anyone ported it to an IBM 370 (MVS) machine?
Does anyone have any advice?
Should we do it from scratch?
Please respond direct, I am not on the List.
Michael MacDonald
Software Specialist, School of Computer Science
University of New Brunswick
Po. Box 4400
Fredericton, New Brunswick
CANADA E3B 5A3
(506) 453-4566
Netnorth/BITNET: MIKEMAC@UNB
∂03-Apr-88 2327 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT C Scheme design info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Apr 88 23:27:36 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 Apr 88 00:15:32 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.26)
id AA07726; Sun, 3 Apr 88 09:42:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 Apr 88 02:37:27 GMT
From: ncc!alberta!calgary!jameson@uunet.uu.net (Kevin Jameson)
Organization: U. of Calgary, Calgary, Ab.
Subject: Re: MIT C Scheme design info
Message-Id: <1520@vaxb.calgary.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
The following is a list (part 2 of 2) of most Scheme files used in the
MIT C Scheme interpreter circa verson 4.1, along with a brief statement
of their function. Most of the information has been gleaned
gleaned from the short comment at the beginning of each
file. This list gives a flavor of how the interpreter is organized,
and should help new readers of the code to find their way around.
Note that much (half?) of C Scheme is written in C, and is not
listed here. The list of C files (part 1 of 2) for the microcode
interpreter was posted earlier.
I know now that the earlier posting of C files contained minor errors,
and at the very least is somewhat out of date (my version is 4.1,
vs. the current version of 6.2.0). (No doubt the same two facts will
hold for this file too, but it's a start...) Any mistakes are my own.
- Kevin Jameson, 31 March 88
..!{ihnp4,ubc-vision}!alberta!calgary!jameson
FILE Brief Function
============= ==================================================
SCHEME SYSTEM TYPES
xbuild.scm build a cross syntaxer system
abuild.scm build a system for athena
ubuild.scm build a unix interface scheme system
sbuildmd.scm build a student (MIT 6.001 course) scheme system
studentmd.scm env,syntax,& read tbl mods for 6.001 students
featmd.scm std features scheme system
INTERPRETER
error.scm rep (read-eval-print) interface,error defs,definers,handlers
parse.scm scheme parser for The REP Reader (ch class tbls,macros,atoms)
print.scm The REP (read-eval-print) Printer
read.scm The REP Reader (tyi/eof/input streams,with-input-from-file)
rep.scm the read-eval-print loop,history,and history access funs
repuse.scm REP user interface (prompts, drivers, proceeds)
CROSS SYNTAXER (the byte code (scode) compiler)
syntax.scm the Cross Syntaxer (byte code (scode) generator/compiler)
scan.scm definition scanner reduces n of "real auxilary" vars in env
xconv.scm convert declarations into integrations
xpatch.scm special lambda interface
xsubst.scm integration of primitives (merger, dispatcher)
unsyn.scm unsyntaxer converts scode back to sexprs
MISC DEFINITIONS and Data Type Stuff
adapt.scm compatability defs (true/#!true,nil/'(),list*/cons*)
crock.scm defs of special obj types (state & syntax tables, type obj)
stypes.scm scode type setup (TC's: symbols,conditions,proctypes,etc)
scode.scm scode grab bag (consts,many predicates for data types)
sdata.scm abstract data field funs(ctl pts,set!s,refs,pairs,vects,etc)
types.scm abstract typing funs (supremum/infimums?,lattice theory stuff)
ustruc.scm microstruc? (follows scode abstraction in boot sequence)
utabmd.scm ucode type tables (fixed,types,returns,prims,externs,errors)
utabs.scm ucode tbl intrfc (fixed obj vec,type detection,TC,RC,TERMC..)
PRIMITIVES
bitvec.scm 1 bit vector ops (cons,set,size,ref,1b? predicates)
char.scm character defs, bit tables, charscan table generator funs
equals.scm many equality funs (eqv?,equal?,etc)
explode.scm maclisp style printname utils (explode,implode,readch,ascii)
format.scm output string formatters, format dispatch table
gensym.scm uninterned symbol generator
gprims.scm global primitives list (defs funs in global env for compiler)
hash.scm object hashing, unhashing, population functions
io.scm primitive io utils (channel stuff, files vector/locks,hunk3s)
list.scm lisp ops (cons,pair?,length,cxr,mappers,assocs,members,etc)
load.scm program loading
lambda.scm lambda abstraction (lambda,lexpr,extended-lambda)
narith.scm scheme math funs (+,-,trigs,floats,polys,min/max,etc)
oldio.scm old io procedure names (channel io stuff)
pathnm.scm pathname utils (make,drive,directroy,type,conversion funs)
primlist.scm primitive list ops (cons,memq,assoc,cxr,etc)
scomb.scm scode combinator abstractions
stream.scm stream utilities (append,filter,accumulate,merge,etc)
string.scm character string ops
strmac.scm stream macros
uio.scm useful file io funs (read,copy,rn,dl,exists?)
unpars.scm unparsers for converting objects to string representations
vector.scm vector ops (make,copy,vector references..)
xlist.scm extended list ops (mapcan,mapcan*,or,and)
PACKAGES
advice.scm tools to advise funs (trace,break,other advice wrappers)
pp.scm scheme pretty printer
rrrs.scm revised report on Scheme compatability defs,macro definers
wind.scm state space world model (state pts,dynamic wind,protectors..)
DEBUGGER
comand.scm debugger command loop support
debug.scm scm level debugger w/ display,history,motion,continuation cmds
stackp.scm scheme control stack parser for debugger
where.scm the environment inspector(show,show-frame,print bindings...)
xdebug.scm debugging primitives
SYSTEM
boot.scm bootload utils, run after coldmd. defs of global primitve funs
datime.scm date time utils
events.scm event distribution system
file.scm file package (catalog,floppy,volumn,directory,misc funs)
gc.scm scheme garbage collector, gc-daemon list, suspension funs
gcstat.scm garbage collector meters, history modes, etc
history.scm history manipulation (backbone & ribs, push/pop history, etc)
intrpt.scm interrupt system (timers,keyboard ints,default handlers)
link.scm links compiled byte code ?
photo.scm ? takes an internal photo or something (whatever that is)
sysclk.scm system clock utils (set,read,interval calculations)
system.scm system funs (world dumpers,disk savers)
world.scm world ops (save, disk restore, quit, exit..)
MACHINE DEPENDENT (md)
implmd.scm defs for implementation dependencies (mostly whtspc ch codes)
spmd.scm control stack/control point funs
xusermd.scm cross syntaxer user interface (pathname and string funs)
coldmd.scm first scm code runs early, builds obarray, fixed obj vector
runmd.scm loads compiled code for runtime system
MISCELLANEOUS
bgraph.scm bobcat (starbase) graphics interface
emacs.scm emacs interface to scheme system
future.scm part of butterfly basic band load (atom macros)
graphics.scm graphics system interface (draw-line,line styles, etc)
process.scm interface to unix primitives (signal,spawn,wait,pause,etc)
qsort.scm a scheme quicksort
sample.scm shows how microcode C funs are linked into scheme
unix.scm unix scheme interface (cwd,mkdir,kill-eol,getenv,etc)
6.001 Course
login.scm student login/logout utils
logout.scm student logout utils (resets 6.001 student environment)
namelist.scm machine names for 6.001 lab
EXAMPLES
chapter1.cod Scheme code from text by Abelson & Sussman,
chapter2.cod Structure and Interpretation of Computer Programs
chapter3.cod
chapter5.cod
chapter4.cod
PROBLEM SETS (mostly related to SICP)
adventure.scm a game
compiler.scm simple scheme compiler (see Struc & Interp of Comp Progms)
eceval.scm explicit control evaluator (see SICP)
ecevsyn.scm expr & env defs used by explicit ctl eval (see SICP)
regsim.scm register machine simulator (see SICP)
ps4.scm huffman encoding funs
ps5.scm basic generic math funs (ints,polys,rationals, see SICP)
ps6.scm imaginary world defs (deans,trolls,etc)
ps7.scm stream utils
ps8eval.scm evaluator funs for explicit ctl evaluator (see SICP)
ps8mods.scm environment, binding utils (see SICP)
ps8putget.scm put/get procs (see SICP)
ps9data.scm database for query language interpreter (see SICP)
ps9query.scm query language interpreter (see SICP)
ps10load.scm program loader
∂05-Apr-88 1304 @MC.LCS.MIT.EDU:SCHREQ@AI.AI.MIT.EDU test message, ignore
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Apr 88 13:04:46 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Apr 88 16:01:17 EDT
Date: Tue, 5 Apr 88 16:02:28 EDT
From: Scheme Requestee <SCHREQ@AI.AI.MIT.EDU>
Subject: test message, ignore
To: scheme@MC.LCS.MIT.EDU
Message-ID: <353958.880405.SCHREQ@AI.AI.MIT.EDU>
Weeding out bad addresses again, and testing many new additions.
If a long time (several weeks) goes by and you haven't received any
scheme mail, this is probably because you've been removed from the list.
The policy is ruthless: addresses that are unreachable even once are
generally removed from the list.
∂05-Apr-88 1908 @MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Apr 88 19:08:33 PDT
Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 5 Apr 88 22:05:50 EDT
Received: by rutgers.edu (5.54/1.15) with UUCP
id AA02295; Tue, 5 Apr 88 20:26:04 EDT
Received: by mimsy.UMD.EDU (smail2.5)
id AA29519; 5 Apr 88 20:12:37 EDT (Tue)
Received: from watmath.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA03924; Tue, 5 Apr 88 19:55:41 EDT
Received: from csc.uucp by watmath; Tue, 5 Apr 88 19:51:10 EDT
Received: by csc.UUCP (smail2.5)
id AA03303; 5 Apr 88 21:32:55 EST (Tue)
Received: from calgary.uucp by watmath; Fri, 1 Apr 88 19:55:03 EST
Received: from vaxb by calgary.UUCP (5.51/3.1x)
id AA15372; Fri, 1 Apr 88 17:55:54 MST
Received: by vaxb.LOCAL (5.51/2.1i)
id AA15368; Fri, 1 Apr 88 17:55:49 MST
Message-Id: <8804020055.AA15368@vaxb.LOCAL>
Date: Fri, 1 Apr 88 17:55:49 MST
From: Kevin Jameson <uunet!utai!calgary!vaxb!jameson@rutgers.edu>
To: scheme@mc.lcs.mit.edu
This is a test message mailed from the usenet to scheme@mc.lcs.mit.edu to
see if it gets forwarded from the Internet to comp.lang.scheme on the
usenet.
∂05-Apr-88 1937 @MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Apr 88 19:37:19 PDT
Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 5 Apr 88 22:06:16 EDT
Received: by rutgers.edu (5.54/1.15) with UUCP
id AA02298; Tue, 5 Apr 88 20:26:07 EDT
Received: by mimsy.UMD.EDU (smail2.5)
id AA29522; 5 Apr 88 20:12:40 EDT (Tue)
Received: from watmath.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA03929; Tue, 5 Apr 88 19:55:49 EDT
Received: from csc.uucp by watmath; Tue, 5 Apr 88 19:51:38 EDT
Received: by csc.UUCP (smail2.5)
id AA03325; 5 Apr 88 21:33:25 EST (Tue)
Received: from calgary.uucp by watmath; Fri, 1 Apr 88 19:55:03 EST
Received: from vaxb by calgary.UUCP (5.51/3.1x)
id AA15372; Fri, 1 Apr 88 17:55:54 MST
Received: by vaxb.LOCAL (5.51/2.1i)
id AA15368; Fri, 1 Apr 88 17:55:49 MST
Message-Id: <8804020055.AA15368@vaxb.LOCAL>
Date: Fri, 1 Apr 88 17:55:49 MST
From: Kevin Jameson <uunet!utai!calgary!vaxb!jameson@rutgers.edu>
To: scheme@mc.lcs.mit.edu
This is a test message mailed from the usenet to scheme@mc.lcs.mit.edu to
see if it gets forwarded from the Internet to comp.lang.scheme on the
usenet.
∂06-Apr-88 1652 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU forwarded message from Clyde Camp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Apr 88 16:52:01 PDT
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 6 Apr 88 19:53:25 EDT
Received: by MURREN.AI.MIT.EDU; Wed, 6 Apr 88 19:56:19 edt
Date: Wed, 6 Apr 88 19:56:19 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8804062356.AA06370@murren>
To: rrrs-authors@mc
Subject: forwarded message from Clyde Camp
Reply-To: hal@ai.ai.mit.edu
Date: Wed, 6 Apr 88 16:43:41 CDT
From: Clyde Camp <camp@mips.csc.ti.com>
To: hal@mc.lcs.mit.edu
Cc: camp@mips.csc.ti.com
In-Reply-To: Hal Abelson's message of Tue, 5 Apr 88 21:16:17 edt <8804060116.AA05307@murren>
Subject: Scheme
OOPS -
I sent Chris a status message to forward to the group, but it
evidently never got to him (or he hasn't forwarded it yet). So will
you please forward this to the net for me.
The ballot was sent out this morning (I got the foil updates yesterday
from Chris) and I requested results back by the 22nd. Chris did not
send the article, but it is not really needed for the ballot and I was
running out of time to allow time for response. It will be needed
before June.
- Clyde
Date: Mon, 4 Apr 88 11:44:27 EST
From: camp
To: iuvax!chaynes@EE.ECN.PURDUE.EDU
CC: camp@csc.ti.com
In-reply-to: Chris Haynes's message of Tue, 29 Mar 88 12:10:43 EST <8803291746.AA26210@ee.ecn.purdue.edu>
Subject: one more thing
Chris, please forward this to the authors for me. The enclosures
referred to are the 1-2 page article and whatever updates to the foils
you wish to make.
- Clyde
=============================
I finally (after several volleys of telephone ping-pong) talked with
Andrew Salem, Director of Standards for the IEEE. He has no problems
with the plan we proposed - specifically that the Scheme community
churns out RnRS documents at some (non-specified) rate and that
selected versions become the basis from which the IEEE standard is
developed. The IEEE retains copyright to the standard while the
Scheme community retains copyright (or lack thereof) to the report.
He felt that this was entirely appropriate. Although he also
questioned why the community would want to retain the report after the
standard was published, he had no problems with its doing so.
With that potential problem being a non-problem, we are ready to
start. I have the mail ballot ready to go and will send it out as
soon as I get the enclosures from Chris. The current voting
membership is 34, so I need to get back at least 26 returns with at
least 20 positive votes to get the PAR request in by the May 1st
deadline. Assuming that it passes, there will probably be no need for
anyone to attend the May meeting.
I enjoyed meeting all of you who attended the March 26 meeting and I
look forward to a continued relationship.
Regards,
Clyde
∂08-Apr-88 1544 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standarization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Apr 88 15:44:26 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 8 Apr 88 18:41:34 EDT
Received: by iuvax.cs.indiana.edu; id AA13722; Fri, 8 Apr 88 11:08:49 EST
Received: by iuvax.cs.indiana.edu (iuvax/MX/4.5/02-10-87)
id AA13722; Fri, 8 Apr 88 11:08:49 EST
Date: Fri, 8 Apr 88 11:08:49 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: Scheme standarization
On March 25, 1988, a majority of the authors of the "Revised↑3 Report
on the Algorithmic Language Scheme" (SIGPLAN Notices, December, 1986),
together with representatives of IEEE and X3 standardization
committees, met at Indiana University as a study group to consider
initiation of a formal standardization effort for Scheme. It was
concluded that a formal standard was desirable to improve code
portability, publication uniformity, and language visibility. It was
recommended that a PAR be submitted through the IEEE Microprocessor
Standards Committee to initiate the formal standardization effort and
establish a Scheme Working Group. Christopher Haynes and William
Clinger were nominated for Chair and Vice-Chair of the Working Group,
respectively. It is expected that the Working Group will meet
approximately twice a year, with the first meeting to be held on July
27, 1988, following the ACM Conference on Lisp and Functional
Programming at Snowbird, Utah.
The study group felt strongly that the informal group that produced
the existing Scheme reports should continue its language design work
by holding workshops and publishing further revised reports. While
these reports are likely to form the basis for future revisions of the
standard, they will probably be less conservative than is appropriate
for a standards document and may, for example, include experimental
features that should be withheld from standardization.
The study group also concluded that Scheme standardization does
not conflict in any way with existing or contemplated standardization
efforts for other members of the Lisp family, such as X3J13. It was
recommended that liaison be maintained with these efforts, and in
particular that the views of the Scheme community be taken into
account by the ANSI delegate to the ISO ISLISP standardization
meetings, and that an observer from the Scheme community be present at
such meetings if possible.
-- Chris Haynes
chaynes@iuvax.cs.indiana.edu
∂09-Apr-88 0911 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu emacs/scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Apr 88 09:11:33 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 9 Apr 88 12:09:01 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA15847; Sat, 9 Apr 88 06:59:31 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Apr 88 23:41:59 GMT
From: decvax!sunybcs!ugwiles@ucbvax.Berkeley.EDU (Dale Wiles)
Organization: SUNY/Buffalo Computer Science
Subject: emacs/scheme
Message-Id: <10040@sunybcs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Has any one run into any problems using scheme and Emacs. When
I try to use scheme (MIT v 10) and emacs (v 18) I get the header with
no prompt and can send functions in. But when I get an error, and it
drops me to level 2, I can't get back up to level 1.
When I remove the "-emacs" option from "run-scheme" then
everything seems to work unless I send a region to the scheme process.
Only the first function is entered, and then some times it locks up.
If anyone has fixxed this problem, let me know.
Thanks;
Dale Wiles.
∂10-Apr-88 2052 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Bibliography database (BIB/REFER format)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Apr 88 20:52:10 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 10 Apr 88 23:50:58 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA17748; Sun, 10 Apr 88 19:35:44 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Apr 88 20:04:40 GMT
From: pacbell!att-ih!alberta!mnetor!utzoo!yunexus!oz@ames.arpa (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme Bibliography database (BIB/REFER format)
Message-Id: <399@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
BIB/REFER Database on SCHEME
The posting contains is a reasonable bibliography database on Scheme
(a *crystal* in the muddy language landscape), in BIB/REFER format,
containing 50 entries sorted by date and first author, for your
perusal, corrections and enjoyment. I do not consider it complete
nor correct, but I am posting it nevertheless to get some feedback,
new entries, corrections etc.
It is somewhat surprising that such a bib database has not been made
available earlier, so I had to borrow + steal (:-) some entries from
on-line documents, and did a lot of typing.
In this database, I have tried to keep the entries very
Scheme-specific, but I am not certain about some of the entries, as
I have not yet been able to track them.
[Speaking of *tracking references*, the most critical MIT tech
reports are also the hardest to get a hold of... I still do not have
a copy of the "RABBIT" report. I kinda wonder why MIT folks never
put these tech reports into a collection book, and publish it thru
MIT press. It would be a great service to the Scheme/Lisp community.]
-------------------------------------------------------------------
Along with this posting, I am volunteering to keep this database
up-to-date (hopefully with your help) for the benefit of this
newsgroup. I will also a post pre-formatted version as well as a
bibTeX version of the database once corrections and missing entries
are in. [Please send all corrections, new entries, etc. via e-mail]
-------------------------------------------------------------------
Happy Scheming...
oz
Usenet: ....utzoo!yunexus!oz
....!uunet!mnetor!yunexus!oz
Bitnet: oz@[yulibra|yuyetti]
Phonet: +1 416 736-5257x3976
-----cut here-----cut here-----cut here-----cut here-----
#!/bin/sh
# shar: Shell Archiver
# Run the following text with /bin/sh to create:
# scheme.bib
# tags.doc
# This archive created: Sun Apr 10 15:48:21 1988
echo shar: extracting scheme.bib '(9125 characters)'
sed 's/↑XX//' << \SHAR_EOF > scheme.bib
XX
XX%A John Reynolds
XX%T Definitional Interpreters for Higher Order Programming Languages
XX%J ACM Conference Proceedings
XX%P 717-740
XX%I ACM
XX%D 1972
XX
XX%A Gerald Jay Sussman
XX%A Guy Lewis Steele, Jr.
XX%T Scheme: an Interpreter for Extended Lambda Calculus
XX%R MIT Artificial Intelligence Memo 349
XX%C Cambridge, Mass.
XX%D December 1975
XX
XX%A Guy Lewis Steele, Jr.
XX%A Gerald Jay Sussman
XX%T Lambda, the Ultimate Imperative
XX%R MIT Artificial Intelligence Memo 353
XX%C Cambridge, Mass.
XX%D March 1976
XX%K imperative
XX
XX%A Guy Lewis Steele, Jr.
XX%T Lambda, the Ultimate Declarative
XX%R MIT Artificial Intelligence Memo 379
XX%C Cambridge, Mass.
XX%D November 1976
XX%K declarative
XX
XX%A Guy Lewis Steele, Jr.
XX%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call
XXImplementations Considered Harmful, or LAMBDA, the Ultimate GOTO
XX%J ACM Conference Proceedings
XX%P 153-162
XX%I ACM
XX%D 1977
XX
XX%A Guy Lewis Steele, Jr.
XX%T Macaroni is Better than Spaghetti
XX%J Proceedings of the Symposium on Artificial Intelligence and
XXProgramming Languages
XX%P 60-66
XX%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64.
XX%D August 1977
XX
XX%A Mitchell Wand
XX%T Continuation-Based Program Transformation Strategies
XX%J Journal of the ACM
XX%V 27
XX%N 1
XX%P 174-180
XX%D 1978
XX
XX%A Guy Lewis Steele, Jr.
XX%A Gerald Jay Sussman
XX%T The Revised Report on Scheme, a Dialect of Lisp
XX%R MIT Artificial Intelligence Memo 452
XX%C Cambridge, Mass.
XX%D January 1978
XX
XX%A Guy Lewis Steele, Jr.
XX%T Rabbit: a Compiler for Scheme
XX%R MIT Artificial Intelligence Laboratory Technical Report 474
XX%C Cambridge, Mass.
XX%D May 1978
XX
XX%A Guy Lewis Steele, Jr.
XX%A Gerald Jay Sussman
XX%T The Art of the Interpreter, or the Modularity Complex
XX(parts zero, one, and two)
XX%R MIT Artificial Intelligence Memo 453
XX%C Cambridge, Mass.
XX%D May 1978
XX%K modularity
XX
XX%A Drew McDermott
XX%T An Efficient Environment Allocation Scheme in an Interpreter
XXfor a Lexically-Scoped Lisp
XX%J Conference Record of the 1980 Lisp Conference
XX%P 154-162
XX%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
XX%D 1980
XX%O Proceedings reprinted by ACM
XX
XX%A Steven S. Muchnick
XX%A Uwe F. Pleban
XX%T A Semantic Comparison of Lisp and Scheme
XX%J Conference Record of the 1980 Lisp Conference
XX%P 56-65
XX%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
XX%D 1980
XX
XX%A Guy Lewis Steele, Jr.
XX%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
XX%B AI: An MIT Perspective
XX%E Patrick Henry Winston
XX%E Richard Henry Brown
XX%I MIT Press
XX%C Cambridge, Mass.
XX%D 1980
XX
XX%A Guy Lewis Steele, Jr.
XX%A Gerald Jay Sussman
XX%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism
XX%J Conference Record of the 1980 Lisp Conference
XX%P 163-172
XX%I The Lisp Conference
XX%D 1980
XX
XX%A Mitchell Wand
XX%T Continuation-Based Multiprocessing
XX%J Conference Record of the 1980 Lisp Conference
XX%P 19-28
XX%I The Lisp Conference
XX%D 1980
XX
XX%A Guy Lewis Steele, Jr.
XX%A Gerald Jay Sussman
XX%T Design of a Lisp-based Processor
XX%J CACM
XX%V 23
XX%N 11
XX%P 628-645
XX%D November 1980
XX
XX%A Gerald Jay Sussman
XX%A Jack Holloway
XX%A Guy Lewis Steele, Jr.
XX%A Alan Bell
XX%T Scheme-79 - Lisp on a Chip
XX%J IEEE Computer
XX%V 14
XX%N 7
XX%P 10-21
XX%D July 1981
XX%I IEEE
XX
XX%A John Batali
XX%A Edmund Goodhue
XX%A Chris Hanson
XX%A Howie Shrobe
XX%A Richard M. Stallman
XX%A Gerald Jay Sussman
XX%T The Scheme-81 Architecture - System and Chip
XX%J Proceedings, Conference on Advanced Research in VLSI
XX%P 69-77
XX%E Paul Penfield, Jr.
XX%C Artech House, Dedham MA.
XX%D 1982
XX%K scheme81
XX
XX%A Peter Henderson
XX%T Functional Geometry
XX%J Conference Record of the 1982 ACM Symposium on Lisp and
XXFunctional Programming
XX%P 179-187
XX%D 1982
XX
XX%A Jonathan A. Rees
XX%A Norman I. Adams
XX%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool
XX%J Conference Record of the 1982 ACM Symposium on Lisp and
XXFunctional Programming
XX%P 114-122
XX%D 1982
XX
XX%A Carol Fessenden
XX%A William Clinger
XX%A Daniel P. Friedman
XX%A Christopher T. Haynes
XX%T Scheme 311 version 4 Reference Manual
XX%R Computer Science Technical Report 137
XX%I Indiana University
XX%D February 1983
XX%O Superceded by Computer Science Technical Report 153, 1985
XX
XX%A William Clinger
XX%T The Scheme 311 compiler: An Exercise in Denotational Semantics
XX%J Conference Record of the 1984 ACM Symposium on Lisp and
XXFunctional Programming
XX%P 356-364
XX%D 1984
XX%K comp311
XX
XX%A Daniel P. Friedman
XX%A Christopher T. Haynes
XX%A Eugene E. Kohlbecker
XX%T Programming with Continuations
XX%B Program Transformation and Programming Environments
XX%P 263-274
XX%E P. Pepper
XX%I Springer-Verlag
XX%D 1984
XX
XX%A Christopher T. Haynes
XX%A Daniel P. Friedman
XX%T Engines Build Process Abstractions
XX%J Conference Record of the 1984 ACM Symposium on Lisp and
XXFunctional Programming
XX%P 18-24
XX%D 1984
XX
XX%A Christopher T. Haynes
XX%A Daniel P. Friedman
XX%A Mitchell Wand
XX%T Continuations and Coroutines
XX%J Conference Record of the 1984 ACM Symposium on Lisp and
XXFunctional Programming
XX%P 293-298
XX%D 1984
XX
XX%A Jonathan A. Rees
XX%A Norman I. Adams
XX%A James R. Meehan
XX%T The T manual, fourth edition
XX%I Yale University Computer Science Department
XX%D January 1984
XX
XX%A Guillermo J. Rozas
XX%T Liar, an Algol-like Compiler for Scheme
XX%I S. B. Thesis, MIT Department of Electrical Engineering and Computer
XXScience
XX%D January 1984
XX
XX%T MIT Scheme Manual, Seventh Edition
XX%I Department of Electrical Engineering and Computer Science, MIT
XX%C Cambridge, Mass.
XX%D September 1984
XX
XX%T MacScheme Reference Manual
XX%I Semantic Microsystems
XX%C Sausalito, Calif.
XX%D 1985
XX
XX%A Harold Abelson
XX%A Gerald Jay Sussman
XX%A Julie Sussman
XX%T Structure and Interpretation of Computer Programs
XX%I MIT Press
XX%C Cambridge, Mass.
XX%D 1985
XX%K sicp
XX
XX%A Amitabh Srivastava
XX%A Don Oxley
XX%A Aditya Srivastava
XX%T An (other) Integration of Logic and Functional Programming
XX%J Proceedings of the Symposium on Logic Programming
XX%P 254-260
XX%I IEEE
XX%D 1985
XX
XX%E William Clinger
XX%T The Revised Revised Report on Scheme, or An Uncommon Lisp
XX%R MIT Artificial Intelligence Memo 848
XX%C Cambridge, Mass.
XX%O Also published as Computer Science Department Technical Report 174,
XXIndiana University, June 1985.
XX%D August 1985
XX%K rrrs
XX
XX%A Daniel P. Friedman
XX%A Christopher T. Haynes
XX%T Constraining Control
XX%J Proceedings of the Twelfth Annual Symposium on Principles of
XXProgramming Languages
XX%P 245-254
XX%I ACM
XX%D January 1985
XX
XX%A Daniel P. Friedman
XX%A Christopher T. Haynes
XX%A Eugene E. Kohlbecker
XX%A Mitchell Wand
XX%T Scheme 84 Interim Reference Manual
XX%R Computer Science Technical Report 153
XX%I Indiana University
XX%D January 1985
XX%K scheme84
XX
XX%T TI Scheme Language Reference Manual
XX%I Texas Instruments, Inc.
XX%O Preliminary version 1.0
XX%D November 1985
XX
XX%A Michael A. Eisenberg
XX%T Bochser: An Integrated Scheme Programming System
XX%R MIT Computer Science Technical Report 349
XX%C Cambridge, Mass.
XX%D October 1985
XX%K bochser
XX
XX%A David H. Bartley
XX%A John C. Jensen
XX%T The Implementation of PC Scheme
XX%J Proceedings of the 1986 ACM Conference on Lisp
XXand Functional Programming
XX%P 86-93
XX%D 1986
XX%K pcscheme
XX
XX%A R. Kent Dybvig
XX%A Daniel P. Friedman
XX%A Christopher T. Haynes
XX%T Expansion-Passing style: Beyond Conventional Macros
XX%J Proceedings of the 1986 ACM Conference on Lisp and
XXFunctional Programming
XX%P 143-150
XX%D 1986
XX
XX%A Marc Feeley
XX%A Guy LaPalme
XX%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE
XX%O Submitted for Publication. Not yet available.
XX%D 1986
XX
XX%A Matthias Felleisen
XX%A Daniel P. Friedman
XX%T A Closer Look At Export and Import Statements
XX%J Computer Languages
XX%V 11
XX%N 1
XX%P 29-37
XX%I Pergamon Press
XX%D 1986
XX
XX%A Matthias Felleisen
XX%A Daniel P. Friedman
XX%A Eugene E. Kohlbecker
XX%A Bruce Duba
XX%T Reasoning with Continuations
XX%J Proceedings of the Symposium on Logic in Computer Science
XX%P 131-141
XX%I IEEE Computer Society Press
XX%C Washigton DC
XX%D 1986
XX
XX%A Christopher T. Haynes
XX%A Daniel P. Friedman
XX%A Mitchell Wand
XX%T Obtaining Coroutines With Continuations
XX%J Computer Languages
XX%V 11
XX%N 3/4
XX%P 143-153
XX%I Pergamon Press
XX%D 1986
XX
XX%A Mitchell Wand
XX%T From Interpreter to Compiler: A Representational Derivation
XX%B Programs as Data Objects
XX%I Springer-Verlag Lecture Notes
XX%D 1986
XX
XX%A Eugene E. Kohlbecker
XX%T Syntactic Extensions in the Programming Language Lisp
XX%I PhD thesis, Indiana University
XX%D August 1986
XX
XX%A Christopher T. Haynes
XX%T Logic Continuations
XX%J Proceedings of the Third International Conference on
XXLogic Programming
XX%P 671-685
XX%I Springer-Verlag
XX%D Jul 1986
XX
XX%A David Kranz
XX%A Richard Kelsey
XX%A Jonathan A. Rees
XX%A Paul Hudak
XX%A James Philbin
XX%A Norman I. Adams
XX%T Orbit: An Optimizing Compiler for Scheme
XX%T Proceedings of the SIGPLAN '86 Symposium on Compiler
XXConstruction
XX%P 219-233
XX%I ACM
XX%O Published as SIGPLAN Notices 21(7), July 1986
XX%D June 1986
XX%K orbit
XX
XX%A Marc Feeley
XX%T Deux Approches a' L'implantation du Language Scheme
XX%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
XXOpe'rationelle, University of Montreal
XX%D May 1986
XX
XX%A R. Kent Dybvig
XX%T The Scheme Programming Language
XX%I Prentice-Hall, Inc.
XX%C Englewood Cliffs, New Jersey
XX%D 1987
XX%K splang
XX
XX%A Marc Feeley
XX%A Guy LaPalme
XX%T Using Cloures for Code Generation
XX%J Computer Languages
XX%V 12
XX%N 1
XX%P 47-66
XX%I Pergamon Press
XX%D 1987
XX
XX%A Daniel P. Friedman
XX%A Matthias Felleisen
XX%T The Little LISPer
XX%I MIT Press
XX%D Trade Edition 1987
XX%K littlelisper
SHAR_EOF
if test 9125 -ne "`wc -c scheme.bib`"
then
echo shar: error transmitting scheme.bib '(should have been 9125 characters)'
fi
echo shar: extracting tags.doc '(422 characters)'
sed 's/↑XX//' << \SHAR_EOF > tags.doc
XXBIB (UofArizona) Field Tags
XX
XX%A - Author's name
XX%B - Title of the book containing item
XX%C - City of publication
XX%D - Date
XX%E - Editor(s) of book containing item
XX%F - Caption
XX%G - Government (NTIS) ordering number
XX%I - Issuer (publisher)
XX%J - Journal name
XX%K - Keys for searching
XX%N - Issue number
XX%O - Other information
XX%P - Page(s) of article
XX%R - Technical report number
XX%S - Series title
XX%T - Title
XX%V - Volume number
SHAR_EOF
if test 422 -ne "`wc -c tags.doc`"
then
echo shar: error transmitting tags.doc '(should have been 422 characters)'
fi
# End of shell archive
exit 0
--
... and they will all Usenet: [decvax|ihnp4]!utzoo!yunexus!oz
bite the dust ... ......!seismo!mnetor!yunexus!oz
comprehensively. ... Bitnet: oz@[yusol|yulibra|yuyetti]
Archbishop Tutu Phonet: +1 416 736-5257 x 3976
∂18-Apr-88 0629 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA SchemeTeX---Simple support for literate programming in Lisp.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Apr 88 06:28:54 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Apr 88 09:28:13 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA25051; Mon, 18 Apr 88 09:23:05 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Mon, 18 Apr 88 09:22:39 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA11583; Mon, 18 Apr 88 09:22:39 EDT
Date: Mon, 18 Apr 88 09:22:39 EDT
Message-Id: <8804181322.AA11583@darwin.sun.uucp>
To: scheme@mc.lcs.mit.edu, texhax@score.stanford.edu
Subject: SchemeTeX---Simple support for literate programming in Lisp.
SchemeTeX provides simple support for literate programming in any
dialect of Lisp on Unix. Originally created for use with Scheme, it
defines a new source file format which may be used to produce LaTeX
code or Lisp code. Roughly speaking, LaTeX formats Lisp code in a
verbatum-like environment, and it formats Lisp comments in an ordinary
environment.
SchemeTeX is available via anonymous FTP from linus (192.12.120.51) in
the shar file named "pub/schemeTeX.sh". Included is an operating
system independent version for the T dialect of Lisp.
John
∂19-Apr-88 0021 @MC.LCS.MIT.EDU:gleicher@cs.duke.edu Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 88 00:20:55 PDT
Received: from duke.cs.duke.edu (TCP 20033306001) by MC.LCS.MIT.EDU 19 Apr 88 01:57:08 EDT
Received: by duke.cs.duke.edu (5.54/DUKE/10-20-87)
id AA11938; Tue, 19 Apr 88 00:13:04 EDT
Date: Tue, 19 Apr 88 00:13:04 EDT
From: Michael Gleicher <gleicher@cs.duke.edu>
Message-Id: <8804190413.AA11938@duke.cs.duke.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme Implementation for Macintosh 2
has anyone ported Cscheme to the mac 2?
Or any other Public domain scheme (or T for that matter)?
Thanks,
Mike
Michael Lee Gleicher (-: If it looks like I'm wandering
Duke University (-: around like I'm lost . . .
E-Mail: gleicher@cs.duke.edu)(or uucp (-:
Or P.O.B. 5899 D.S., Durham, NC 27706 (-: It's because I am!
∂19-Apr-88 0905 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 88 09:05:15 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 19 Apr 88 12:04:23 EDT
Date: Tue 19 Apr 88 11:59:15-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Scheme Implementation for Macintosh 2
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12391721505.50.MKATZ@A.ISI.EDU>
I also would like to know about any ports of Cscheme to either the Mac 2 or
any other Unix system 5 rel 2 machine. I was about to send mail on this topic
this morning when I found that someone had beaten me to it by 1 day.
Morry Katz
-------
∂20-Apr-88 0129 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Scheme on SysVr2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 01:29:16 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 Apr 88 04:15:50 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 20 Apr 88 04:10:54 EDT
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 7251; Wed, 20 Apr 88 04:10:51 EDT
Date: Wed, 20 Apr 88 10:07:24 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Comment: CROSSNET mail via MAILER@MITVMA
Subject: Scheme on SysVr2
Date: 20 April 1988, 09:57:22 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
There is a lot of questions about CScheme port on SystemVr2:
I have 5.3 running on our Vanilla 5.2 (certified by AT&T).
It is UTS/V running on a IBM 3090-200.
I had little problem doing it, much less than some other according to
what I know.
CScoops runs on it, the Gabriel benchmarks too, with one slight exception
that I have to work on.
I have 6.1, but did not get the time to have it compiled yet.
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂20-Apr-88 0932 @MC.LCS.MIT.EDU:mimsy!cvl!dolqci!irs3!spl1!richp1!richsun!craig@rutgers.edu Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 09:32:14 PDT
Received: from rutgers.edu (TCP 20001402007) by MC.LCS.MIT.EDU 20 Apr 88 12:29:36 EDT
Received: by rutgers.edu (5.54/1.15) with UUCP
id AA16677; Wed, 20 Apr 88 11:20:08 EDT
Received: by mtune.ATT.COM (smail2.6)
id AA24825; 20 Apr 88 11:05:16 EDT (Wed)
Received: by ihnp4.ATT.COM id AA23663; 20 Apr 88 09:11:56 CDT (Wed)
Received: by richp1.UUCP (smail2.5)
id AA06493; 20 Apr 88 09:45:06 EST (Wed)
Received: by richsun.uucp (3.2/SMI-3.2)
id AA00346; Wed, 20 Apr 88 08:38:48 CDT
Date: Wed, 20 Apr 88 08:38:48 CDT
From: moss!ihnp4!richsun!craig@att.arpa (Craig Peterson (consultant))
Message-Id: <8804201338.AA00346@richsun.uucp>
To: MKATZ@trout.nosc.mil
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: <12391721505.50.MKATZ@A.ISI.EDU> (ihnp4!ucsd!A.ISI.EDU!ll-xn!MKATZ@trout.nosc.mil)
Subject: Scheme Implementation for Macintosh 2
Posted-Date: Tue 19 Apr 88 11:59:15-EDT
Date: Tue 19 Apr 88 11:59:15-EDT
From: Morris Katz <ihnp4!ucsd!A.ISI.EDU!ll-xn!MKATZ@trout.nosc.mil>
I also would like to know about any ports of Cscheme to either the Mac 2 or
any other Unix system 5 rel 2 machine. I was about to send mail on this topic
this morning when I found that someone had beaten me to it by 1 day.
Morry Katz
-------
I've ported it to System VR2. I've tried to contact the people at mit
to let them know so that they can integrate it into future releases,
but haven't had any success.
Let me know if you'd like the diffs, and I'll try to put them together.
craig@richp1.UUCP
∂20-Apr-88 1149 @MC.LCS.MIT.EDU:eric%s3landrew@scubed.ARPA Read Macros in PC-Scheme??
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 11:49:47 PDT
Received: from SCUBED.ARPA (TCP 30004010106) by MC.LCS.MIT.EDU 20 Apr 88 14:48:59 EDT
Received: from s3landrew (s3landrew.ARPA) by SCUBED.ARPA (1.2/5.20b)
id AA14154; Wed, 20 Apr 88 11:47:02 pdt
Received: by s3landrew (3.2/5.20b)
id AA12958; Wed, 20 Apr 88 11:46:31 PDT
Date: Wed, 20 Apr 88 11:46:31 PDT
From: eric%s3landrew@scubed.ARPA (Eric Kennedy)
Message-Id: <8804201846.AA12958@s3landrew>
To: scheme@mc.lcs.mit.edu
Cc: eric%s3landrew@scubed.ARPA
Subject: Read Macros in PC-Scheme??
Does anyone know if it is possible to define new read macros in
TI's PC-Scheme?
Sincerely,
eric@scubed.arpa
Eric Kennedy
S-CUBED
3398 Carmel Mountain Road
San Diego, CA 92121
(619) 453-0060
∂20-Apr-88 1234 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Is there a new version of T ?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 12:34:14 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Apr 88 15:00:23 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA23501; Tue, 19 Apr 88 14:41:00 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Apr 88 18:02:33 GMT
From: cos!duc@uunet.uu.net (Duc Kim Nguyen)
Organization: Corporation for Open Systems, McLean, VA
Subject: Is there a new version of T ?
Message-Id: <1455@cos.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is there a new version of T being distributed from Yale ?
The version 3 of source we got was not buildable, and the
instruction was very weak.
I would appreciate any help and info.
cheers
duc@COS.COM
∂20-Apr-88 2027 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu On Beyond Abelson & Sussman
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 20:26:54 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 20 Apr 88 23:26:48 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA03646; Wed, 20 Apr 88 01:38:44 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Apr 88 08:34:11 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.Berkeley.EDU (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Subject: On Beyond Abelson & Sussman
Message-Id: <23666@ucbvax.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I've read Abelson & Sussman's "Structure and Interpretation of Computer
Programs." Great book. Do you have any suggestions for what I should read
now to take the next steps in:
1.) constraint propoagation systems
2.) logic programming
3.) ?
--- David Phillip Oster --When you asked me to live in sin with you
Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
∂20-Apr-88 2335 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Lisp according to one Pascal programmer
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 88 23:35:31 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 21 Apr 88 01:08:45 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA23209; Wed, 20 Apr 88 15:20:55 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Wed, 20 Apr 88 15:20:15 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA13737; Wed, 20 Apr 88 15:20:15 EDT
Date: Wed, 20 Apr 88 15:20:15 EDT
Message-Id: <8804201920.AA13737@darwin.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: Lisp according to one Pascal programmer
Normally, I avoid reading journals with the name of a programming
language in their title whenever the journal is about that programming
language. Those journals tend to contain disappointing articles.
My curiousity was peeked by an article by Morteza Marzjarani called "A
Comparison of the Computer Languages Pascal, C, Lisp, and Ada" in the
Journal of Pascal, Ada, & Modula-2, Vol. 7, No. 1, pp. 5-10, 1988.
What would someone from that journal say about Lisp?
Turning to the reference list of Marzjarani's article, I noticed the
only Lisp reference was Abelson and Sussman's "Structure and
Interpretation of Computer Programs". I concluded the dialect of Lisp
for comparison was Scheme.
Turning to the main text I found that Lisp is not block structured,
and "LISP has two data types only, ATOM and LIST" {p. 6}. Did you
know that "An A-list (association list) represents referencing
environment. That is referencing in LISP is strictly according to the
most recent association rule via searching the A-list from beginning
to end for an entry whose CAR is the atom we are searching for."? {p. 7}
Features of LISP include {p. 8}
"Explicit garbage collection",
"No data structures",
"Explicit sequencing is eliminated;
instead function calls are used",
"Two reserved words only (T,NIL)",
"Linked lists and property list (represented as a special
case of linked lists) form the basic data structures", and
"Most LISP output is automatic. For each function call the
system prints out the function name, its arguments, and
the value returned by the function".
Somehow, I think Morteza doesn't know how to turn of tracing in his
Lisp and has never opened Abelson and Sussman's book.
John
∂21-Apr-88 0010 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 00:10:22 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 01:44:40 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA06387; Wed, 20 Apr 88 04:20:34 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 20 Apr 88 01:24:14 GMT
From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vince Manis)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: Re: Scheme Implementation for Macintosh 2
Message-Id: <2100@ubc-cs.UUCP>
References: <12391721505.50.MKATZ@A.ISI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
MacScheme is alleged to run on the Mac 2 (I haven't seen it). According
to the documentation for version 1.5, it runs ok, though there are apparently
some rough edges. MacScheme comes with a really good native-code compiler.
Publisher is Semantic Microsystems, in Portland.
There is also an implementation called XScheme, which is still under
development. The author is David Betz, who wrote XLisp. It uses a bytecoded
interpreter, so it's not wildly fast, but it is highly portable. Versions
exist for PC, Atari ST, and Mac. I've read the code for the prerelease
Mac version that's on BIX, and I'd expect it to run ok on a Mac 2. (No
toolbox support, though). XScheme is intended as a tool for experimentation,
not a production system (don't try to run Macsyma on it!), but it *is*
free.
Vincent Manis | manis@cs.ubc.ca
The Invisible City of Kitezh | manis@cs.ubc.cdn
Department of Computer Science | manis@ubc.csnet
University of British Columbia | {ihnp4!alberta,uw-beaver,uunet}!
| ubc-cs!manis
<<NOTE NEW ADDRESS>>
∂21-Apr-88 1030 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu C Scheme Documentation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 10:30:18 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 13:09:08 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA04126; Thu, 21 Apr 88 07:31:48 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 88 10:46:31 GMT
From: imagine!pawl23.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam)
Organization: RPI Public Access Workstation Lab - Troy, NY
Subject: C Scheme Documentation
Message-Id: <749@imagine.PAWL.RPI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Two questions...
We have MIT C scheme here, and it is not exactly as described in
R↑3 Report on Scheme. This is certainly OK by me as long as I know
what is in it. But I dont. T'other day i was trying to do something
and failing miserably because i couldnt find something - I think it
was named-lambda - not in R↑3, but used all over the place in the
scheme code. Eventually, i figured out (after a couple DAYS! of
poking around) that "(enable-language-features)" turned it on, but
how was anyone supposed to know that from the C scheme source or
documentation? Anyway, im looking for a manual - not SICP - but a
real manual - one with lists of functions and what they do.
Lacking this, i was trying to browse through the Scheme source and
executable to find what i needed. One of the problems seems to be
that scheme has no "apropos" which might have helped. (Actually
the problem is worse since im trying to get things to work on an
IBM running MTS where everything is protected and i cant even figure
out what has been loaded.) Is there any way to browse environments -
that is, to locate environments and then to see what they have defined
in them?
Or am I going about this in the completely wrong way?
jeff putnam
jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu
"People would rather believe a simple lie than the complex truth."
∂21-Apr-88 1121 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Engines/SCOOPS in T?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 11:20:49 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 13:40:52 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA05921; Thu, 21 Apr 88 08:58:16 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 88 02:35:22 GMT
From: hp-pcd!uoregon!markv@hplabs.hp.com (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: Engines/SCOOPS in T?
Message-Id: <1856@uoregon.uoregon.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anyone have an implementation of Chris Haynes Engines facilities
written for T? While I am at it, how about an implementation of SCOOPS?
I am currently using T to do research in functional programming, and
would like to use these facilities.
Thank you...
Mark VandeWettering
markv@cs.uoregon.edu \ Mark Terrence VandeWettering
University of Oregon \ ..!tektronix!uoregon!markv
Computer Science Dept. \ Life...the final frontier...
∂21-Apr-88 1448 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 14:47:55 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 21 Apr 88 17:46:01 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 21 Apr 88 15:13:04 EDT
Received: by kali.think.com; Thu, 21 Apr 88 15:13:00 EDT
Date: Thu, 21 Apr 88 15:13:00 EDT
From: gls@Think.COM
Message-Id: <8804211913.AA20292@kali.think.com>
To: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Vince Manis's message of 20 Apr 88 01:24:14 GMT <2100@ubc-cs.UUCP>
Subject: Scheme Implementation for Macintosh 2
Date: 20 Apr 88 01:24:14 GMT
From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vince Manis)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
References: <12391721505.50.MKATZ@A.ISI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
MacScheme is alleged to run on the Mac 2 (I haven't seen it). According
to the documentation for version 1.5, it runs ok, though there are apparently
some rough edges. MacScheme comes with a really good native-code compiler.
Publisher is Semantic Microsystems, in Portland.
...
I run MacScheme on a Mac II all the time. It works fine. (The version
of Toolsmith that I have does not interface to all the new routines in
Volume V of "Inside Macintosh"--I obtained Toolsmith before Volume V had
even been published--but this aside I have been very happy with it.
I have done nontrivial Toolbox hacking to do some nifty dialog boxes.)
My wife Barbara has implemented at least one full-blown, double-clickable
application in MacScheme, and uses the resulting application routinely.
--Guy Steele
∂21-Apr-88 1548 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 15:48:07 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 18:37:59 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA10001; Thu, 21 Apr 88 11:47:01 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 88 17:10:26 GMT
From: apatosaur.cis.ohio-state.edu!verber@TUT.CIS.OHIO-STATE.EDU (Mark Verber)
Organization: Ohio State University, Computer Science
Subject: Re: Scheme Implementation for Macintosh 2
Message-Id: <11244@tut.cis.ohio-state.edu>
References: <12391721505.50.MKATZ@A.ISI.EDU>, <2100@ubc-cs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
From my experience MacScheme runs very happily on a MacII. The guys
from Semantics (and Will Clinger) did a go job following the Apple
rules. I will also run under Multi-finder in the background and under
A/UX using the toolboxdeamon. Note: Stand alone applications
generated via the native code compiler also run on the MacII and under
A/UX.
----------------------------------------------------------------------
Mark A. Verber MaBell: 614-292-7344
Computer Science Department MX: verber@cis.ohio-state.edu
Ohio State University DUMB: verber@ohio-state.arpa
2036 Neil Ave, Columbus, Ohio 43210 UUCP: ..!att!osu-cis!verber
∂21-Apr-88 2032 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where to mail bugs?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 20:32:48 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 21 Apr 88 23:21:43 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA12257; Thu, 21 Apr 88 13:54:13 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 88 18:21:40 GMT
From: sunybcs!ugwiles@boulder.colorado.edu (Dale Wiles)
Organization: SUNY/Buffalo Computer Science
Subject: Where to mail bugs?
Message-Id: <10423@sunybcs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anyone know the e-mail address to send bugs about
MIT's C-Scheme to? The address in the source code is
"BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me.
Thanks in advance:
Dale (ug) Wiles
∂21-Apr-88 2339 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Where to mail bugs?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Apr 88 23:39:02 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 22 Apr 88 00:38:56 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Fri, 22 Apr 88 00:33:18 edt
Date: Fri, 22 Apr 88 00:33:18 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8804220433.AA15204@chamarti>
To: sunybcs!ugwiles@boulder.colorado.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Dale Wiles's message of 21 Apr 88 18:21:40 GMT <10423@sunybcs.UUCP>
Subject: Where to mail bugs?
Reply-To: jinx@zurich.ai.mit.edu
Does anyone know the e-mail address to send bugs about
MIT's C-Scheme to? The address in the source code is
"BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me.
The correct address is BUG-CSCHEME%oz@mc.lcs.mit.edu
∂22-Apr-88 2216 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Followup to Stoy's book?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Apr 88 22:16:13 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Apr 88 00:18:11 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA02063; Fri, 22 Apr 88 08:41:26 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 88 14:46:32 GMT
From: mcvax!enea!liuida!kjepo@uunet.uu.net (Kjell Post)
Organization: CIS Dept, Univ of Linkoping, Sweden
Subject: Followup to Stoy's book?
Message-Id: <791@butterix.liu.se>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Maybe this isn't the right group but here goes:
Are there any plans on a revised edition of
Joe Stoy's "Denotational Semantics" (MIT Press) ?
The reason I'm asking is because the book is out
of print (according to our local bookstore).
Any other recommendations for books in this and
adjacents areas?
--
-------------------------------------------------------------------------------
(Y F) = (F (Y F)) |Dept of Comp&Info Science, Linkoping Sweden
"This super-amazing, clever thing" | kjepo@majestix.liu.se
- G.J. Sussman _|_ ...liuida!majestix.liu.se!kjepo
∂22-Apr-88 2249 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Apr 88 22:49:18 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 23 Apr 88 00:36:11 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA25783; Tue, 19 Apr 88 17:01:14 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 Apr 88 21:30:45 GMT
From: rochester!ur-tut!hwfe@rutgers.edu (Harlan Feinstein)
Organization: Univ. of Rochester Computing Center
Subject: Re: Scheme Implementation for Macintosh 2
Message-Id: <1861@ur-tut.UUCP>
References: <12391721505.50.MKATZ@A.ISI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <12391721505.50.MKATZ@A.ISI.EDU> MKATZ@A.ISI.EDU (Morris Katz) writes:
>I also would like to know about any ports of Cscheme to either the Mac 2 or
>any other Unix system 5 rel 2 machine. I was about to send mail on this topic
>this morning when I found that someone had beaten me to it by 1 day.
> Morry Katz
>-------
I'm wondering if CScheme could run on an IBM PC. If anyone has done this
could you send me email? 'ppreciate it.
Disclaimer:
If what I say seems wrong or offends you, consider this: I'm writing in my
own language, not English, and it's coincidence that it looks like English.
------------------------------------------------------------------------------
"_The_ Zaphod Beeblebrox?" "Count the heads."
Harlan Feinstein U U RRRR hwfeccss@uorvm.bitnet
Student, University of Rochester U U RRRR hwfe@tut.cc.rochester.edu
"We are... U R!" UUUU R R seismo!rochester!ur-tut!hwfe
------------------------------------------------------------------------------
∂23-Apr-88 2239 @MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU small scheme implementation.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Apr 88 22:38:50 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 24 Apr 88 01:37:40 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7)
id AA29495; Sun, 24 Apr 88 01:32:16 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA28440; Sun, 24 Apr 88 01:33:18 edt
Date: Sun, 24 Apr 88 01:33:18 edt
From: gjc%bucsf.bu.edu@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8804240533.AA28440@bucsf>
To: scheme@mc.lcs.mit.edu
Subject: small scheme implementation.
I have done a demonstration implementation called SIOD, "Scheme In One
Defun" originally in zetalisp, but now in C. A reasonable effort was
made to keep the size and complexity down. The result is one file
under 20 thousand bytes.
Features:
* (double) floating pointer numbers, +,-,*,/,>,<,eql
* symbols, oblist
* lists, cons,car,cdr,setcar,setcdr, assq, copy-list, eq.
* define,set!,lambda,quote,if,progn
* garbage collection, (copy style), heap size fixed on startup.
* control-c quit interrupt, floating point exception handler.
* Ran on 4.2BSD and VAX/VMS
It is very easy to add new subrs and special forms (e.g. cons-stream),
which I plan to do, up to 5000 bytes worth. The current version is
available by anonymous ftp from bu-it.bu.edu in /pub/siod.c
I hope the small size and straightfoward implementation make it
easy for interested parties to port it to their microcomputers.
Let me know if you have any problems.
The implementation is moderately fast, with (fib 20) on an Encore
Multimax taking 3.5 times longer in Cscheme than in SIOD. On a
SUN4-280 SIOD did (fib 20) in 4.1 seconds, consing about 100 thousand cells.
N.B. I like to time fib with:
(define (fib x) (if (< x 2) x (+ (fib (- x 1)) (fib (- x 2)))))
-gjc
∂24-Apr-88 1313 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu collect macro
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Apr 88 13:13:43 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 24 Apr 88 16:12:25 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA25523; Sun, 24 Apr 88 08:29:13 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 23 Apr 88 13:30:53 GMT
From: mcvax!enea!tut!jh@uunet.uu.net (Juha Hein{nen)
Organization: Tampere University of Technology, Finland
Subject: collect macro
Message-Id: <3200@korppi.tut.fi>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Has anyone written the collect macro from Abelson&Sussman in
extend-syntax or in some other macro notation?
--
Juha Heinanen, Tampere Univ. of Technology, Finland
jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
∂25-Apr-88 1933 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU SIOD release 1.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 88 19:33:32 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 25 Apr 88 22:27:09 EDT
Return-Path: <gjc@bu-it.bu.edu>
Received: by bu-it.BU.EDU (4.0/4.7)
id AA13520; Mon, 25 Apr 88 22:21:35 EDT
Date: Mon, 25 Apr 88 22:21:35 EDT
From: gjc@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8804260221.AA13520@bu-it.BU.EDU>
To: scheme@mc.lcs.mit.edu
Subject: SIOD release 1.1
Well, Barak.Pearlmutter@DOGHEN.BOLTZ.CS.CMU.EDU sent me a couple fixes
including a full flonum recognizer, so while I was putting these into
the source I figured, what the heck, add a case tc_symbol: to
the switch on TYPE(tmp) in the evaluator and boom, you have macros.
Then, if you can write macros you can add syntax for things like
delay, and cons-stream. Then you want to put these goodies into a file,
so you want to have load. Then why not (the-environment) and add
a couple special forms like and, or, let, if you are going
to actually write a program or two? Then I realized I had left out
predicates like consp and numberp.
Then with all this stuff you better write a siod.doc file, and actually
make sure the thing compiles and runs on all the nearby systems.
Release 1.1 SIOD is now in three files,
siod.c 25k bytes
siod.doc 21k bytes
siod.scm 2k bytes
Same system, same anonymous ftp, same directory. Enjoy!
Some people without FTP access have asked for me to mail them the file,
which is now three files. Perhaps someone can suggest a proper list
on which to do some kind of POSTING of this code? Any experienced
posters out there?
-gjc
∂26-Apr-88 0510 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET SIOD 1.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 05:10:23 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Apr 88 08:10:52 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Tue, 26 Apr 88 08:05:15 EDT
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 7892; Tue, 26 Apr 88 08:05:13 EDT
Date: Tue, 26 Apr 88 14:04:43 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Comment: CROSSNET mail via MAILER@MITVMA
Subject: SIOD 1.1
Date: 26 April 1988, 14:00:54 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
I got siod 1.1 , compile it on a Unix System Vr2 (UTS/V on a IBM 3090),
and IT IS working.
My timing for the simple naive (fib 20) is around 0.8 seconds.
(Cscheme 5.3 is around 2.1 seconds.)
Now I will try to understand the code.
Thank you for this exercise.
Regards,
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂26-Apr-88 1435 SCHREQ@MC.LCS.MIT.EDU Cross mailing between UseNet and the ArpaNet
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 14:35:45 PDT
Date: Tue, 26 Apr 88 17:34:50 EDT
From: Scheme Requestee <SCHREQ@MC.LCS.MIT.EDU>
Subject: Cross mailing between UseNet and the ArpaNet
To: ramsdell@LINUS.UMD.EDU
cc: SCHEME@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 18 Apr 88 07:12:28 EDT from John D. Ramsdell <ramsdell%linus at mitre-bedford.ARPA>
Message-ID: <411485.880426.SCHREQ@MC.LCS.MIT.EDU>
Date: Mon, 18 Apr 88 07:12:28 EDT
From: John D. Ramsdell <ramsdell%linus at mitre-bedford.ARPA>
Did you get the UseNet to ArpaNet connection working? If so, please
tell the rest of us so we know if we no longer need to send our
contributions to MIT.
It is my understanding that mail is forwarded in both directions,
without danger of divergence. Submissions to comp.lang.scheme will go
to scheme@mc, and vice versa. I believe we have Eric Fair at Berkeley
to thank for this somewhat miraculous achievement.
∂26-Apr-88 1525 ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88 15:25:11 PDT
Date: Tue, 26 Apr 88 18:20:20 EDT
From: Oliver Laumann <hplabs!pyramid!tub!net at rutgers.edu>@MC.LCS.MIT.EDU
Sender: SCHREQ@MC.LCS.MIT.EDU
Subject: ``Update functions'' in Scheme.
To: SCHEME@MC.LCS.MIT.EDU
Message-ID: <411492.880426.SCHREQ@MC.LCS.MIT.EDU>
Date: Fri, 8 Apr 88 17:55:27 +0200
From: Oliver Laumann <hplabs!pyramid!tub!net at rutgers.edu>
To: scheme-request at mc.lcs.mit.edu
Re: ``Update functions'' in Scheme.
Did anybody already think about adding ``generalized functions''
(a la Common-Lisp's setf/defsetf feature) to Scheme? This would
eliminate the need for several primitive procedures, among them
set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing
(set-car! p 5) or (vector-set! v 10 'a)
this would make it possible to write
(set! (car p) 5) or (set! (vector-ref v 10) 'a)
accordingly. Of course, in implementations that support ``fluid-let''
one would also have to extend fluid-let to accept the new syntax.
But how should users be able to define their own ``update functions''?
Yes, I know the concept of ``settable operations'' of T, but unfortunately
they are based on T's object oriented features. And I don't like the
setf/defsetf concept of Common Lisp, because the accessor function and
the update function have to be separate functions (if I understood it right).
Consider the following example:
I would like to be able to write a ``print-length'' procedure which,
when called outside a set! form, returns the current ``print length''
(whatever this may be), and, when called as ``(set! (print-length) 10)'',
sets the print length to 10. Ideally, only *one* function should be
involved -- this function both knows how to return the current print
length and how to set it to a new value.
I could imagine something like this:
(define print-length
(let ((len 100))
(lambda (&update flag &optional val)
(if flag
... ; set len to val (possibly with sanity-check)
len))))
When called from within a set! form (that is, as an update function),
``flag'' would be true, otherwise false (called as accessor function).
Now I can't come up with a satisfying syntax; the above &update kludge
should only illustrate the concept (i.e. the function "knows" if it
should act as accessor or update function).
A coworker suggests adding a different lambda (which he jokingly
called ``mikro'') that contains two parameter lists and two body
forms, e.g.
(define print-length
(let ((len 100))
(mikro () len ; accessor
(val) (something a la set! len val)))) ; updater
Does anybody else think that a feature like this would be useful?
What kind of syntax (not involving ugly &foo keys -- Scheme currently
does not yet have any of them) could actually be used for this?
--
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
...!mcvax!unido!tub!net
∂27-Apr-88 1109 ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 11:09:42 PDT
Date: Wed, 27 Apr 88 14:03:41 EDT
From: Oliver Laumann <hplabs!pyramid!tub!net at rutgers.edu>@MC.LCS.MIT.EDU
Sender: SCHREQ@MC.LCS.MIT.EDU
Subject: ``Update functions'' in Scheme.
To: SCHEME@MC.LCS.MIT.EDU
Message-ID: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>
Date: Fri, 8 Apr 88 17:55:27 +0200
From: Oliver Laumann <hplabs!pyramid!tub!net at rutgers.edu>
To: scheme-request at mc.lcs.mit.edu
Re: ``Update functions'' in Scheme.
Did anybody already think about adding ``generalized functions''
(a la Common-Lisp's setf/defsetf feature) to Scheme? This would
eliminate the need for several primitive procedures, among them
set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing
(set-car! p 5) or (vector-set! v 10 'a)
this would make it possible to write
(set! (car p) 5) or (set! (vector-ref v 10) 'a)
accordingly. Of course, in implementations that support ``fluid-let''
one would also have to extend fluid-let to accept the new syntax.
But how should users be able to define their own ``update functions''?
Yes, I know the concept of ``settable operations'' of T, but unfortunately
they are based on T's object oriented features. And I don't like the
setf/defsetf concept of Common Lisp, because the accessor function and
the update function have to be separate functions (if I understood it right).
Consider the following example:
I would like to be able to write a ``print-length'' procedure which,
when called outside a set! form, returns the current ``print length''
(whatever this may be), and, when called as ``(set! (print-length) 10)'',
sets the print length to 10. Ideally, only *one* function should be
involved -- this function both knows how to return the current print
length and how to set it to a new value.
I could imagine something like this:
(define print-length
(let ((len 100))
(lambda (&update flag &optional val)
(if flag
... ; set len to val (possibly with sanity-check)
len))))
When called from within a set! form (that is, as an update function),
``flag'' would be true, otherwise false (called as accessor function).
Now I can't come up with a satisfying syntax; the above &update kludge
should only illustrate the concept (i.e. the function "knows" if it
should act as accessor or update function).
A coworker suggests adding a different lambda (which he jokingly
called ``mikro'') that contains two parameter lists and two body
forms, e.g.
(define print-length
(let ((len 100))
(mikro () len ; accessor
(val) (something a la set! len val)))) ; updater
Does anybody else think that a feature like this would be useful?
What kind of syntax (not involving ugly &foo keys -- Scheme currently
does not yet have any of them) could actually be used for this?
--
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
...!mcvax!unido!tub!net
∂27-Apr-88 1607 @MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU SIOD release 1.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 16:07:09 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 27 Apr 88 18:23:58 EDT
Received: by GENEVA.AI.MIT.EDU; Wed, 27 Apr 88 12:54:17 edt
Date: Wed, 27 Apr 88 12:54:17 edt
From: jrm@GENEVA.AI.MIT.EDU (Joe Marshall)
Message-Id: <8804271654.AA12980@geneva>
To: gjc@bu-it.BU.EDU
Cc: scheme@mc.lcs.mit.edu
Subject: SIOD release 1.1
Hi, George. What's up?
∂27-Apr-88 1923 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM R3RS number syntax
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 19:22:54 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 27 Apr 88 22:03:42 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 88 17:30:44 PDT
Date: Wed, 27 Apr 88 17:30:37 PDT
From: Pavel.pa@Xerox.COM
Subject: R3RS number syntax
To: scheme@mc.lcs.mit.edu
Message-ID: <880427-173044-6364@Xerox>
I have a few questions about the syntax of numbers in R3RS Scheme:
1. The sequence of characters ``#x3e4'' has two very different parses. The
question is whether or not the ``e'' is a digit or the exponent marker. What is
intended here?
2. What is the meaning of the exponent part when the radix is not 10? My guess
was that ``#O3E4'' meant 3 times 8 to the 4th, but C-Scheme, at least, treats
this as 3 times 10 to the 4th. I can guess from the syntax that the digits of
the exponent are always in radix 10 (since the base 10 digits are all that's
allowed there), but what is the base for the exponentiation? I thought it would
be more useful if the exponentiation base was the same as the number radix (so
that, for example, I could say #b1E20 to make a mask that has only bit 20 turned
on).
3. Does ``3/4e5'' mean the same as ``75000'' or ``.0000075''? That is, is the
exponent intended to apply to the entire rational ``3/4'' or just to the
denominator?
4. Does ``123##.##'' mean anything different from ``12300'' when read? Or does
it really mean the same as ``#i12300''?
5. I assume that the syntax ``3@4'' is meant to denote the complex number with
magnitude 3 and angle 4, but this isn't actually said anywhere in the document.
The same goes for the (assumed rectangular) notation ``3+4i'', though it's more
clear in that case. I had to infer the meaning from an example in the
description of number-printing formats.
It would really be nice if R4RS were to include a formal semantics for the
syntax of numbers. I realize that some issues (such as whether or not such a
literal is exact) are intended to be implementation-dependent, but I think that
there could be a semantics that defined the mathematical number that each input
syntax is intending to represent (perhaps the semantic function should return an
interval of the reals for each expansion of the <real> nonterminal in the
grammar).
Pavel
∂27-Apr-88 1952 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Proposals for R4RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 19:52:05 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 27 Apr 88 22:03:57 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 88 17:47:40 PDT
Date: Wed, 27 Apr 88 17:47:33 PDT
From: Pavel.pa@Xerox.COM
Subject: Proposals for R4RS
To: RRRS-Authors@mc.lcs.mit.edu
Message-ID: <880427-174740-6396@Xerox>
1. It would be nice if R4RS provided the simplest possible support for a
portable implementation of hash-tables. As far as I can tell, the only things
required are two procedures:
EQ-HASH object
Returns an integer with the property that (EQ? a b) implies (= (EQ-HASH a)
(EQ-HASH b)). Implementations are encouraged to make the converse true as well
in as many cases as possible.
EQV-HASH object
Returns an integer with the property that (EQV? a b) implies (= (EQV-HASH a)
(EQV-HASH b)). Implementations are encouraged to make the converse true as well
in as many cases as possible.
I think that with these as primitives, one can portably write the corresponding
EQUAL-HASH procedure and essentially any other equivalence-relation hashing
function. Thus, this appears to be sufficient for an efficient implementation
of hashing, working in terms of normal vectors.
Note that no ``unhash'' procedures are provided, so none of the difficulties
that caused OBJECT-HASH and OBJECT-UNHASH to be removed exist here.
2. Is there any reason not to make ``.'' and ``{'' and ``}'' extended alphabetic
characters? Dot, in particular, is useful for EXTEND-SYNTAX implementations or
other things in that style. Perhaps someone could simply explain the criteria
for inclusion in or exclusion from that extended alphabetic characters list?
Comments?
∂27-Apr-88 2212 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme Implementation for Macintosh 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Apr 88 22:11:55 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Apr 88 01:01:39 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA09164; Tue, 26 Apr 88 18:50:34 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 Apr 88 17:30:21 GMT
From: mcvax!unido!fauern!faui44!msurlich@uunet.uu.net (Matthias Urlichs )
Organization: CSD., University of Erlangen, W - Germany
Subject: Re: Scheme Implementation for Macintosh 2
Message-Id: <246@soni.UUCP>
References: <8804190413.AA11938@duke.cs.duke.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8804190413.AA11938@duke.cs.duke.edu> gleicher@CS.DUKE.EDU (Michael Gleicher) writes:
>has anyone ported Cscheme to the mac 2?
I transferred r2 to MPW C and ran it thru Gnu-CP and MPW C (its preprocessor
wouldn't accept CScheme's #define's; too many levels) without much
difficulty. But no toolbox etc. support yet as I don't know much (read that as
"anything") about the internal organization of CScheme, eg where to put your
own REP interface, how to put in output to windows, ...
I probably will do that if/when there's time (right now there isn't) and
if I get pointers to more detailed information about CScheme.
--
Matthias Urlichs CompuServe: 72437,1357 Delphi: URLICHS
Rainwiesenweg 9
8501 Schwaig 2 "Violence is the last refuge
West Germany of the incompetent." -- Salvor Hardin
∂28-Apr-88 0247 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where to mail bugs?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 02:47:48 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 28 Apr 88 05:45:04 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA07188; Wed, 27 Apr 88 17:50:41 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 Apr 88 03:19:33 GMT
From: rochester!ur-tut!joss@cu-arpa.cs.cornell.edu (Josh Sirota)
Organization: Univ. of Rochester, Computing Center
Subject: Re: Where to mail bugs?
Message-Id: <1881@ur-tut.UUCP>
References: <10423@sunybcs.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <10423@sunybcs.UUCP> ugwiles@sunybcs.UUCP (Dale Wiles) writes:
> Does anyone know the e-mail address to send bugs about
>MIT's C-Scheme to? The address in the source code is
>"BUG-CSCHEME%OZ@MC.LCS.MIT" but our postmaster bounced it back to me.
bug-cscheme%oz@mc.lcs.mit.edu ... Somehow you must have it stripped.
Josh
--
Josh Sirota
INTERNET: joss@tut.cc.rochester.edu BITNET: joss_ss@uordbv.bitnet
ur-tut!joss@cs.rochester.edu UUCP: ...!rochester!ur-tut!joss
∂28-Apr-88 0844 @MC.LCS.MIT.EDU:sdawkins%hpda@hplabs.HP.COM delete from list
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 08:43:59 PDT
Received: from hplabs.HP.COM (TCP 1777610007) by MC.LCS.MIT.EDU 28 Apr 88 11:17:22 EDT
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Thu, 28 Apr 88 07:12:19 PST
Received: from hpda.HP.COM (hpda.itg.hp.com) by hplms2.HP.COM; Thu, 28 Apr 88 08:12:01 pdt
Received: by hpda.HP.COM; Thu, 28 Apr 88 08:14:12 pdt
Message-Id: <8804281514.AA13365@hpda.HP.COM>
To: scheme@mc.lcs.mit.edu
Subject: delete from list
Date: Thu, 28 Apr 88 08:14:07 PDT
From: Scott Dawkins <sdawkins%hpda@hplabs.HP.COM>
Hi,
The scheme mailing list includes "cire@hpda" or perhaps "cire@hplabs".
Anyway, Eric Decker (cire) has left the company. Please delete him from the
scheme mailing list.
Thanks,
Scott Dawkins
sdawkins@hpda.hp.com
Technical Data Center Manager
HP - Information Technology Group
(408) 447 - 6963
∂28-Apr-88 1957 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU SIOD release 1.2 (28-APR-88).
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Apr 88 19:56:54 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 28 Apr 88 22:55:41 EDT
Return-Path: <gjc@bu-it.bu.edu>
Received: by bu-it.BU.EDU (4.0/4.7)
id AA02291; Thu, 28 Apr 88 22:49:52 EDT
Date: Thu, 28 Apr 88 22:49:52 EDT
From: gjc@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8804290249.AA02291@bu-it.BU.EDU>
To: scheme@mc.lcs.mit.edu
Cc: tower@bu-it.bu.edu
Subject: SIOD release 1.2 (28-APR-88).
(1) bug fixed in use of atof for VMS.
(2) compiled and run on AMIGA 500
(3) name changes to conform better to recently published material.
(4) bug in extend_environment fixed.
(5) siod.scm file now has:
* standard-fib procedure for benchmarking
* cons-stream, enumerate-interval, print-stream-elements.
(6) siod.doc file updated to reflect name changes.
Same place, anonymous ftp to bu-it.bu.edu (128.197.20.40 or 128.197.2.40)
and get /pub/siod.*
I have gotten many messages from people who cannot FTP to this machine.
Sorry for not responding yet. Already I have spent more time in MAIL
about this than in the actual Scheme implementation. Thanks to those
who have sent in bug fixes or new features. When I found out how to
post to comp.sources.unix or misc I will do so.
-gjc
∂29-Apr-88 1136 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM TI-scheme on PS/2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Apr 88 11:36:03 PDT
Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 29 Apr 88 14:02:53 EDT
Date: 29 Apr 88 12:29:47 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: scheme@mc.lcs.mit.edu
Message-Id: <042988.122947.alberga@ibm.com>
Subject: TI-scheme on PS/2
I have attempted to run TI-scheme (version 3.0) on a PS/2 model 80 with
4 MB of memory installed, running under DOS 3.3. Scheme does not seem
to recognize any memory above 640 KB. Is this a known condition? If
so, is there a fix?
Cyril N. Alberga
∂29-Apr-88 1733 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Extending the address space of MIT Cscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Apr 88 17:33:19 PDT
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 29 Apr 88 19:12:42 EDT
Received: from A.ISI.EDU (a.isi.edu) by ZURICH.AI.MIT.EDU; Fri, 29 Apr 88 19:06:44 edt
Date: Fri 29 Apr 88 13:03:48-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Extending the address space of MIT Cscheme
To: scheme@ZURICH.AI.MIT.EDU
Message-Id: <12394354697.55.MKATZ@A.ISI.EDU>
In order to effectively use CScheme on modern multiprocessors there is a real
need to extend its 24 bit address space. In the past I have heard two
suggestions for accomplishing this task.
1) Interprest the 24 bits as a word address (object address) rather than a
byte address, effectively increasing the address space by a factor of 4.
(Unfortunately, this requires repeated shifting of addresses on most
processors.)
2) Steal a type code bit and make it part of the address field.
Neither of these solutions is really satisfactory since even in combination
they do not allow one to address even 4M of memory on each of 64 processors.
Does anyone have any other suggestions? I have been considering doubling the
size of Scheme objects to 8 bytes, the first 4 for the type code and the second
4 for the address. This would obviously be quite wasteful of memory, but at
least it would allow me to use the full 32 bit address space of my processors.
How hard do people think it would be to modify CSchemme for such an object
representation? Someone must have a better solution. This sounds real grim.
Morry Katz
-------
∂29-Apr-88 1828 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Questions on Scheme treatment of numbers
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Apr 88 18:28:04 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 29 Apr 88 19:53:40 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA10868; Thu, 28 Apr 88 20:41:50 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Apr 88 00:05:47 GMT
From: spar!freeman@decwrl.dec.com (Jay Freeman)
Organization: SPAR - Schlumberger Palo Alto Research
Subject: Questions on Scheme treatment of numbers
Message-Id: <380@spar.SPAR.SLB.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have been browsing through the R3 report on Scheme, and have
become curious about some aspects of Scheme's treatment of numbers ...
(1) The syntax given for external representations of numbers
appears to require that exponents -- if present -- be in
radix 10, even when the rest of the number has been
explicitly declared to be in binary, octal or hex. My
first reaction was that this is probably an oversight:
Have I overlooked any obvious advantage or misread the
BNF?
(2) I think there is an abiguity in parsing hexadecimal
numbers: E. g., is #x1e2 to be interpreted as one times
sixteen to the power two (= 256), or as 1 * 256 + 14 * 16
+ 2 (= 482). (If so, it is probably best to prefer the
latter interpretation: a user who intends the former
can always provide a "+" sign (#x1e+2).)
(3) It looks as if there is no object foo for which
(number? foo) is #t but (complex? foo) is #f.
This might be a good hook for recognizing IEEE
floating-point INFs, or for other similar overflow
conditions. Any thoughts?
-- Jay Freeman
∂30-Apr-88 1352 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Biblio.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Apr 88 13:52:19 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 30 Apr 88 16:51:44 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA23376; Sat, 30 Apr 88 05:03:54 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 Apr 88 17:16:08 GMT
From: mnetor!spectrix!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme Biblio.
Message-Id: <427@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Many people have sent me additions and corrections for the
bibliography posted several weeks ago. Your help is much appreciated.
Due to my absence for about a month, I will not be able to post an
up-to-date version of this bibliography until June. Until that time,
please do keep sending me any new references suitable to be added to
this scheme-only biblio.
many thanks. oz
--
The deathstar rotated slowly, | Usenet: ...!utzoo!yunexus!oz
towards its target, and sparked | ....!uunet!mnetor!yunexus!oz
an intense sunbeam. The green world | Bitnet: oz@[yulibra|yuyetti]
of unics evaporated instantly... | Phonet: +1 416 736-5257x3976
∂01-May-88 1340 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect macro
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 May 88 13:40:06 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 1 May 88 16:26:19 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA22621; Sun, 1 May 88 04:02:44 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 Apr 88 04:36:10 GMT
From: killer!pollux!ti-csl!mips!gateley@ames.arc.nasa.gov (John Gateley)
Organization: TI Computer Science Center, Dallas
Subject: Re: collect macro
Message-Id: <47466@ti-csl.CSNET>
References: <3200@korppi.tut.fi>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
This might help. It is an extend-syntax version of collect which has not been
tested other than to show that it expands into what looks to be the right
thing. The function nth is just like Common Lisp, if you want to use
list-ref, just switch the order of the two arguments. I use `with' clauses
to help build the let bindings. This is the only complicated feature used.
Hope this helps,
John Gateley
; code starts here
; This just converts (v1 v2 ...) to ((v1 (nth 0 tuple)) (v2 (nth 1 tuple)) ...)
; it should always be called w/ second argument of 0
(define make-v-fun
(lambda (l n)
(cond ((null? l) ())
(t (cons `(,(car l) (nth ,n tuple)) (make-v-fun (cdr l) (+ n 1)))))))
; this guy creates the flatmap expression
(extend-syntax (make-flatmaps) (tuple)
((make-flatmaps ((vn setn)) (v ...))
(map (lambda (vn)
(list v ... vn))
setn))
((make-flatmaps ((vi seti)(vj setj) ...) (v ...))
(flatmap
(lambda (vi)
(make-flatmaps ((vj setj) ...) (v ... vi)))
seti)))
; this is the main guy
(extend-syntax (collect) (tuple)
((collect result ((v1 set1) ...) restriction)
(with ((let-bindings (make-v-fun '(v1 ...) 0)))
(map (lambda (tuple)
(let let-bindings
result))
(filter (lambda (tuple)
(let let-bindings
restriction))
(make-flatmaps ((v1 set1) ...) ()))))))
∂01-May-88 1918 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU siod release 1.3
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 May 88 19:18:43 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 1 May 88 21:49:51 EDT
Return-Path: <gjc@bu-it.bu.edu>
Received: by bu-it.BU.EDU (4.0/4.7)
id AA18536; Sun, 1 May 88 21:48:30 EDT
Date: Sun, 1 May 88 21:48:30 EDT
From: gjc@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8805020148.AA18536@bu-it.BU.EDU>
To: scheme@mc.lcs.mit.edu
Subject: siod release 1.3
In this release the environment representation has been changed from
a simple ALIST to a frame structure made up by consing the formal
argument list with the actual argument list returned by eval_args.
With this representation is is easy to get "define" to work properly.
(It does now). Also included is a vms specific function for calling
the editor within the same address space as the lisp.
Same place, bu-it.bu.edu, /pub, anonymous anonymous.
Those unable to FTP who requested direct mail have been sent four messages
today containing the siod sources and a test message.
This will be the last release before a gc-at-any-time version is available.
I hope people have found this amusing, instructive, or both.
-gjc
∂02-May-88 0302 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu SIOD release 1.1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 May 88 03:02:13 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 May 88 05:57:13 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA07201; Sun, 1 May 88 19:06:29 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 May 88 21:11:52 GMT
From: ubvax!smegma!mdg@ames.arc.nasa.gov (Marc de Groot)
Organization: A moving point in 4-space
Subject: SIOD release 1.1
Message-Id: <379@smegma.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am interested in Scheme, and I know very little about it. I understand
that it is LISP done in a relatively compact, symmetrical, and orderly
way. That is what piqued my interest.
Some questions:
Is SIOD 1.1 a public-domain Scheme? If so, can I get source, and will
it run on my IBM PC/AT (80286 crummy segmented architecture) under
Microport UNIX SVr2?
What are some good books about Scheme and where can I get them?
Thanks in advance.
--
Marc de Groot (KG6KF)
UUCP: {hplabs, sun, ucbvax}!amdcad!uport!smegma!mdg
AMATEUR PACKET RADIO: KG6KF @ KB6IRS
"Look, he's mounting a tape!" "Quick, throw cold water on him!"
∂02-May-88 0332 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: R3RS number syntax
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 May 88 03:32:48 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 2 May 88 05:57:29 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA06911; Sun, 1 May 88 18:39:14 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 May 88 01:28:31 GMT
From: spar!freeman@decwrl.dec.com (Jay Freeman)
Organization: SPAR - Schlumberger Palo Alto Research
Subject: Re: R3RS number syntax
Message-Id: <405@spar.SPAR.SLB.COM>
References: <880427-173044-6364@Xerox>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <880427-173044-6364@Xerox> Pavel.pa@XEROX.COM writes:
>2. What is the meaning of the exponent part when the radix is not 10? My guess
>was that ``#O3E4'' meant 3 times 8 to the 4th,
Mine, too. I always thought of exponents as being merely a
notational convenience for inconveniently-placed radix points.
>4. Does ``123##.##'' mean anything different from ``12300'' when read? Or does
>it really mean the same as ``#i12300''?
I think the system should try to arrange that when it reads
(and evals) something that it printed out, the object created
should be as indistinguishable as possible from the one printed.
(This is of course an impossible goal, if only because you can
always print a number with fewer digits of precision than are
implicit in its internal representation; or because you can
print an inexact "1" as an integer with exactness surpressed.)
I also think the purpose of the "exact" bit is very low-level;
I believe it is intended to flag that all information necessary
to describe a number completely is contained in the particular
bit-pattern that represents the number in store.
If that is true, then the system should NEVER print "#"s
in any representation of an exact number. Thus for example,
if you asked for the exact rational 1/3 to be printed as a
decimal with six million digits of precision, you should get
lots and lots of "3"s, even though no likely internal
representation of a flonum has that much precision.
So if the system prints "123##.##", the number printed
must originally have been inexact. Thus I think the reader
ought to treat "123##.##" as an inexact number.
Don't take me as an authority, I certainly am not!
It seems more natural to me to interpret 3/4e6 as (3/4)e6,
but I certainly don't see anything in the R3 report to require it.
By the way, what does C-Scheme say to "(integer? 1.0)"? To "(integer?
1)"? MacScheme (version 1.51) says the former is false and the latter true;
I think both should be true. (MacScheme does say that "(= 1 1.0)" is true
so I am not just a victim of roundoff.)
-- Jay Freeman
<canonical disclaimer -- these are personal opinions only>
∂02-May-88 1132 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Re: Extending the address space of MIT Cscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 May 88 11:32:03 PDT
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 2 May 88 13:58:04 EDT
Received: from Xerox.COM (xerox.com) by ZURICH.AI.MIT.EDU; Mon, 2 May 88 13:57:35 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 02 MAY 88 10:49:35 PDT
Date: 2 May 88 10:49 PDT
From: Fischer.pa@Xerox.COM
Subject: Re: Extending the address space of MIT Cscheme
In-Reply-To: Morris Katz <MKATZ@A.ISI.EDU>'s message of Fri, 29 Apr 88 13:03:48
EDT
To: MKATZ@A.ISI.EDU
Cc: scheme@ZURICH.AI.MIT.EDU
Message-Id: <880502-104935-3391@Xerox>
Put the type bits at the bottom of the address word. No shift, just mask if
needed. Result: larger 'words.' This technique also used in Smalltalk-80,
immediates were tagged with low order bit, shifted only when needed.
(ron)
∂03-May-88 1121 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 May 88 11:21:32 PDT
Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 3 May 88 14:09:36 EDT
Received: by BASEL.AI.MIT.EDU; Tue, 3 May 88 15:11:14 edt
Date: Tue, 3 May 88 15:11:14 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
Message-Id: <8805031911.AA04352@basel>
To: SCHEME@MC.LCS.MIT.EDU
In-Reply-To: Oliver Laumann's message of Wed, 27 Apr 88 14:03:41 EDT <411493.880427.SCHREQ@MC.LCS.MIT.EDU>
Subject: ``Update functions'' in Scheme.
> Did anybody already think about adding ``generalized functions''
> (a la Common-Lisp's setf/defsetf feature) to Scheme? This would
> eliminate the need for several primitive procedures, among them
> set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing
>
> (set-car! p 5) or (vector-set! v 10 'a)
>
> this would make it possible to write
>
> (set! (car p) 5) or (set! (vector-ref v 10) 'a)
What's so great about SETF? It doesn't eliminate the *need* for
the setting primitives (after all, they conceptually must still
be there); it just makes it easier to remember their "names"
by providing a convention for deriving the setter from the
accessor.
But it's easy to develop alternate naming conventions without
altering Scheme. One simple convention can be carried out
by simple renaming:
(define set!car set-car!)
(define set!cdr set-cdr!)
(define set!vector-ref vector-set!)
(define set!string-ref string-set!)
Here the name of each setter is the name of the accessor prefixed
by set! Now we can write
(set!car p 5) or (set!vector-ref v 10 'a)
which, except for the missing pair of parens, looks a lot like
the SETF approach. And we didn't have to extend Scheme all!
- Lyn -
∂03-May-88 2313 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Extending the address space of MIT Cscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 May 88 23:08:29 PDT
Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 4 May 88 01:33:22 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA01819; Mon, 2 May 88 20:54:03 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 May 88 02:37:53 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
Organization: PASS Research Group
Subject: Re: Extending the address space of MIT Cscheme
Message-Id: <5460@utah-cs.UUCP>
References: <12394354697.55.MKATZ@A.ISI.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <12394354697.55.MKATZ@A.ISI.EDU> MKATZ@A.ISI.EDU (Morris Katz) writes:
>In order to effectively use CScheme on modern multiprocessors there is a real
>need to extend its 24 bit address space.
There is the Spice Lisp technique of divvying up the address space into
areas dedicated to each type, in such a way that they still appear to have
tags. There is also BIBOP or BBOP, in which objects of the same type are
grouped together on a page (as in Franz or Maclisp or Interlisp). Both
techniques would give you a full 32-bit address space, although BBOP may
be more practical for multiprocessing. However, I suspect that either of
these changes would be far too radical for CScheme, whose coding style and
general design/engineering have given MIT a black eye in the Lisp/Scheme
community...
stan shebs
shebs@cs.utah.edu
(Yes, it's a harsh assessment, but does accurately reflect both my own
experiences in trying to understand CScheme, and a number of other people's
feelings as well)
∂04-May-88 0051 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 00:51:34 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 4 May 88 03:45:47 EDT
Received: by kleph.AI.MIT.EDU; Wed, 4 May 88 03:47:10 edt
Date: Wed, 4 May 88 03:47:10 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8805040747.AA21368@kleph>
To: defun.utah.edu!shebs@cs.utah.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Stanley T. Shebs's message of 2 May 88 02:37:53 GMT <5460@utah-cs.UUCP>
Subject: Extending the address space of MIT Cscheme (long reply)
Reply-To: cph@zurich.ai.mit.edu
Date: 2 May 88 02:37:53 GMT
From: defun.utah.edu!shebs@cs.utah.edu (Stanley T. Shebs)
However, I suspect that either of
these changes would be far too radical for CScheme, whose coding style and
general design/engineering have given MIT a black eye in the Lisp/Scheme
community...
(Yes, it's a harsh assessment, but does accurately reflect both my own
experiences in trying to understand CScheme, and a number of other people's
feelings as well)
As you might expect, your statement ruffled my feathers. I'd be
interested in your answers to some questions:
* When you refer to CScheme's "coding style" are you referring to
the portion written in C, the portion written in Scheme, or both?
* How about some specific examples of design/engineering decisions
that you consider flaws, and why?
* Have you seen a lisp of comparable (or greater) functionality
that is significantly better in either respect? Please name it,
and explain why.
* When you refer to "experiences in trying to understand CScheme",
how much of that can be attributed to lack of documentation? Have
you ever tried to understand another program of comparable
complexity?
For example, while I know a great deal about compilers, I would
expect to spend a great deal of time and effort trying to
understand a good one, such as GNU CC. I'd probably get pretty
pissed off at the crummy way that certain things were designed.
But I wouldn't blame this on RMS being a poor programmer. The
real problem is that such a program is so complex that even the
best programmer can't make it perfect.
A general statement like yours is easy to make and can convey false
impressions. I'd rather not have my reputation (and that of my
colleagues) tarnished by vague accusations about the quality of our
work. On the other hand, I welcome specific, well-reasoned criticism.
Here are my views on a few relevant topics:
* By and large, I'm very proud of the part of CScheme that is
implemented in Scheme. I believe that it captures a great deal of
modularity and abstraction, contains many fine symmetries, and in
general is very robust. It also pushes some of our language
technology to the limit: in particular it suffers from the lack of a
good module description facility.
* The part written in C is a very different story. I think alot of
this can be attributed to C itself. Some of it can be attributed to
the fact that most of us in the Scheme group at MIT hate C, and
therefore don't want to do the work that it would take to make it a
beautiful C program. In fact, I'm not sure it would be possible to
make it beautiful, although clearly it could be much much better.
One thing that everyone here has agreed upon: we would all like to
rewrite that C program in Scheme or a nice Scheme-like language if
only the compiler technology were good enough to let us keep the
portability and performance. Well, I think that will be true in
another year or two, and then maybe it will happen.
* We have virtually no documentation. This is obviously a terrible
thing, and we are in fact generating some. But the bottom line for
this is simply lack of time, plus the fact that none of us has much
text writing experience.
It is not widely known that CScheme, along with the Liar compiler, the
Edwin text editor, and a previous 68000-based implementation, have
largely been created by three people over about 5 years. Two of us
had significant other commitments during that time which reduced the
amount of effort that could be devoted to the project. Yet we
generated over a quarter million lines of hairy code in about 10 to 12
person-years. It is only now that our project has expanded to the
point where we feel that time is available for documentation.
* Various representation decisions that we have made have been
criticised at various times. In particular: high tags vs. low tags;
SCode vs. byte code; and more recently, register-based vs. stack-based
calling convention. I can produce reasonable arguments for all of
these decisions. One thing that I have noticed is that the
"community" seems to have preconceptions about some of these
alternatives being better than others. In some cases we've tested
them and found that the "common knowledge" is misleading: often the
performance difference between two of the alternatives is very slight.
* In your message you essentially are criticising us for not being
able to change a fundamental representation decision. I don't believe
this is a valid criticism. I claim that NO implementation in
existence could easily make a large change at that level. Small
changes, on the other hand, are a different matter.
In this particular case, there are a number of things we can easily
do, such as: reduce the size of the type field to reflect the fact
that we only use 6 type bits rather than 8; reduce the number of type
bits by making some of them manifest (we could probably go down to 3
or 4 without much work); or change the addressing from byte granular
to word (or even pair) granular. But a BIBOP-style type
representation is a fundamental change that would require alot of
work. I would be surprised if any system could claim to change
between such radically different representations easily.
In closing: please don't feel that I'm attacking you. I am, however,
trying to defend myself, my colleagues, and our work, against your
rather vague condemnation. I'm sure you have some good reasons for
feeling the way you do and I'd be happy to hear and discuss them. But
please try to be a little more specific. General arguments of this
nature do nothing to improve our software, much less the state of the
art.
∂04-May-88 0808 @MC.LCS.MIT.EDU:mhwu@DUMBO.AI.MIT.EDU More flames about CScheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 08:08:39 PDT
Received: from dumbo (TCP 2206400251) by MC.LCS.MIT.EDU 4 May 88 11:02:51 EDT
Received: by DUMBO.AI.MIT.EDU; Wed, 4 May 88 11:00:47 edt
Date: Wed, 4 May 88 11:00:47 edt
From: mhwu@DUMBO.AI.MIT.EDU (Henry M. Wu)
Message-Id: <8805041500.AA05512@dumbo>
To: cph@zurich.ai.mit.edu
Cc: defun.utah.edu!shebs@cs.utah.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph>
Subject: More flames about CScheme
Reply-To: mhwu%dumbo@mc.lcs.mit.edu
* The part written in C is a very different story. I think alot of
this can be attributed to C itself. Some of it can be attributed to
the fact that most of us in the Scheme group at MIT hate C, and
therefore don't want to do the work that it would take to make it a
beautiful C program. In fact, I'm not sure it would be possible to
make it beautiful, although clearly it could be much much better.
I would like to add a few points:
- If a large C program like CScheme could be "much much" better, I
haven't seen anybody succeed trying to write one. I have certainly
looked at a large amount of C code coming from various sources, and I
claim that CScheme is better than MOST, if not all that I have come
across. This is not to say that CScheme is anywhere near perfect;
it's just that C programs are in general badly written.
- Unlike a lot of C programs, CScheme does try to have SOME
abstraction. Believe it or not, to some people this actually makes
the program harder to understand! This isn't helped by the fact that
a lot of the abstraction is implemented using hairy macros, mainly for
efficiency reasons. My claim is that CScheme isn't "bad", it's just
different.
- A lot of claims about CScheme's so-called "bad design/engineering"
are based not on people's understanding of it's design, but rather the
fact that empirically CScheme is slow, and "so it must be badly
designed". In fact CScheme was never supposed to be fast. All of the
optimizing switches and hacks are defaultly turned off, unlike many
other implementations. One of the main features of CScheme is its
portability, and it is very sucessful in that regard. Some of the
design decisions came from the fact that CScheme evolved from a Scheme
implementation that was a teaching tool, not a [commercial] speedster
for preparing programs for a Cray. But yet I have survived CScheme
INTERPRETING some robust CAD tools, solving large design problems.
These days I can only see CScheme getting faster, with the
introduction of the compiler.
I don't want to sound like I am trying to portray CScheme as this
wonderful piece of software that it isn't. I do feel that making
generalized attacks on issues like coding style is often too easy (and
I guess I just made some myself), while sometimes even those of us
close to the project fail to stop and try to appreciate the amount of
effort put into a very useful tool. I like CScheme.
∂04-May-88 0929 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 09:29:18 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 88 11:28:27 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA10685@BLOOM-BEACON.MIT.EDU>; Wed, 4 May 88 11:24:03 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 3 May 88 19:11:14 GMT
From: BASEL.AI.MIT.EDU!lyn@ucbvax.berkeley.edu (Franklyn Turbak)
Organization: The Internet
Subject: ``Update functions'' in Scheme.
Message-Id: <8805031911.AA04352@basel>
References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
> Did anybody already think about adding ``generalized functions''
> (a la Common-Lisp's setf/defsetf feature) to Scheme? This would
> eliminate the need for several primitive procedures, among them
> set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing
>
> (set-car! p 5) or (vector-set! v 10 'a)
>
> this would make it possible to write
>
> (set! (car p) 5) or (set! (vector-ref v 10) 'a)
What's so great about SETF? It doesn't eliminate the *need* for
the setting primitives (after all, they conceptually must still
be there); it just makes it easier to remember their "names"
by providing a convention for deriving the setter from the
accessor.
But it's easy to develop alternate naming conventions without
altering Scheme. One simple convention can be carried out
by simple renaming:
(define set!car set-car!)
(define set!cdr set-cdr!)
(define set!vector-ref vector-set!)
(define set!string-ref string-set!)
Here the name of each setter is the name of the accessor prefixed
by set! Now we can write
(set!car p 5) or (set!vector-ref v 10 'a)
which, except for the missing pair of parens, looks a lot like
the SETF approach. And we didn't have to extend Scheme all!
- Lyn -
∂04-May-88 1506 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 15:06:01 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 4 May 88 17:58:01 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA11796; Wed, 4 May 88 11:13:43 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02219; Wed, 4 May 88 11:12:23 MDT
Date: Wed, 4 May 88 11:12:23 MDT
From: shebs%defun@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8805041712.AA02219@defun.utah.edu>
To: cph@zurich.ai.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph>
Subject: Re: Extending the address space of MIT Cscheme (long reply)
I suppose I was hoping that the CSchemers felt sufficiently guilty that
they would agree with my remark by their silence - I see this is not the
case!
> * When you refer to CScheme's "coding style" are you referring to
> the portion written in C, the portion written in Scheme, or both?
Primarily the portion written in C. I suppose I could admire the Scheme
portion if I knew why it existed and what the various pieces are supposed
to do (not being a brilliant MIT student, I can't just look at a half-page
long S-expression and comprehend it instantly).
> * How about some specific examples of design/engineering decisions
> that you consider flaws, and why?
Gazillions of builtin types. There are twice as many primitive types of
objects as any other high-level language that I know of (3- and 4-element
hunks? give me a break!). Many could have been built as nonprimitives.
See T for good efforts in that direction.
Attempts to optimize the C code implementing a virtual machine. If you use
a virtual machine, you've already lost speedwise; doing complicated C hacks
isn't going to recover much for you. (Presumably that's the reason for
hundreds of C macros that could have been function calls.)
Writing nonprimitives in C. My eye happened to fall on list_to_string,
which is about three times longer and more complicated in C than in Scheme.
What earthly reason could there be for this? I suppose it could be worse;
KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier
Transform and a regular expression matcher in its C "microcode"...
References to apparent GC in all kinds of strange places. When I followed
them, the trail disappeared in a maze of macros.
References to the compiler and Edwin, thus violating every principle of
abstraction known to exist.
Strange code concerning "MIT ASCII" (that's what it said) vs regular
ASCII characters. Given that CScheme is "portable", why does this get
included in everybody's copy?
There are probably others, I haven't looked at every single one of the
120+ files and 50K+ lines of the C code...
> * Have you seen a lisp of comparable (or greater) functionality
> that is significantly better in either respect? Please name it,
> and explain why.
In the absence of a manual describing the "functionality" of CScheme,
it's impossible to compare it on that basis. I hope there's lots of
functionality, CScheme is larger than commercial Common Lisps (which is
amusing considering how Schemers abuse Common Lisp for its "bloat").
Spice Lisp/CMU Common Lisp has its flaws, but it's better overall (for
one thing, it's smaller!). T/Orbit has better structure and style, but
its documentation is too scanty to recommend. I would say that PSL/PCLS
is cleaner, but I am biased!
> * When you refer to "experiences in trying to understand CScheme",
> how much of that can be attributed to lack of documentation? Have
> you ever tried to understand another program of comparable
> complexity?
Lack of documentation is an unforgivable omission, and is by far my
biggest gripe about CScheme. It shouldn't take two hours to figure
out what kind of garbage collection is being done, or to figure out
what the "danger bit" does. I've worked with many programs on that
scale during my 12 years in computing, and to be fair, most large
programs are difficult to understand, even with documentation (TeX
for instance). This just means that *more* documentation is required,
not less! To put it another way, lesser minds can't be amazed by your
cleverness if they don't even know what's going on...
> For example, while I know a great deal about compilers, I would
> expect to spend a great deal of time and effort trying to
> understand a good one, such as GNU CC. I'd probably get pretty
> pissed off at the crummy way that certain things were designed.
> But I wouldn't blame this on RMS being a poor programmer. The
> real problem is that such a program is so complex that even the
> best programmer can't make it perfect.
A bogus argument - I'm not asking for perfection, but a minimal standard
of quality. There should *at least* be a one-line justification for the
existence of functions and macros.
BTW, I don't want to claim that anyone is a "poor programmer"! A phrase
comes to mind (don't remember from where), that there are only a few
Gandhi-like programmers who are never tempted to write bad code...
>A general statement like yours is easy to make and can convey false
>impressions. I'd rather not have my reputation (and that of my
>colleagues) tarnished by vague accusations about the quality of our
>work. On the other hand, I welcome specific, well-reasoned criticism.
I'm sorry to say it, but your reputation has already been tarnished by
the code you've allowed to travel throughout the world. Hopefully you
prefer to have someone say it to your face (so to speak :-) ) than
behind your back.
>* By and large, I'm very proud of the part of CScheme that is
>implemented in Scheme. I believe that it captures a great deal of
>modularity and abstraction, contains many fine symmetries, and in
>general is very robust. It also pushes some of our language
>technology to the limit: in particular it suffers from the lack of a
>good module description facility.
So why didn't you explain all these "abstractions" and "fine symmetries"?
>* The part written in C is a very different story. I think alot of
>this can be attributed to C itself. Some of it can be attributed to
>the fact that most of us in the Scheme group at MIT hate C, and
>therefore don't want to do the work that it would take to make it a
>beautiful C program. In fact, I'm not sure it would be possible to
>make it beautiful, although clearly it could be much much better.
I find it odd that haters of C would use macros to the extent that CScheme
does. I find it odd that haters of C would write so much of it.
I find it odd that people who are aware of C's problems wouldn't try
to alleviate them by commenting on what the code is up to.
>One thing that everyone here has agreed upon: we would all like to
>rewrite that C program in Scheme or a nice Scheme-like language if
>only the compiler technology were good enough to let us keep the
>portability and performance. Well, I think that will be true in
>another year or two, and then maybe it will happen.
This sounds like a veiled criticism of T and Orbit, since they are portable
and fast. KCL compiles to C code, so it maintains portability at that
level. (Someone could do a great public service by reimplementing KCL
in a less idiosyncratic way - the basic idea is quite sound.)
>* We have virtually no documentation. This is obviously a terrible
>thing, and we are in fact generating some. But the bottom line for
>this is simply lack of time, plus the fact that none of us has much
>text writing experience.
I hear that excuse from froshes, and don't accept it from them either.
Documentation after the fact is inherently inferior, and leaves out
important details that the programmers have forgotten about.
>It is not widely known that CScheme, along with the Liar compiler, the
>Edwin text editor, and a previous 68000-based implementation, have
>largely been created by three people over about 5 years. Two of us
>had significant other commitments during that time which reduced the
>amount of effort that could be devoted to the project. Yet we
>generated over a quarter million lines of hairy code in about 10 to 12
>person-years. It is only now that our project has expanded to the
>point where we feel that time is available for documentation.
Perhaps if you had thought more carefully about what you were doing,
it wouldn't have been necessary to write so much code, and surely five
years is enough time to think about writing more documentation!
Still, I do appreciate where you're coming from - it's something that
professional SEs have to contend with all the time (my own views have
no doubt been colored by one of my first jobs, which was to document
40,000 lines of Fortran written by several other people).
>* Various representation decisions that we have made have been
>criticised at various times. In particular: high tags vs. low tags;
>SCode vs. byte code; and more recently, register-based vs. stack-based
>calling convention. I can produce reasonable arguments for all of
>these decisions. One thing that I have noticed is that the
>"community" seems to have preconceptions about some of these
>alternatives being better than others. In some cases we've tested
>them and found that the "common knowledge" is misleading: often the
>performance difference between two of the alternatives is very slight.
I would like to see the data - there are a huge number of undocumented
claims like this. It is true that if you use a virtual machine, then
a lot of representation decisions are unimportant. In fact, my almost
finished thesis is all about the analysis of representation decisions.
>* In your message you essentially are criticising us for not being
>able to change a fundamental representation decision. I don't believe
>this is a valid criticism. I claim that NO implementation in
>existence could easily make a large change at that level. Small
>changes, on the other hand, are a different matter.
You are almost right. Our new Common Lisp implementation can change
from tags to BBOP to separate spaces, just by changing opencodings.
We can also vary the function protocol in interesting ways. This all
happens in a native code compiler. Admittedly, this wasn't easy, and
it is not yet complete. No publications yet (i.e. Lisp conf paper
rejected), but my thesis will be available shortly, and we do have
some initial reports.
To summarize: CScheme is not incredibly bad, but it is disappointing,
especially given the interest of the Scheme community in simplicity,
modularity, and abstraction. The most serious consequence is that people
interested in learning about Scheme implementation will look at CScheme,
and most likely conclude that people at MIT don't really believe all those
ideas being promulgated in SICP...
stan
∂04-May-88 1622 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: R3RS number syntax
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 16:22:47 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 May 88 18:43:40 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA20874@BLOOM-BEACON.MIT.EDU>; Wed, 4 May 88 18:37:19 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 4 May 88 20:07:47 GMT
From: spar!freeman@decwrl.dec.com (Jay Freeman)
Organization: SPAR - Schlumberger Palo Alto Research
Subject: Re: R3RS number syntax
Message-Id: <475@spar.SPAR.SLB.COM>
References: <880427-173044-6364@Xerox>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <880427-173044-6364@Xerox> Pavel.pa@XEROX.COM writes:
>It would really be nice if R4RS were to include a formal semantics for the
>syntax of numbers.
The more I think about it, the more glaring that omission looks. The
R3 report provides a perfectly adequate BNF for determining whether or
not a particular token represents a number, but provides no hint how
to tell *which* number.
-- Jay Freeman
<canonical disclaimer -- these are personal opinions only>
∂04-May-88 1917 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 19:17:27 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 4 May 88 22:05:08 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Wed, 4 May 88 22:02:40 edt
Date: Wed, 4 May 88 22:02:40 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8805050202.AA29123@chamarti>
To: shebs%defun@cs.utah.edu
Cc: cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Stanley T. Shebs's message of Wed, 4 May 88 11:12:23 MDT <8805041712.AA02219@defun.utah.edu>
Subject: Extending the address space of MIT Cscheme (long reply)
Reply-To: jinx@zurich.ai.mit.edu
I hope the following clarifies the situation somewhat about the
technical/stylistic points you've raised:
> * How about some specific examples of design/engineering decisions
> that you consider flaws, and why?
Gazillions of builtin types. There are twice as many primitive types of
objects as any other high-level language that I know of (3- and 4-element
hunks? give me a break!). Many could have been built as nonprimitives.
See T for good efforts in that direction.
What's wrong with that? It's nice (and ultimately more robust) to
allow the system to distinguish between various objects with 2, 3, or
more components. For example, taken the CAR of a symbol (which in
CScheme has two components) will signal an error. Similarly for other
kinds of objects. Implementations on custom Lisp hardware often
allocate 5 or 6 tag bits so they can accomodate a large number of
primitive types for the same reason.
In the case of T, I suspect that they would do the same if they could
afford the tag bits, but their decision (which I'm not questioning or
criticizing) to use an object representation with low tag bits gives
them very few primitive types, so they had to reduce their number.
Attempts to optimize the C code implementing a virtual machine. If you use
a virtual machine, you've already lost speedwise; doing complicated C hacks
isn't going to recover much for you. (Presumably that's the reason for
hundreds of C macros that could have been function calls.)
You are confusing a few things:
1) Using a virtual machine is a common technique these days to
implement interpreters. We have made no claim that our interpreter
will run code as fast as code produced by native code compilers. Thus
there is no attempt to make the CScheme interpreter run as fast as
anybody else's compiled code. As far as interpreters go, it's not
great, but it's not bad in terms of speed, but provides much more
convenience and ease of debugging than any other interpreter I know.
2) Most of the hairy C and macrology arise not from using a virtual
machine, but from the fact that the PARTICULAR virtual machine we
chose cannot be conveniently written in C without paying an undue
penalty.
The CScheme interpreter is a recoding of an assembly language
interpreter written for the Motorola MC68000 which in turn started out
as an emulator for the Scheme 81 chip. The virtual machine was coded
naturally in assembly language (and Scheme 81 microcode), but cannot
be coded as conveniently in C. We wish we had a portable assembly
language which would allow us to do these things more cleanly and
efficiently, but unfortunately there is no such beast. C comes
closest, but is a far cry from what we would like. As it is, the
assembly language interpreter implementing the same virtual machine is
considerably cleaner and still runs somewhat faster on the same
hardware.
Writing nonprimitives in C. My eye happened to fall on list_to_string,
which is about three times longer and more complicated in C than in Scheme.
What earthly reason could there be for this? I suppose it could be worse;
KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier
Transform and a regular expression matcher in its C "microcode"...
Again, you are ignoring the fact that CScheme is currently an
interpreter based system, rather than a compiler based system. The
trade-offs are pretty different. In the presence of an acceptable
native code compiler one can easily afford to write many utilities in
the language being compiled, but interpreters rarely provide enough
performance. Many Basic interpreters have the same outlook: Most of
the utility procedures are provided as part of the implementation and
written in the implementation language rather than Basic.
Even in the presence of an acceptable native code compiler (which we
now have), there is no good reason to flush this code: The interpreter
can still be used without having to port the compiler (which is a much
harder task than bringing up the interpreter) and may give adequate
performance in educational settings (which was CScheme's only goal in
the first place).
As far as FFT and Regexp search:
- FFT is not part of the standard scheme "microcode". It is part of a
special version of Scheme used in the introductory signals course at
MIT. Since somebody had bothered to write it, we included it in the
release (although it is not loaded by default) so that other people
could use it if they wanted to or were curious. It was written in C
because our interpreter could hardly compete with compiled C, but few
Lisp implementations (if any) can currently match the speed that can
be obtained from C or FORTRAN in numeric code. What's wrong with
coding a commonly used procedure in a language which will make it more
efficient? Please show me a Lisp which can compete with C in this
regard. If you manage to do this, I strongly suspect that the number
of arcane declarations in the Lisp code will make it at least as
unreadable as C, so you're no better off.
- Regexp search: It's written in C because it has been copied almost
verbatim from the similar code in GNU Emacs, written in C. Why bother
rewriting (and debugging) something which we can use directly with
little effort? Note that this code is used only by Edwin, which has
not yet been released, so it's presence in the release is spurious,
and the file which contains it can be dropped from the set of loaded
files since no released code uses it (to my knowledge). On the other
hand, why not make it available so people can use it or read it if
they are curious?
References to apparent GC in all kinds of strange places. When I followed
them, the trail disappeared in a maze of macros.
Hmm. Maybe the Lisps you are used to don't check whether there is
enough space to allocate storage before they go ahead and do it. They
can't be very robust. I'm also surprised that you complain about this
particular "maze". It seems pretty straightforward to me.
References to the compiler and Edwin, thus violating every principle of
abstraction known to exist.
What? Please explain, I don't understand what that means.
Strange code concerning "MIT ASCII" (that's what it said) vs regular
ASCII characters. Given that CScheme is "portable", why does this get
included in everybody's copy?
Please read section 13.5 of the "Common Lisp the Language" book. MIT
ASCII is ASCII with control, meta, hyper, and super bits, and is
extremely useful when writing Emacs-like editors. CScheme only
assumes the standard ASCII character set (and the assumptions are few,
so converting to EBCDIC is not hard and has been done in the past),
and builds MIT ASCII on top, thus portability is not compromised.
Lack of documentation is an unforgivable omission, and is by far my
biggest gripe about CScheme. It shouldn't take two hours to figure
out what kind of garbage collection is being done, or to figure out
what the "danger bit" does. I've worked with many programs on that
scale during my 12 years in computing, and to be fair, most large
programs are difficult to understand, even with documentation (TeX
for instance). This just means that *more* documentation is required,
not less! To put it another way, lesser minds can't be amazed by your
cleverness if they don't even know what's going on...
The hard line:
CScheme was provided because other people asked for it, not because we
wanted to "spread the Gospel", or were willing to support it. Quoting
from the CScheme copyright notice:
4. MIT has made no warrantee or representation that the operation of
this software will be error-free, and MIT is under no obligation to
provide any services, by way of maintenance, update, or otherwise.
This is not merely "legalese", we mean it. As a consequence of this,
we feel under NO obligation to write documentation until WE need it or
have the time to do it. Both of these conditions have been met
recently, so the process has started.
On the other hand... The CScheme system is FAR from complete or
"finished". We could have waited until it was finished (including
documentation) before making it available, but we decided to make it
available earlier in the hope that it would be useful, but with the
understanding that it would be incomplete. Please don't flame because
we are not yet done. You are being impatient.
A little CScheme history may explain some idiosyncrasies:
- CScheme was first written, as a toy, in the fall of 1983. We did NOT
use it. People asked for it, so we gave it out.
- In late 1986 we decided to make it our main implementation.
Previously our main implementation consisted of the assembly language
interpreter, a compiler which had been running since early 1984, and
Edwin, which was developed on that implementation and then ported by
TI to the PC.
- Up until that point we had treated CScheme mostly as a curiosity.
After this, we developed a new compiler which coexists with the C
interpreter. The compiler went into beta test a few weeks ago and
will be released later this year. I'm fairly certain that by the end
of this summer CScheme (with its compiler) will provide performance
similar to that provided by other dialects of Lisp (Lucid, T), at
which point we may be able to reexamine some of the issues, but so far
it has been premature. We've only been really working on it for 2
years. As far as I know, most other implementations of Lisp have been
around for considerably more time, so we're not doing too badly.
∂04-May-88 2010 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Unpleasantness
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 88 20:10:36 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 4 May 88 22:27:58 EDT
Received: by ZOHAR.AI.MIT.EDU; Wed, 4 May 88 22:32:08 edt
Date: Wed, 4 May 88 22:32:08 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8805050232.AA03440@zohar>
To: shebs%defun@cs.utah.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Stanley T. Shebs's message of Wed, 4 May 88 11:12:23 MDT <8805041712.AA02219@defun.utah.edu>
Subject: Unpleasantness
Usually I refrain from becoming involved in squabbles about the
apparent quality of one or another person's code. I can remember such
arguments when I was very small -- something of the form "My daddy is
bigger and stronger than your daddy.", so it usually feels a bit
childish to fight about things like that. In this case, however, you
have said some rather unpleasant things about very good friends of
mine, and they are feeling quite bad about it, so I feel compelled to
respond.
In defense of CScheme.
I teach 2 subjects at MIT that use Scheme as an integral part of
the methodology of teaching. Abelson and I are in charge of the
introductory computer science subject, where we use SICP. This
subject serves a population of 700 students each year. Abelson and I
also are involved with our introductory subject in Circuits, Signals
and Systems, with about 500 students each year. In both of these
subjects we use a Scheme system produced by those friends of mine you
have insulted. We use CScheme in the CSS subject and a previous
version of Scheme written for the HP Pascal P system in the SICP
subject.
In running such large subjects it is essential that we have
excellent software, because even a small problem can become an
educational disaster. Thus, I can assert, with considerable
experience, that the Scheme software we use is of outstanding quality.
It is clean. It is maintainable. It is reliable. I can be sure that
when I put out a problem set that the students will not get the system
into bad states and that their bugs will be clearly indicated with
clear error comments. I can be sure that the Scheme system will not
crash, even under the relentless pressure of hundreds of smart
undergraduates.
You complain about some strange things:
Writing nonprimitives in C. My eye happened to fall on
list_to_string, which is about three times longer and more
complicated in C than in Scheme. What earthly reason could
there be for this? I suppose it could be worse; KCL is an
example. On the other hand, even KCL doesn't put a Fast Fourier
Transform and a regular expression matcher in its C "microcode"...
I can see nothing wrong with this, but I am willing to take
responsibility for it, since I can explain it rather easily... Even
KCL is not used in an introductory subject on Signal Processing. It
just so happened that we had an excellent FFT, written in C by Yekta
Gursel. I needed a good FFT for my subject, so Panayotis Skordos, one
of my star graduate students, who was a teaching assistant for me in
the subject, installed a slightly modified version of the Gursel FFT
into the CScheme kernel for students to use in the course. It seems
to me that we Lispers would be fools not to use good code that we can
get from someone else. Do YOU want to write me a procedure that
computes Bessel functions? -- I can probably buy a better one from
IMSL. In fact, that we can assimilate code not written in Scheme is
one of the virtues of the MIT CScheme system.
I assert, and I believe that I can do so with authority, that CScheme
is an excellent system that reliably and effectively supports teaching
of massive subjects at MIT. I have tried a number of other Lisp
systems, including PSL, and of those I have tried I have found no other
systems, except for possibly TI PC Scheme or Semantic Microsystems'
MACScheme that could stand up to this rigorous a test.
Strategic Considerations
You also object to a number of organizational decisions that were
made in CScheme, indicating serious ignorance of the historical
context of the system.
Gazillions of builtin types. There are twice as many
primitive types of objects as any other high-level language
that I know of (3- and 4-element hunks? give me a break!).
Many could have been built as nonprimitives. See T for good
efforts in that direction.
Attempts to optimize the C code implementing a virtual
machine. If you use a virtual machine, you've already lost
speedwise; doing complicated C hacks isn't going to recover
much for you. (Presumably that's the reason for hundreds of
C macros that could have been function calls.)
Again, though I find nothing wrong with virtual machines (note that TI
PC Scheme uses a virtual-machine strategy and it is roaringly fast) I
am pleased to take responsibility for this. What you do not know is
that CScheme evolved from the actual microcode for the Scheme-81 chip,
a special-purpose architecture for executing the Scheme SCODE language
efficiently. The CScheme system started as a simulator for the actual
Scheme-81 machine. The SCODE language is an experimental machine
language. The plethora of types you refer to are the opcodes of that
language. They have nothing at all to do with the user's types. You
should be amazed at CScheme's excellent performance, considering that
we had not contemplated running it on a conventional architecture at
all.
Summary
I feel that your allegations are unfounded and ill considered.
However, I want you and everyone else to know that I am part of the
reason why some of the things you object to came out the way they did.
I suggest that we stop arguing about such things in public like little
children. I will stop if you do. I also suggest that if you want to
fight out the technical details I will be pleased to meet with you at
the Lisp Conference in Snowbird. Perhaps we will both learn something
useful in that context.
Gerald Jay Sussman,
Professor of Electrical Engineering,
Massachusetts Institute of Technology.
∂05-May-88 0713 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM Re: Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 07:13:15 PDT
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 5 May 88 09:52:14 EDT
Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176759; Thu 5-May-88 09:51:14 EDT
Date: Thu, 5 May 88 09:50 EDT
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: Re: Extending the address space of MIT Cscheme (long reply)
To: shebs%defun@cs.utah.edu, cph@zurich.ai.mit.edu
cc: scheme@mc.lcs.mit.edu
In-Reply-To: <8805041712.AA02219@defun.utah.edu>
Message-ID: <19880505135059.9.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Wed, 4 May 88 11:12:23 MDT
From: shebs%defun@cs.utah.edu (Stanley T. Shebs)
Writing nonprimitives in C. My eye happened to fall on list_to_string,
which is about three times longer and more complicated in C than in Scheme.
What earthly reason could there be for this? I suppose it could be worse;
KCL is an example. On the other hand, even KCL doesn't put a Fast Fourier
Transform and a regular expression matcher in its C "microcode"...
I dunno. The precedents are there. The VAX gives you a FORMAT statement in
microcode... :-)
I find it odd that haters of C would use macros to the extent that CScheme
does.
[I'm speaking from the vantage point of someone who has NEVER seen the CScheme
sources, but who HAS tried to program abstractly in C]
Unfortunately, macros are the only way to do \syntactic/ extensions of the
language. I'm currently preparing a short class on code
maintainability/writing "good" code. One of the things we examine is why it's
hard to do reasonable abstraction in C. Part of the reason is that syntax is
tightly tied to representation. The only facility around that is macros.
>* We have virtually no documentation. This is obviously a terrible
>thing, and we are in fact generating some. But the bottom line for
>this is simply lack of time, plus the fact that none of us has much
>text writing experience.
I hear that excuse from froshes, and don't accept it from them either.
Documentation after the fact is inherently inferior, and leaves out
important details that the programmers have forgotten about.
Still, I do appreciate where you're coming from - it's something that
professional SEs have to contend with all the time (my own views have
no doubt been colored by one of my first jobs, which was to document
40,000 lines of Fortran written by several other people).
A marvelous exercise! I started my programming career working for a man who
had me go through various RSTS/E V5 system programs, document them, and rewrite
them "modularly." There's nothing like that kind of experience to make
"writing code" a superset of "writing documentation" (n.b. a superset; the
two aren't disjoint!)
In fact, my almost finished thesis is all about the analysis of
representation decisions.
I'd be \very/ interested in a copy of this. Will they be available online?
- Stephen
STEVER@RIVERSIDE.SCRC.Symbolics.COM or SCRC-RIVESIDE.ARPA [arpa]
stever@ATHENA.MIT.EDU
...!mit-eddie!mit-athena!stever [UUCP]
(617) 621-7634 [NYNEX]
4CC 02142-1421 [USPS]
∂05-May-88 0819 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 08:19:35 PDT
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 5 May 88 10:02:51 EDT
Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 176764; Thu 5-May-88 10:02:02 EDT
Date: Thu, 5 May 88 10:01 EDT
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: Extending the address space of MIT Cscheme (long reply)
To: jinx@zurich.ai.mit.edu
cc: cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: <8805050202.AA29123@chamarti>
Message-ID: <19880505140151.1.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Wed, 4 May 88 22:02:40 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
... few Lisp implementations (if any) can currently match the speed that
can be obtained from C or FORTRAN in numeric code. What's wrong with
coding a commonly used procedure in a language which will make it more
efficient? Please show me a Lisp which can compete with C in this regard.
If you manage to do this, I strongly suspect that the number of arcane
declarations in the Lisp code will make it at least as unreadable as C, so
you're no better off.
I was under the impression that LISP's numeric inefficiency was, in general, a
fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some
years back?
- Stephen
∂05-May-88 0913 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 09:13:01 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 5 May 88 10:33:10 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08373; Thu, 5 May 88 08:32:58 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02983; Thu, 5 May 88 08:32:54 MDT
Date: Thu, 5 May 88 08:32:54 MDT
From: shebs%defun@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8805051432.AA02983@defun.utah.edu>
To: jinx@zurich.ai.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 4 May 88 22:02:40 edt <8805050202.AA29123@chamarti>
Subject: Re: Extending the address space of MIT Cscheme (long reply)
Thanks for your message. It clears up most of my problems with CScheme.
> Gazillions of builtin types.
>
>What's wrong with that? It's nice (and ultimately more robust) to
>allow the system to distinguish between various objects with 2, 3, or
>more components.
I was suggesting user-defined types, a la DEFSTRUCT. Some types are just
not "important" enough to be made into primitives. User-defined types are
such an important abstraction it's surprising to see CScheme not use them;
it would save a lot in the many switch statements on types.
>1) Using a virtual machine is a common technique these days to
>implement interpreters. We have made no claim that our interpreter
>will run code as fast as code produced by native code compilers. Thus
>there is no attempt to make the CScheme interpreter run as fast as
>anybody else's compiled code. As far as interpreters go, it's not
>great, but it's not bad in terms of speed, but provides much more
>convenience and ease of debugging than any other interpreter I know.
>
>2) Most of the hairy C and macrology arise not from using a virtual
>machine, but from the fact that the PARTICULAR virtual machine we
>chose cannot be conveniently written in C without paying an undue
>penalty.
These two statements seem contradictory - first you're saying that there
is no attempt to make things as fast as compiled code, but that using
functions instead of macros exacts an undue penalty. I don't understand!
>[...] What's wrong with
>coding a commonly used procedure [FFT] in a language which will make it more
>efficient?
I have no problem with that, but it's the embedding of the procedure in a
language implementation that seems strange. There are any number of other
ways to provide FFT in C without making it into a primitive function.
> References to apparent GC in all kinds of strange places. When I followed
> them, the trail disappeared in a maze of macros.
>
>Hmm. Maybe the Lisps you are used to don't check whether there is
>enough space to allocate storage before they go ahead and do it. They
>can't be very robust. I'm also surprised that you complain about this
>particular "maze". It seems pretty straightforward to me.
I found the check for the *necessity* of GC, and it was in the same place
that most other implementations put it. What I didn't find was how the check
actually got a GC going! No doubt it will seem straightforward to me too,
once it's pointed out...
> References to the compiler and Edwin, thus violating every principle of
> abstraction known to exist.
>
>What? Please explain, I don't understand what that means.
I'm speaking of edwin.h and com*.c. Why are they for?
∂05-May-88 0947 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Extending the address space of MIT Cscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 09:47:33 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 5 May 88 10:34:16 EDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06016; 5 May 88 15:24 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 5 May 88 15:23:49 bst
Message-Id: <21122.8805051423@aiva.ed.ac.uk>
To: cph@zurich.ai.mit.edu, shebs <@cs.utah.edu:shebs@defun>
Subject: Re: Extending the address space of MIT Cscheme
Cc: scheme@mc.lcs.mit.edu
> Date: Wed, 4 May 88 11:12:23 MDT
> From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs>
> Attempts to optimize the C code implementing a virtual machine. If
> you use a virtual machine, you've already lost speedwise; doing
> complicated C hacks isn't going to recover much for you. (Presumably
> that's the reason for hundreds of C macros that could have been
> function calls.)
C hacks (if you want to call them that) can make a difference,
particularly (on many machines) if they let you avoid procedure
calls (slow call instructions, parameters moved from registers to
stack and back). In-line procedures would be better than C macros,
but C doesn't have them.
∂05-May-88 1025 @MC.LCS.MIT.EDU:gls@Think.COM Extending the address space of MIT Cscheme (semi-long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 10:25:47 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 May 88 10:53:08 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 5 May 88 10:50:19 EDT
Received: by kali.think.com; Thu, 5 May 88 10:50:16 EDT
Date: Thu, 5 May 88 10:50:16 EDT
From: gls@Think.COM
Message-Id: <8805051450.AA03093@kali.think.com>
To: cph@zurich.ai.mit.edu
Cc: defun.utah.edu!shebs@cs.utah.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 4 May 88 03:47:10 edt <8805040747.AA21368@kleph>
Subject: Extending the address space of MIT Cscheme (semi-long reply)
Date: Wed, 4 May 88 03:47:10 edt
From: cph@kleph.ai.mit.edu (Chris Hanson)
Reply-To: cph@zurich.ai.mit.edu
* We have virtually no documentation. This is obviously a terrible
thing, and we are in fact generating some. But the bottom line for
this is simply lack of time, plus the fact that none of us has much
text writing experience.
I have not seen the code for CScheme, and did not particularly want to jump
into the middle of this flame, but I have a set of points to make about
documentation in general, as one who has written a lot of a code for
publication and also a lot of text.
(1) The way you get experience at writing text is to write text. (When you
first started programming you didn't have much experience at programming,
either, but you obviously didn't let *that* stop you.)
(2) Lack of documentation often stems from the belief that the code is so
clear to you (because you've got it all in your head) that you'll have no
trouble remembering what's going on six months from now. This belief is
invariably false. Even if you don't want to write documentation for other
people, write it for the you of six months from now, becase by then you'll
be a different person too.
(3) Writing documentation usually *saves* time in the programming process,
because it takes less time to review design decisions and rediscover how
little details work.
(4) The writing of documentation actually *improves* the code. The reason
is that it is usually easier to clean up a crock than to have to explain
it. I have seen this phenomenon hundreds of times in programs of all kinds.
I'm not saying that everyone should write documentation the way Knuth
did for TeX. I am saying that documentation has a direct intrinsic value to
the programming process, and that lack of experience in no excuse.
--Best regards,
Guy
∂05-May-88 1113 @MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu Re: Unpleasantness
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 11:13:37 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 5 May 88 11:57:30 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA09148; Thu, 5 May 88 09:04:07 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA03035; Thu, 5 May 88 09:04:03 MDT
Date: Thu, 5 May 88 09:04:03 MDT
From: shebs%defun@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8805051504.AA03035@defun.utah.edu>
To: gjs@zohar.ai.mit.edu
Cc: shebs%defun@cs.utah.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Wed, 4 May 88 22:32:08 edt <8805050232.AA03440@zohar>
Subject: Re: Unpleasantness
> Usually I refrain from becoming involved in squabbles about the
>apparent quality of one or another person's code. I can remember such
>arguments when I was very small -- something of the form "My daddy is
>bigger and stronger than your daddy.", so it usually feels a bit
>childish to fight about things like that.
I suppose we really belong to different communities. In the community I
come from, "apparent quality" of code is a serious issue, possibly involving
multi-million dollar expenses, so it doesn't seem particularly "childish" to
discuss such matters. In the Scheme community, the same issue seems to be
considered unimportant, and I apologize for bringing it up and being
unnecessarily disruptive.
>In this case, however, you
>have said some rather unpleasant things about very good friends of
>mine, and they are feeling quite bad about it, so I feel compelled to
>respond.
Again, I'm sorry to have insulted anybody - that was not my intention.
>[...] I also suggest that if you want to
>fight out the technical details I will be pleased to meet with you at
>the Lisp Conference in Snowbird. Perhaps we will both learn something
>useful in that context.
Perhaps - although I'm afraid our viewpoints are too different. For example,
(now I'm going to get flamed!), I find the differences between Scheme and
Common Lisp to be mostly uninteresting, but consider that the design of
efficient implementations is the most critical issue facing Lisp dialects
today. If you are still willing to communicate given all that, I would be
very pleased to do so!
stan
∂05-May-88 1153 @MC.LCS.MIT.EDU:gls@Think.COM Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 11:53:47 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 5 May 88 12:45:03 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 5 May 88 12:15:20 EDT
Received: by kali.think.com; Thu, 5 May 88 12:15:17 EDT
Date: Thu, 5 May 88 12:15:17 EDT
From: gls@Think.COM
Message-Id: <8805051615.AA03188@kali.think.com>
To: Stever@waikato.s4cc.symbolics.com
Cc: jinx@zurich.ai.mit.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Stephen Robbins's message of Thu, 5 May 88 10:01 EDT <19880505140151.1.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Subject: Extending the address space of MIT Cscheme (long reply)
Date: Thu, 5 May 88 10:01 EDT
From: Stephen Robbins <Stever@waikato.s4cc.symbolics.com>
Date: Wed, 4 May 88 22:02:40 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
... few Lisp implementations (if any) can currently match the speed that
can be obtained from C or FORTRAN in numeric code. What's wrong with
coding a commonly used procedure in a language which will make it more
efficient? Please show me a Lisp which can compete with C in this regard.
If you manage to do this, I strongly suspect that the number of arcane
declarations in the Lisp code will make it at least as unreadable as C, so
you're no better off.
I was under the impression that LISP's numeric inefficiency was, in general, a
fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some
years back?
- Stephen
See, for example, the following two references:
Fateman, Richard J. "Reply to an Editorial." ACM SIGSAM Bulletin 25
(March 1973), 9-11.
Brooks, Rodney A., Gabriel, Richard P., and Steele, Guy L., Jr. An
optimizing compiler for lexically scoped LISP. Proceedings of the 1982
Symposium on Compiler Construction. ACM SIGPLAN (Boston, June 1982),
261-275. Proceedings published as ACM SIGPLAN Notices 17, 6 (June 1982).
--Guy
∂05-May-88 1406 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 14:06:10 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 5 May 88 16:13:36 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Thu, 5 May 88 15:55:24 edt
Date: Thu, 5 May 88 15:55:24 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8805051955.AA00668@chamarti>
To: scheme@mc.lcs.mit.edu
Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
Reply-To: jinx@zurich.ai.mit.edu
Date: Thu, 5 May 88 15:36:01 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
To: gls@Think.COM
Cc: Stever@waikato.s4cc.symbolics.com, cph@zurich.ai.mit.edu
In-Reply-To: gls@Think.COM's message of Thu, 5 May 88 12:15:17 EDT <8805051615.AA03188@kali.think.com>
Subject: Extending the address space of MIT Cscheme (long reply)
Reply-To: jinx@zurich.ai.mit.edu
I was under the impression that LISP's numeric inefficiency was, in general, a
fallacy. Didn't MacLISP generate better numeric code than DEC's FORTRAN, some
years back?
- Stephen
See, for example, the following two references:
Fateman, Richard J. "Reply to an Editorial." ACM SIGSAM Bulletin 25
(March 1973), 9-11.
Brooks, Rodney A., Gabriel, Richard P., and Steele, Guy L., Jr. An
optimizing compiler for lexically scoped LISP. Proceedings of the 1982
Symposium on Compiler Construction. ACM SIGPLAN (Boston, June 1982),
261-275. Proceedings published as ACM SIGPLAN Notices 17, 6 (June 1982).
MacLisp is, unfortunately, essentially dead, and S-1 Lisp (as far as I
know) only ran on the S-1. I'm not claiming that this task is
impossible (I know it isn't and one of the current main goals in the
MIT Scheme project is improving the efficiency of numeric code),
merely that I don't believe there are widespread implementations
running on stock hardware which can compete RIGHT NOW. I hope I'm
wrong, but I fear I'm not.
The sad fact of life is that most of the Lisp community does not care
about numeric code, and the few exceptions in the community are rare
and seen as odd birds. The only widespread Lisp compiler that has
provided good performance (MacLisp) required (from what I've heard)
over 10 man-years of implementation (by JONL, you (GLS), and others).
Most Lisp compiler writers have not attempted to match this, and often
good performance is obtained only by using arcane declarations which
only implementors can manage.
∂05-May-88 1447 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 14:47:08 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 5 May 88 16:14:09 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Thu, 5 May 88 15:54:10 edt
Date: Thu, 5 May 88 15:54:10 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8805051954.AA00661@chamarti>
To: scheme@mc.lcs.mit.edu
Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
Reply-To: jinx@zurich.ai.mit.edu
Date: Thu, 5 May 88 15:28:29 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
To: shebs%defun@cs.utah.edu
In-Reply-To: Stanley T. Shebs's message of Thu, 5 May 88 08:32:54 MDT <8805051432.AA02983@defun.utah.edu>
Subject: Extending the address space of MIT Cscheme (long reply)
Reply-To: jinx@zurich.ai.mit.edu
I was suggesting user-defined types, a la DEFSTRUCT. Some types are just
not "important" enough to be made into primitives. User-defined types are
such an important abstraction it's surprising to see CScheme not use them;
it would save a lot in the many switch statements on types.
CScheme has a defstruct-like macro (define-structure). Most of the
types you saw in the C files are used by the implementation as GJS
implied. An altogether different question is whether defstruct really
provides (relatively opaque) types or merely convenient syntax for
constructors, selectors and mutators for standard types.
>1) Using a virtual machine is a common technique these days to
>implement interpreters. We have made no claim that our interpreter
>will run code as fast as code produced by native code compilers. Thus
>there is no attempt to make the CScheme interpreter run as fast as
>anybody else's compiled code. As far as interpreters go, it's not
>great, but it's not bad in terms of speed, but provides much more
>convenience and ease of debugging than any other interpreter I know.
>
>2) Most of the hairy C and macrology arise not from using a virtual
>machine, but from the fact that the PARTICULAR virtual machine we
>chose cannot be conveniently written in C without paying an undue
>penalty.
These two statements seem contradictory - first you're saying that there
is no attempt to make things as fast as compiled code, but that using
functions instead of macros exacts an undue penalty. I don't understand!
They are not contradictory. The first version of the C Scheme
interpreter ran about 4 times slower than the assembly language
version on the same hardware. We were not attempting to achieve
native code speed, merely regain the penalty imposed by naively coding
in C.
I found the check for the *necessity* of GC, and it was in the same place
that most other implementations put it. What I didn't find was how the check
actually got a GC going! No doubt it will seem straightforward to me too,
once it's pointed out...
The relevant macros are (in microcode/primitive.h and microcode/gc.h)
#define Primitive_GC(Amount) \
{ \
Request_GC (Amount); \
Primitive_Interrupt (); \
}
#define Primitive_Interrupt signal_interrupt_from_primitive
#define Request_GC(Amount) \
{ \
REQUEST_INTERRUPT(INT_GC); \
GC_Space_Needed = Amount; \
}
where signal_interrupt_from_primitive is a procedure in
microcode/utils.c.
I would hardly call this a maze. A good cross-reference program could
easily help you sort this one out. Even grep suffices most of the
time, and certainly in this case.
> References to the compiler and Edwin, thus violating every principle of
> abstraction known to exist.
>
>What? Please explain, I don't understand what that means.
I'm speaking of edwin.h and com*.c. Why are they for?
I don't believe that the fact that you don't know what they are for
implies that some abstraction principles have been violated.
compiler.c and related files are various hooks for the compiler. The
default version of the system assumes that there is no compiler, so
the hooks are just stubs. When the compiler is ported to a new
machine/operating system, appropriate versions of these files are
written reflecting some of the machine-dependent decisions made, and
implementing the compiled code interface to the interpreter. It is a
relatively simple and innocuous way of providing a system which can
coexist with the compiler but does not require its presence.
edwin.h is a spurious part of the release. rgxprim.c and syntax.c
(which are the only files that need it) are files essentially taken
from GNU Emacs, and could easily be spliced out of the load sequence
since the system does not use them.
A problem that must be faced when attempting to write a (relatively)
portable EXTENSIBLE C program is that there is no standardized dynamic
loader for C, so all of the C code that you may ever want to use must
be linked to your interpreter at interpreter generation time.
We could have attempted to write a dynamic linker for C, but the
resulting system would probably have been far less portable, and even
harder to read.
∂05-May-88 1542 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Extending the address space of MIT Cscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 15:40:18 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 16:14:24 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA15150@BLOOM-BEACON.MIT.EDU>; Thu, 5 May 88 15:59:56 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 5 May 88 14:23:49 GMT
From: aiva.edinburgh.ac.UK!jeff@ucbvax.berkeley.edu (Jeff Dalton)
Organization: The Internet
Subject: Re: Extending the address space of MIT Cscheme
Message-Id: <21122.8805051423@aiva.ed.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
> Date: Wed, 4 May 88 11:12:23 MDT
> From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs>
> Attempts to optimize the C code implementing a virtual machine. If
> you use a virtual machine, you've already lost speedwise; doing
> complicated C hacks isn't going to recover much for you. (Presumably
> that's the reason for hundreds of C macros that could have been
> function calls.)
C hacks (if you want to call them that) can make a difference,
particularly (on many machines) if they let you avoid procedure
calls (slow call instructions, parameters moved from registers to
stack and back). In-line procedures would be better than C macros,
but C doesn't have them.
∂05-May-88 1702 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Unpleasantness
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 17:02:20 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 16:44:37 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA16132@BLOOM-BEACON.MIT.EDU>; Thu, 5 May 88 16:30:50 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 5 May 88 15:04:03 GMT
From: CS.UTAH.EDU!shebs%defun@ucbvax.berkeley.edu (Stanley T. Shebs)
Organization: The Internet
Subject: Re: Unpleasantness
Message-Id: <8805051504.AA03035@defun.utah.edu>
References: <8805050232.AA03440@zohar>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
> Usually I refrain from becoming involved in squabbles about the
>apparent quality of one or another person's code. I can remember such
>arguments when I was very small -- something of the form "My daddy is
>bigger and stronger than your daddy.", so it usually feels a bit
>childish to fight about things like that.
I suppose we really belong to different communities. In the community I
come from, "apparent quality" of code is a serious issue, possibly involving
multi-million dollar expenses, so it doesn't seem particularly "childish" to
discuss such matters. In the Scheme community, the same issue seems to be
considered unimportant, and I apologize for bringing it up and being
unnecessarily disruptive.
>In this case, however, you
>have said some rather unpleasant things about very good friends of
>mine, and they are feeling quite bad about it, so I feel compelled to
>respond.
Again, I'm sorry to have insulted anybody - that was not my intention.
>[...] I also suggest that if you want to
>fight out the technical details I will be pleased to meet with you at
>the Lisp Conference in Snowbird. Perhaps we will both learn something
>useful in that context.
Perhaps - although I'm afraid our viewpoints are too different. For example,
(now I'm going to get flamed!), I find the differences between Scheme and
Common Lisp to be mostly uninteresting, but consider that the design of
efficient implementations is the most critical issue facing Lisp dialects
today. If you are still willing to communicate given all that, I would be
very pleased to do so!
stan
∂05-May-88 1745 @MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU Thanks for CScheme; I like it
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 17:44:52 PDT
Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 5 May 88 16:52:30 EDT
Date: Thu, 5 May 88 08:27:19 PDT
From: Max Hailperin <HAILPERIN@SUMEX-AIM.Stanford.EDU>
Subject: Thanks for CScheme; I like it
To: scheme@mc.lcs.mit.edu
Message-ID: <12395909997.20.HAILPERIN@SUMEX-AIM.Stanford.EDU>
I can't speak with the authority of GJS, but I am an outside user who has
benefited from the decision to export CScheme, imperfections and all, so
let me say this:
I am extremely grateful to MIT for making this system available.
I would feel very uneasy turning my introductory-course students
loose on any implementation with a less transparent debugging
environment. My attempts at understanding the code have always
been quite bareable, certainly relative to what I paid.
Thanks so much for this valuable contributiion, and please don't let a
few naysayers discourage you from sharing with the rest of us in the
future.
-------
∂05-May-88 2110 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Extending the address space of MIT Cscheme (semi-long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 21:05:16 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 May 88 22:39:03 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA15973@BLOOM-BEACON.MIT.EDU>; Thu, 5 May 88 16:25:48 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 5 May 88 14:50:16 GMT
From: THINK.COM!gls@ucbvax.berkeley.edu
Organization: The Internet
Subject: Extending the address space of MIT Cscheme (semi-long reply)
Message-Id: <8805051450.AA03093@kali.think.com>
References: <8805040747.AA21368@kleph>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Date: Wed, 4 May 88 03:47:10 edt
From: cph@kleph.ai.mit.edu (Chris Hanson)
Reply-To: cph@zurich.ai.mit.edu
* We have virtually no documentation. This is obviously a terrible
thing, and we are in fact generating some. But the bottom line for
this is simply lack of time, plus the fact that none of us has much
text writing experience.
I have not seen the code for CScheme, and did not particularly want to jump
into the middle of this flame, but I have a set of points to make about
documentation in general, as one who has written a lot of a code for
publication and also a lot of text.
(1) The way you get experience at writing text is to write text. (When you
first started programming you didn't have much experience at programming,
either, but you obviously didn't let *that* stop you.)
(2) Lack of documentation often stems from the belief that the code is so
clear to you (because you've got it all in your head) that you'll have no
trouble remembering what's going on six months from now. This belief is
invariably false. Even if you don't want to write documentation for other
people, write it for the you of six months from now, becase by then you'll
be a different person too.
(3) Writing documentation usually *saves* time in the programming process,
because it takes less time to review design decisions and rediscover how
little details work.
(4) The writing of documentation actually *improves* the code. The reason
is that it is usually easier to clean up a crock than to have to explain
it. I have seen this phenomenon hundreds of times in programs of all kinds.
I'm not saying that everyone should write documentation the way Knuth
did for TeX. I am saying that documentation has a direct intrinsic value to
the programming process, and that lack of experience in no excuse.
--Best regards,
Guy
∂05-May-88 2145 @MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 21:45:30 PDT
Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 5 May 88 22:56:42 EDT
Received: by labrea.stanford.edu; Thu, 5 May 88 18:14:14 PDT
Received: from bhopal.lucid.com by edsel id AA06333g; Thu, 5 May 88 17:56:58 PDT
Received: by bhopal id AA29419g; Thu, 5 May 88 17:59:36 PDT
Date: Thu, 5 May 88 17:59:36 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805060059.AA29419@bhopal.lucid.com>
To: labrea!jinx@zurich.ai.mit.edu
Cc: shebs%defun@cs.utah.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 4 May 88 22:02:40 edt <8805050202.AA29123@chamarti>
Subject: Extending the address space of MIT Cscheme (long reply)
re: . . . What's wrong with
coding a commonly used procedure in a language which will make it more
efficient? Please show me a Lisp which can compete with C in this
regard. If you manage to do this, I strongly suspect that the number
of arcane declarations in the Lisp code will make it at least as
unreadable as C, so you're no better off.
Two points:
(1) nothing is wrong with coding an essentially numerical algorithm
in the language classically used to code numerical algorithms
(such as FORTRAN/ALGOL/ADA/PASCAL/C etc). That's one reason why
"industrial strength" Common Lisps have a convenient foreign
function interface. [see article in most recent issue of Lisp
Pointers]
(2) Here are names of two generally available Lisps which can frequently
compete with C in writing numerical code like FFT: PDP10 MacLisp
and Lucid Common Lisp. Furthermore, I challenge your presumption
that any such Lisp-written code will be unintelligible due to
"arcane" declarations [mostly I challenge the underlying assumption
(if in fact you are making it) that *any* declarations in Lisp are
"arcane".] While it is true that most variables in such a program
will be declared of type fixnum, or float, or array-of-float (and
some function types will be proclaimed too), the number of source
lines of code devoted to such declarations, compared to the total
amount of source code, is down in the noise.
Looking ahead in the mails, I see that GLS has already sent out references
to the early successes of MacLisp (1973!). It would be difficult for me
to say more about Lucid Common Lisp now without appearing to be self-
serving; suffice it to say that you could contact me privately, or RPG@SAIL,
and ask for substantiation of the above statements.
-- JonL --
P.S. I suspect that ZetaLisp on a Lisp Machine produces numerical code
that competes with C/FORTRAN on such machines (to my knowledge,
only Symbolics has such compilers -- but I really don't know about
TI and the now-defunct LMI). You must have meant "a Lisp which can
compete with C" on stock hardware.
∂05-May-88 2319 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU Maclisp revisited.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 23:18:58 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 May 88 23:13:47 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7)
id AA21731; Thu, 5 May 88 18:33:32 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA19995; Thu, 5 May 88 18:34:43 edt
Date: Thu, 5 May 88 18:34:43 edt
From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8805052234.AA19995@bucsf>
To: jinx@zurich.ai.mit.edu
Cc: scheme@mc.lcs.mit.edu
Subject: Maclisp revisited.
Through the intervention of the Macsyma->Lisp translator which I did
extensive work on and with in the days when the Macsyma Consortium had
hundreds of active users, I can say I produced my share of heavy
numerical code usage in Maclisp. In fact, we Plasma Fusion hackers
knew well the trade of between a quick-turn-around hack in maclisp or
macsyma and a heavy run in Fortran on the CRAY-1 at the MFE center at
Lawrence Livermore Labs. It was not unusual for a person using that
KL-10 with Maclisp and a knowlege of applicable numerical programming
techniques to come up with a physically meaningful result before the
guy in the next office using the CRAY-1 was able to. Of course, one would
hope that we always made sure the results checked before going to publication.
It is indeed sad but true that no machine/lisp implementation I have used
in the ten years since has quite matched that performance. Lispmachines
came very close, but that is another story.
I disagree strongly however that it is actually DIFFICULT to get good
number complication in Lisp. Not great, just good. Maclisp was good,
not great, and that worked out just fine. The amount work supposedly
put into the Maclisp compiler is not a valid measure of how much work
it would be to do something equivalent today.
Anyway, in a couple months DOE-Macsyma will be producing as good numerical
code in a lisp enviroment (in lisp of course) as in the PDP-10 days.
There actually are some decent numerical lisp's out there.
-gjc
∂05-May-88 2353 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU C and Cscheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 May 88 23:53:07 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 5 May 88 23:14:01 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7)
id AA20558; Thu, 5 May 88 18:15:20 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA24411; Thu, 5 May 88 18:16:31 edt
Date: Thu, 5 May 88 18:16:31 edt
From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8805052216.AA24411@bucsf>
To: scheme@mc.lcs.mit.edu
Subject: C and Cscheme.
I actually believe that good programmers are good programmers, and
bad programmers are bad programmers, no matter what language they
program in. The UBERPROGRAMMER has mastery over many languages
and can learn a new one and start programming in it in less than 15 minutes.
Personally, knowing the people that worked on CScheme, I think they
would have been happier with a more powerful (as far as the ability to
express statements that better cover the output domain of the
compiler, which in this case is the machine architecture, or
instruction set) and abstract language such as BLISS. (Quite possible,
since the first development happened on TOPS-20 and VMS).
But I'm sure that everybody is happy that it is in C, since it was
intended to be ported without first porting a compiler!
Now this might be a secret, but there are famous people, well know
for promulgating the use of lisp, either by founding LISPMACHINE companies,
or writing books, etc, who do quite a bit of programming in C and/or FORTRAN.
Enquiring People Want to Know!
(Motto of National Enquirer, info for you sheltered types)
-gjc
∂06-May-88 0151 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Extending the address space of MIT Cscheme (long reply)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 01:51:05 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 6 May 88 01:19:20 EDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08679; 5 May 88 19:54 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 5 May 88 19:54:29 bst
Message-Id: <24707.8805051854@aiva.ed.ac.uk>
To: jinx@zurich.ai.mit.edu, shebs <@cs.utah.edu:shebs@defun>
Subject: Re: Extending the address space of MIT Cscheme (long reply)
Cc: scheme@mc.lcs.mit.edu
> Date: Thu, 5 May 88 08:32:54 MDT
> From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs>
> These two statements seem contradictory - first you're saying that
> there is no attempt to make things as fast as compiled code, but that
> using functions instead of macros exacts an undue penalty. I don't
> understand!
Not as fast as compiled code but faster than it would be otherwise.
-- Jeff
∂06-May-88 0249 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu set in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 02:49:49 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 May 88 05:29:35 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA00159@BLOOM-BEACON.MIT.EDU>; Fri, 6 May 88 05:04:11 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 5 May 88 21:58:28 GMT
From: uhccux!chin@humu.nosc.mil (David Chin)
Organization: U. of Hawaii, Manoa (Honolulu)
Subject: set in Scheme?
Message-Id: <1822@uhccux.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anyone know how to do the equivalent of a Common Lisp "set" in
Scheme. In particular, I would like to be able to pass different
symbols as arguments to a function and then set! or define them inside
the function. Is this style of programming (global side-effects for
function calls) contrary to the Scheme philosophy?
Thanks,
David Chin
David_N_Chin@Hawaii.Edu (Internet)
∂06-May-88 0326 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: compatibility/elegance & *theory*
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 03:26:15 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 May 88 05:35:15 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA27527@BLOOM-BEACON.MIT.EDU>; Fri, 6 May 88 02:31:03 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 4 May 88 18:24:01 GMT
From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: Re: compatibility/elegance & *theory*
Message-Id: <395@aiva.ed.ac.uk>
References: <365@aiva.ed.ac.uk>, <385@aiva.ed.ac.uk>, <922@cresswell.quintus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
The frist 4 paragraphs or so are a review of the story so far...
The original question was whether it is possible to write a correct
(and complete) automatic conversion program from Prolog (or Lisp) to
assembler. It was pointed out (by OK and perhaps others) that this
was not possible because call/1 (in Prolog) or EVAL (in Lisp) could
use arbitrary data ("source code representations") as code and so
would require that the "conversion" include an interpreter for the
language -- the conversion wouldn't be complete for further
conversions might be required.
I then suggested that Lisp's APPLY was less troublesome in this regard
that call/1 or EVAL because it just called a function (which is a kind
of data objetc in Lisp) rather than process some source representation
that might turn out to do anything whatsoever.
Richard replied that call/1 was just APPLY, not EVAL.
[Aside: it isn't always implemented that way. Sometimes call/1 is
an interpreter rather than having the "interpretation" put off into
"fexprs" such as ','/2.]
I replied that call/1 takes (and in Prolog must take) the name of a
procedure while APPLY can take the actual procedure and that this
causes problems for some kinds of Prolog module systems. It turns
out that this name vs. procedure point isn't quite the right one
though: see below.
In article <922@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>There are two differences between EVAL and APPLY
>(1) EVAL evaluates the arguments of its argument, APPLY does not.
> In this respect, call/1 resembles APPLY, not EVAL. call/1 as such
> does not do any interpretation other than to locate the predicate
> which is to be called.
>(2) EVAL is given (a form in which there occurs) the _name_ of a function,
> not the function itself, APPLY is given a function pointer/closure &c.
> In this respect call/1 resembles EVAL, not APPLY. There is no Prolog
> object which "directly" represents a predicate.
>
>I have always regarded the essential feature of EVAL as being (1), and
>have regarded (2) as a detail of implementation, so I understood "is
>basically an EVAL" to mean "is like an interpreter which is responsible
>for evaluating sub-forms". That is what is false.
The question of whether APPLY accepts procedures or (also) procedure
names is one of the key differences between Scheme and other Lisps
such as Franz and CL. It is one way in which Scheme makes a clearer
distinction between procedures and source representations.
By saying call/1 is basically an EVAL, I meant that it brings in the
problems that EVAL does while APPLY does not. One of these problems
is that procedure names can be passed around rather than procedures.
Then you may have do decide at call time which module to dereference
the name in unless (as in Common Lisp packages) the module information
is part of the name. So this is a problem. But it's not the right
problem, or at least not all of it.
The right problem is that EVAL means you can never completely
translate Lisp without supplying an EVAL on the object side too.
Call/1 shares this problem.
APPLY, defined as in Scheme, does not because
(a) You can call procedures but not, say, lists like (LAMBDA (X) ...).
So you can't build an arbitrary expression as a list and then
call APPLY to get that list evaluated.
(b) You can't call fexprs, only functions of the normal sort.
So you can't say
(apply if '(t <arbitrary expression as a list>))
Richard's explanation of call/1 shows that it can do this.
>Jeff Dalton is quite right about (2), and as he points out, you _do_
>have to work a bit to make a module system and call/1 work together.
By the way, Richard, are you still opposed to the so-called atom-based
module schemes? I suppose it should be a separate topic...
>If Prolog were typed, with the void/N type constructor as Alan
>Mycroft suggested, it would be possible to have a version of call/1
>which resembled APPLY in both respects.
Tell me more.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂06-May-88 0455 @MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 04:55:26 PDT
Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 6 May 88 06:59:14 EDT
Received: by labrea.stanford.edu; Thu, 5 May 88 20:37:49 PDT
Received: from bhopal.lucid.com by edsel id AA07249g; Thu, 5 May 88 20:25:46 PDT
Received: by bhopal id AA29976g; Thu, 5 May 88 20:28:25 PDT
Date: Thu, 5 May 88 20:28:25 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805060328.AA29976@bhopal.lucid.com>
To: labrea!jinx@zurich.ai.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 5 May 88 15:55:24 edt <8805051955.AA00668@chamarti>
Subject: [jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]
re: The sad fact of life is that most of the Lisp community does not care
about numeric code, and the few exceptions in the community are rare
and seen as odd birds. The only widespread Lisp compiler that has
provided good performance (MacLisp) required (from what I've heard)
over 10 man-years of implementation (by JONL, you (GLS), and others).
Ah, 10 man-years! [really, I don't think it was that much for MacLisp,
but it certainly wasn't a sophmore's term project].
The sadder fact is how often, during the past 30 years of Lisp existence,
that the total cost of producing a high-quality compiler and system has
been grossly underestimated. At least one world-class company in Germany
is reported to have embarked on a Common Lisp effort with an adequate
understanding of the level of effort required. But that's just about
the only one I know of; almost every other case I'm aware of is off -- on
the low side -- by a factor of two or more.
Say, didn't Chris mention about 10 man-years of development on CScheme,
and still not much of a compiler yet? Applause for his candor.
A few Lisp efforts took someone else's working, and highly portable,
Lisp compiler and produced from that a working Lisp compiler for their
operating-system/machine. Ocasionally I've heard someone publicly boast
that he wrote "the compiler" in well under a man-year, when in fact I know
it to be a case like this. But even this piggy-backing of compilers is a
job whose level of effort is often underestimated.
-- JonL --
P.S. I'd like to throw in the name Rod Brooks -- although he isn't one of
the "others" you mention above, he was a principal on the S1 Lisp
development, and he is (I would say) the principal developer of the
Lucid compiler. If Quux and I et. al. are odd birds, then so is Rod.
∂06-May-88 1130 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: set in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 11:30:01 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 May 88 13:16:45 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAY 88 10:07:44 PDT
Date: Fri, 6 May 88 10:03:38 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: set in Scheme?
In-reply-to: <1822@uhccux.UUCP>
To: scheme@mc.lcs.mit.edu
Message-ID: <880506-100744-4063@Xerox>
David Chin asks, ``Does anyone know how to do the equivalent of a Common Lisp
"set" in Scheme? In particular, I would like to be able to pass different
symbols as arguments to a function and then set! or define them inside the
function. Is this style of programming (global side-effects for function calls)
contrary to the Scheme philosophy?''
I won't stick my neck out by claiming to speak for ``the Scheme philosophy'',
but I will point out some semantic difficulties with this idea. The problem is
that in most Schemes there is no single ``global'' value for a symbol. Rather,
there are a set of environments in which each symbol is bound to a corresponding
set of values. Thus, it is difficult to know what such a ``set''-like operator
would do. Most Schemes with multiple first-class environments, however, do
provide a way to define or set! a symbol in a *particular* environment. For
example, the T dialect has the procedure *LSET for this purpose.
For your application, perhaps you can change things so that, rather than passing
symbols around, you pass procedures of one argument that set a particular
variable to the value of that argument. Thus, rather than passing the symbol
FOO around, you might pass this procedure:
(lambda (v) (set! foo v))
The receiving procedure would then simply apply its argument to the desired
value, as opposed to calling the non-existent ``set'' operation.
Hope this helps,
Pavel
∂06-May-88 1225 @MC.LCS.MIT.EDU:allen@LISPERANTO.BBN.COM Thanks for CScheme; I like it
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 12:25:09 PDT
Received: from LISPERANTO.BBN.COM (TCP 20026201075) by MC.LCS.MIT.EDU 6 May 88 13:22:07 EDT
To: HAILPERIN@SUMEX-AIM.STANFORD.EDU
CC: scheme@MC.LCS.MIT.EDU
In-reply-to: Max Hailperin's message of Thu, 5 May 88 08:27:19 PDT <12395909997.20.HAILPERIN@SUMEX-AIM.Stanford.EDU>
Subject: Thanks for CScheme; I like it
Date: Fri, 6 May 88 12:29:02 EDT
From: allen@LISPERANTO.BBN.COM
Sender: allen@LISPERANTO.BBN.COM
I would like to second this motion. I am the manager of the group that
has developed Butterfly Lisp, for the BBN Butterfly multiprocessor.
Butterfly Lisp is based on CScheme and we have worked closely with the
software and with the people who built it for about 3 years now.
Of course the system has its flaws (though just what they are is
itself debatable), many of which I attribute to its unusual history:
beginning life in silicon, and moving to machine code and then to C
(I'll leave it to others to decide whether this represents progress).
I consider none of the "flaws" fatal -- they mostly just hair up the
interpreter a bit (e.g., the s-code abstraction, which I suspect would
not reappear if the system were being designed today for
implementation in software, with a native-code compiler, rather than
as an interpreter implemented directly in hardware).
On the whole, however, we have found the system to be quality
software, designed and implemented with care, and robust and highly
functional in use. With the advent of the compiler, performance is
beginning to approach that of fast Lisp/Scheme implementations (such
as T/Orbit), and where it doesn't, the problems are understood and in
the process of being fixed (mostly open-coding of arithmetic
operations). I do not believe that the performance issues that tend to
get flamed about (high-tag, passing args on the stack) will amount to
as much (on 680x0-based hardware) as some people seem to believe -- as
Chris mentioned, this belief is supported, in part, by experiment and
measurement, not conjecture.
And speaking of flames, I would like to register my vote for basic
civility in our discussions -- questions were raised here that would
have been a lot more fun to debate if the initial messages had been
less acrimonious.
/Don Allen
∂06-May-88 1408 @MC.LCS.MIT.EDU:fischer.pa@Xerox.COM Re: Declarations and speed
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 14:08:39 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 May 88 16:21:52 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 MAY 88 11:53:44 PDT
Date: 6 May 88 11:53 PDT
From: fischer.pa@Xerox.COM
Subject: Re: Declarations and speed
In-reply-to: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>'s message of
Thu, 5 May 88 10:01 EDT
In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>'s message of Thu, 5
May 88 17:59:36 PDT
To: Stever@WAIKATO.S4CC.Symbolics.COM, edsel!jonl@labrea.stanford.edu
cc: jinx@zurich.ai.mit.edu, cph@zurich.ai.mit.edu, scheme@mc.lcs.mit.edu
Message-ID: <880506-115344-4357@Xerox>
Declarations, of themselves, do not obscurity make. Having to model their
effect on performance is painful.
What is unfathomable, both in C and Lisp, is the exact effect a given set of
declarations will have on your code. For this you must either simulate the
compiler's heuristics in your head or (more commonly) look at the machine code.
Not a pleasant solution, but the only one todays' s/w technology offers. We
could really use a more graceful interface to the machine that doesn't assume
ignorance.
Typically Lisp heaps more complexity on understanding performance with its
memory management, although the swift will usually recycle structure when
possible and forget it only when neccessary.
(ron)
∂06-May-88 1521 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU set in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 May 88 15:21:41 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 May 88 17:02:41 EDT
Date: Fri, 6 May 88 12:12:07 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: set in Scheme?
To: uhccux!chin@HUMU.NOSC.MIL
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 5 May 88 21:58:28 GMT from uhccux!chin at humu.nosc.mil (David Chin)
Message-ID: <372083.880506.JAR@AI.AI.MIT.EDU>
Date: 5 May 88 21:58:28 GMT
From: uhccux!chin at humu.nosc.mil (David Chin)
Does anyone know how to do the equivalent of a Common Lisp "set" in
Scheme. In particular, I would like to be able to pass different
symbols as arguments to a function and then set! or define them inside
the function. Is this style of programming (global side-effects for
function calls) contrary to the Scheme philosophy?
Don't pass the symbol, pass a closure that will assign the variable:
(foo (lambda (new-value) (set! var new-value)))
If you also need to get the value of the variable, or find out its name,
pass an object that can do any operations that need doing:
(foo (lambda (operation)
(case operation
((value) var)
((set-value!) (lambda (new-value) (set! var new-value)))
((name) 'var))))
Global side effects are not contrary to "scheme philosophy" (although
they are discouraged), but confusing variables with their names is.
∂07-May-88 0232 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 May 88 02:32:35 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 03:15:13 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA23163@BLOOM-BEACON.MIT.EDU>; Sat, 7 May 88 01:59:43 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 6 May 88 19:27:02 GMT
From: pierce@locus.ucla.edu
Organization: UCLA Computer Science Department
Subject: Re : set in Scheme
Message-Id: <12063@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In reply to David Chin about "set in Scheme". I'd have to agree with
Pavel that it's better to recode without passing around different symbols.
However, there's a lot of code out there, UCILISP for natural language
processing for example, which uses "set" all over the place. If you just
want to get some simple examples from a text or article running, you
may not consider it worth your time to recode everything; fortunately the
problems described by Pavel may not be that critical either for this type of
code. If so, why not just forget about elegance for a little while and save
yourself some trouble. Just hack out a horrible little ugly macro like the
following:
(macro set
(lambda (e) `(eval ,`(set! ,(eval (cadr e)) ,(caddr e)))))
But I don't think I'd be "sticking my neck out" by saying that THIS doesn't
adhere to the "Scheme philosophy", so I would use it only in emergencies.
-- Brad Pierce
<pierce@cs.ucla.edu>
∂07-May-88 1503 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 May 88 15:03:15 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 17:45:46 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA07913@BLOOM-BEACON.MIT.EDU>; Sat, 7 May 88 16:19:24 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 7 May 88 17:40:57 GMT
From: pierce@locus.ucla.edu
Organization: UCLA Computer Science Department
Subject: Re : set in Scheme
Message-Id: <12073@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Sorry about the last message, I wrote the set macro down a little too
fast and it clearly won't work as intended. I meant to say something
like this:
(macro set
(lambda (e)
(list 'eval
(list 'list
''set!
(list 'eval (list 'quote (cadr e)))
(list 'quote (caddr e))))))
Then if you
(define a 's)
(define s 'any)
(define b 'r)
the effect of (set a b) should be to assign the value r to s.
So far so good. But what about this function?
(define foo
(lambda (x y)
(set x y)))
If we (define s 'any) then the effect of (foo a b) is the same as above.
Judging by my last posting, this may not be perfect either, but at least it's
a lot closer. I'd be interested in seeing a shorter or better solution.
Thanks for your patience.
-- Brad Pierce
<pierce@cs.ucla.edu>
∂07-May-88 1644 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: siod release 1.3
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 May 88 16:43:55 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 17:46:21 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA02334@BLOOM-BEACON.MIT.EDU>; Sat, 7 May 88 11:35:12 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 4 May 88 22:43:54 GMT
From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: Re: siod release 1.3
Message-Id: <397@aiva.ed.ac.uk>
References: <8805020148.AA18536@bu-it.BU.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8805020148.AA18536@bu-it.BU.EDU> gjc@BU-IT.BU.EDU (George J. Carrette) writes:
>Those unable to FTP who requested direct mail have been sent four messages
>today containing the siod sources and a test message.
I have a copy of siod 1.3 and can make it available to sites with
JANet addresses in the UK.
Thanks to George for writing the thing.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂08-May-88 1917 @MC.LCS.MIT.EDU:cire@clash.cisco.com Please remove me.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 May 88 19:17:30 PDT
Received: from clash.cisco.com (TCP 30007603430) by MC.LCS.MIT.EDU 8 May 88 21:03:13 EDT
Received: from clash.cisco.com by clash.cisco.com with TCP; Sun, 8 May 88 17:59:40 PDT
To: scheme@mc.lcs.mit.edu, scheme-request@mc.lcs.mit.edu
Cc: bruce%hpda@hplabs.hp.com, sdawkins%hpda@hplabs.hp.com
Subject: Please remove me.
Date: Sun, 08 May 88 17:59:38 PDT
From: cire@clash.cisco.com
Sorry about troubling the entire list with this request. I have
been trying for some time now to get removed from this list. I
left my previous position a little while ago and the people I've
left behind are still getting deluged.
Please please please. Remove me from the scheme list. Also remove cire@hpda
or cire%hpda@hplabs.hp.com or ucbvax!hpda!cire.
Thanks,
-c
cire|eric
Eric B. Decker
cisco Systems
Menlo Park, California
email: cire@cisco.com
uSnail: 1360 Willow Rd., Menlo Park, CA 94025
Phone : (415 326-1941
∂09-May-88 1317 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 May 88 13:05:23 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 May 88 16:00:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA27543@BLOOM-BEACON.MIT.EDU>; Mon, 9 May 88 15:51:59 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 9 May 88 17:18:45 GMT
From: phoenix!crabb@princeton.edu (David W Crabb)
Organization: Princeton University, NJ
Subject: Re: Re : set in Scheme
Message-Id: <2823@phoenix.Princeton.EDU>
References: <12073@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Dybvig's extend-syntax is a natural for your problem:
(extend-syntax (set)
( (set x y)
(set! x y) ))
-- David
∂09-May-88 1537 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 May 88 15:37:12 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 May 88 16:46:00 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA28430@BLOOM-BEACON.MIT.EDU>; Mon, 9 May 88 16:35:00 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 9 May 88 15:55:41 GMT
From: Ram-Ashwin@yale-zoo.arpa (Ashwin Ram)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Subject: Re: ``Update functions'' in Scheme.
Message-Id: <28710@yale-celray.yale.UUCP>
References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>, <8805031911.AA04352@basel>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8805031911.AA04352@basel>, lyn@BASEL (Franklyn Turbak) writes:
> > Did anybody already think about adding ``generalized functions''
> > (a la Common-Lisp's setf/defsetf feature) to Scheme? This would
> > eliminate the need for several primitive procedures, among them
> > set-car!, set-cdr!, vector-set!, and string-set!. Instead of writing
> >
> > (set-car! p 5) or (vector-set! v 10 'a)
> >
> > this would make it possible to write
> >
> > (set! (car p) 5) or (set! (vector-ref v 10) 'a)
>
> What's so great about SETF? [...]
> it's easy to develop alternate naming conventions without
> altering Scheme. One simple convention can be carried out
> by simple renaming:
>
> (define set!car set-car!) [...]
>
> (set!car p 5) or (set!vector-ref v 10 'a)
>
> which, except for the missing pair of parens, looks a lot like
> the SETF approach. And we didn't have to extend Scheme all!
I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a
difference between the two. When you write (SET (FOO ...) ...), the operation
FOO can specify how it is to be set, i.e., it can handle the operation (SETTER
FOO) and return a setter procedure, which then does the setting appropriately.
This is not a matter of simple renaming; rather, it is a very useful programming
construct which lets you define new operations and their setters within the
existing syntax.
For example, you could implement a two-dimensional array by defining an accessor
operation (array-element A x y), where the definition of the operation would
include a definition of its setter.
Of course, you can do this without this feature too; it just turns out to be a
nice way to program, that's all.
-- Ashwin.
ARPA: Ram-Ashwin@cs.yale.edu
UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin
BITNET: Ram@yalecs
∂09-May-88 1918 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 May 88 19:18:48 PDT
Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 9 May 88 21:51:15 EDT
Received: by BASEL.AI.MIT.EDU; Mon, 9 May 88 22:51:49 edt
Date: Mon, 9 May 88 22:51:49 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
Message-Id: <8805100251.AA08745@basel>
To: Ram-Ashwin@yale-zoo.arpa
Cc: scheme@mc.lcs.mit.edu, lyn@BASEL.AI.MIT.EDU
In-Reply-To: (Ashwin Ram's message of 9 May 88 15:55:41 GMT <28710@yale-celray.yale.UUCP>
Subject: ``Update functions'' in Scheme.
> I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a
> difference between the two. When you write (SET (FOO ...) ...), the operation
> FOO can specify how it is to be set, i.e., it can handle the operation (SETTER
> FOO) and return a setter procedure, which then does the setting appropriately.
> This is not a matter of simple renaming; rather, it is a very useful programming
> construct which lets you define new operations and their setters within the
> existing syntax.
The purpose of my message suggesting simple renaming vs. SETF [e.g. using
(set!vector-ref v 10 'a) rather than (setf (vector-ref v 10) 'a), where
SET!VECTOR-REF is just another name for VECTOR-SET!] was to emphasize that
there is nothing particularly magical about SETF. All SETF does is to
provide a connection between an accessor and its corresponding mutator.
I suggested that an appropriate naming convention served many of the
same purposes as SETF.
Unfortunately, as Bard Bloom has pointed out to me, a simple naming convention
does not work if we wish to use the relationship between accessor and mutator in
a more abstract way. An example derived from the one Bard showed me is:
(define (act-foolishly-on accessor object)
(setf (accessor object) (list (accessor object) "silly"))
object)
That is,
(act-foolishly-on car '(1 2 3)) should return ((1 "silly") 2 3)
and
(act-foolishly-on car '(1 2 3)) should return (1 (2 3) "silly")
ACT-FOOLISHLY-ON can "make sense" for other accessor/mutator pairs as well
(though not STRING-REF / STRING-SET!)
But since procedures are first-class in Scheme, there is an easy way to get this
more abstract behavior using a table that maps accessors to mutators. Suppose
we have table abstraction based on the procedures MAKE-TABLE, TABLE-INSERT!,
and TABLE-LOOKUP. Then we can obtain the more abstract behavior as follows:
; --------------------------------------------------------------------------
; Make a 1-dimensional table
(define *setter-table* (make-table))
; Insert setting procedures into the table keyed by the accessing procedures
; | ACCESSOR | MUTATOR |
(table-insert! *setter-table* car set-car! )
(table-insert! *setter-table* cdr set-cdr! )
(table-insert! *setter-table* vector-ref vector-set! )
(table-insert! *setter-table* string-ref string-set! )
(table-insert! *setter-table* table-lookup table-insert! ) ; !
; . . . and so on.
; The procedure SETTER gets the mutator from the accessor
(define (setter accessor)
(table-lookup *setter-table* accessor))
; Then we can use SETTER for the simple examples . . .
((setter car) p 5)
((setter vector-ref) v 10 'a)
; . . . as well as Bard's more complex example:
(define (act-foolishly-on accessor object)
((setter accessor) object (list (accessor object) "silly"))
object)
; --------------------------------------------------------------------------
The key point here is that Scheme already has enough power to express
the abstract relationship between accessors and mutators; there is no
need to "extend" the language to provide this feature.
- Lyn -
∂10-May-88 0109 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 01:07:09 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 04:02:02 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA10968@BLOOM-BEACON.MIT.EDU>; Tue, 10 May 88 03:56:16 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 10 May 88 02:58:37 GMT
From: ubc-cs!faculty.cs.ubc.ca!manis@beaver.cs.washington.edu (Vincent Manis)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: Re: Re : set in Scheme
Message-Id: <2491@ubc-cs.UUCP>
References: <12073@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Well, putting my radical hat on, not only is set evil, but also set!. Only
non-destructive programming practices are safe, and everything else inevitably
leads to disaster.
But back here in the real world, one occasionally wants global variables.
Those you can have via set! and define. I guess the frequency with which
I use set in Lisp can be best judged by the fact that I hadn't realised
it was absent in Scheme until reading the original posting on this subject.
There are good reasons for omitting it. First of all, set makes programs
opaque in that one has no idea which variable is getting modified. More to
the point, Scheme dispenses with value cells, so implementing set would be
non-trivial in most Schemes (though Chez Scheme's "boxes" might make it
easier).
My eyes glaze over when I see two levels of backquote in a macro definition,
so I don't know how effective the posted solution is. However, my choice is
the humble property list. Still not terribly structured, but efficiently
implemented and a bit more modular (different bits of code can use plists
without interfering, so long as they use different pnames).
Of course, the *right* way to do this is probably a hash table or tree...
Vincent Manis | manis@cs.ubc.ca
The Invisible City of Kitezh | manis@cs.ubc.cdn
Department of Computer Science | manis@ubc.csnet
University of British Columbia | {ihnp4!alberta,uw-beaver,uunet}!
<<NOTE NEW ADDRESS>> | ubc-cs!manis
∂10-May-88 0321 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 03:20:57 PDT
Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 9 May 88 23:03:47 EDT
Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 9 May 88 23:02:26 ast
Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Mon, 9 May 88 23:02:20 ast
Date: Mon, 9 May 88 23:02:20 ast
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
Message-Id: <8805100302.AA01261@TOUCAN.LCS.MIT.EDU>
To: lyn@BASEL.AI.MIT.EDU, scheme@mc.lcs.mit.edu
In-Reply-To: Franklyn Turbak's message of Mon, 9 May 88 22:51:49 edt <8805100251.AA08745@basel>
Subject: ``Update functions'' in Scheme.
> The key point here is that Scheme already has enough power to express
> the abstract relationship between accessors and mutators; there is no
> need to "extend" the language to provide this feature.
I'm not exactly sure what a language extension is. I am pretty sure that
SETF in Lisp is a macro:
(SETF x y) expands to something depending on the structure of x:
symbol ==> (SETQ x y)
(CAR x') ==> (RPLACA x' y)
(VREF v i) ==> (WHATEVER-VECTOR-SET-IS v i y)
...
(SETF (UNKNOWN-SETTER v) y) expands to something like Lyn's or T's method,
where the setter is looked up dynamically.
So, SETF is a smart macro that either knows a lot about built-in setters, or
at least does the lookup once at compile time rather than repeatedly. It
*is* definable in T and presumably in LISP as well. I wouldn't call it a
language extension; it doesn't let the language do anything it couldn't do
anyways.
One thing that neither Lyn nor T can handle -- I don't know about Lisp -- is
function equality:
(LSET ELEMENTS '((EARTH AIR FIRE WATER)))
(DEFINE (MY-PERSONAL-CAR X) (CAR X))
(SET (MY-PERSONAL-IDENTITY ELEMENTS)
(APPEND '(HYDROGEN HELIUM LITHIUM ... LAWRENCIUM) (CAR ELEMENTS)))
Now, MY-PERSONAL-IDENTITY is the car function, and lambda-calculus people
like me would like to have (CAR X) and (MY-PERSONAL-IDENTITY X) behave
precisely the same under all circumstances. I'm willing to let the
programming-language people tell me that it'll run slower, it will show up in
backtraces, it may overflow the stack, and so forth. I'm not so willing to
learn that it doesn't behave the same in a simple usage like this.
Another example:
(SET (CAAR X) Y) works
(SET ((COMPOSE CAR CAR) X) Y) doesn't.
In particular, my high-order functional program can build up an accessor
function which ought to have a corresponding mutator, but the mutator can't
be found because the accessor we built isn't EQ? to the accessor in the
table.
I'll stop being idiotic about programming languages now, and admit that the
table-lookup method is much simpler to implement that any ideas I have about
getting SET to work right with higher-order programming. Still, there might
be some not-too-horrible way to get it to work better. Any ideas?
-- Bard the (LAMBDA (X) GARGOYLE)
∂10-May-88 0822 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 08:22:34 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 10:47:51 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA13993@BLOOM-BEACON.MIT.EDU>; Tue, 10 May 88 07:37:54 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 10 May 88 02:16:56 GMT
From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer)
Organization: Dept of Math and CS, UMass Boston.
Subject: Re: ``Update functions'' in Scheme.
Message-Id: <632@umb.umb.edu>
References: <411493.880427.SCHREQ@MC.LCS.MIT.EDU>, <8805031911.AA04352@basel>, <28710@yale-celray.yale.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Following the discussion on assignments in Scheme, and how to have them
performed in subroutines, the following question strikes my mind:
*** Why didn't the designers of Scheme include locations (~anonymous variables)
as first-class values in the language? ***
Wouldn't that fit the Scheme philosophy of orthogonality and 'first-class
everything'? After all, locations are part of the denotational semantics of
Scheme, so this wouldn't be much of an extension to Scheme from an abstract
point of view.
A variable would then be an identifier bound to a location, and we would have
true constants as well, by binding identifiers to values that are not
locations. All identifier bindings would then be irreversible, only locations
could be updated (thus indirectly updating identifiers bound to them).
If that sounds too abstract, consider the following hypothetical program
fragment:
(let ((x (var 1)) ; VAR creates a new location and
(y 1)) ; initializes it to its argument
(set! x 2)
(set! x (+ val x) 2)) ; VAL looks up the current value of x
(set! x (+ y 2))) ; y can't be set! and needn't be val'ed
The cons function would have to create a pair of locations and initialize them
to its arguments. (So that we could make sense of setcar!)
We could now also write a 'swap' function as in
(define (swap x y) ; actual arguments must be variables
(let ((h (val x)))
(set! x (val y))
(set! y h)))
This would not violate the 'call by value' principle, since locations would
_be_ values. First-class variables shouldn't give us any more headaches than
side-effects per se. Separating constants from variables should even simplify
some compiler optimizations (for the constants).
For the very least, we would get rid of having to write macros or extend the
syntax in order to abstract over assignments.
Any takers?
--
------------------------------------------------------------------------------
Gerald "When I use a word, it means
<gerald@grn.umb.edu> exactly what I want it to mean"
(Humpty Dumpty, Through the Looking Glass)
∂10-May-88 0925 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: set in Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 09:25:22 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 May 88 12:01:56 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA18910@BLOOM-BEACON.MIT.EDU>; Tue, 10 May 88 11:57:36 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 9 May 88 17:17:37 GMT
From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: Re: set in Scheme?
Message-Id: <411@aiva.ed.ac.uk>
References: <1822@uhccux.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <1822@uhccux.UUCP> chin@uhccux.UUCP (David Chin) writes:
>Does anyone know how to do the equivalent of a Common Lisp "set" in
>Scheme. In particular, I would like to be able to pass different
>symbols as arguments to a function and then set! or define them inside
>the function.
Standard (R3RS) Scheme does not have anything of this sort.
>Is this style of programming (global side-effects for
>function calls) contrary to the Scheme philosophy?
Probably.
What you can do in Scheme is to use a different abstraction rather
than passing symbols to set. For example:
(define (make-cell contents)
(list contents))
(define (cell-contents cell) (car cell))
(define (set-cell-contents! cell new-contents)
(set-car! cell new-contents))
Instead of passing a symbol, you would give the symbol a cell as its
value and pass the value of the symbol (the cell). Set-cell-contents!
could then be used to change the value in the cell.
So: (define (set-three! cell) (set-cell-contents! call 3))
(define x (make-cell 2))
(set-three! x)
Then (cell-contents x) ==> 3.
An alternative approach would be to pass a function instead of the symbol.
This function could be called to get or set the symbol's value. This can
be made to look nicer by using macros. The code below is meant to look
a bit like "locatives" in T:
(defmacro (symbol-locative sym)
(let ((temp-name (different-symbol sym)))
`(make-symbol-locative
(lambda () ,sym)
(lambda (,temp-name) (set! ,sym ,temp-name)))))
(define (different-symbol s)
(if (eq? s 'x) 'y 'x))
(define (make-symbol-locative get-thunk set!-thunk)
(lambda (message)
(cond ((eq? message 'get) get-thunk)
((eq? message 'set!) set!-thunk))))
(define (contents locative)
((locative 'get)))
(define (set-contents! locative new-contents)
((locative 'set!) new-contents))
The example again:
(define set-three! (loc) (set-contents! loc 3))
(define x 2)
(set-three (symbol-locative x))
Then x ==> 3.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂10-May-88 1020 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 10:20:43 PDT
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 10 May 88 12:16:08 EDT
Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177642; Tue 10-May-88 12:13:04 EDT
Date: Tue, 10 May 88 12:12 EDT
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: ``Update functions'' in Scheme.
To: lyn@BASEL.AI.MIT.EDU, Ram-Ashwin@YALE-ZOO.ARPA
cc: scheme@mc.lcs.mit.edu, stever@WAIKATO.S4CC.Symbolics.COM
In-Reply-To: <8805100251.AA08745@basel>
Message-ID: <19880510161237.7.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Mon, 9 May 88 22:51:49 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
> I don't know about Common Lisp's SETF, but in the T dialect of Scheme there is a
> difference between the two. When you write (SET (FOO ...) ...), the operation
> FOO can specify how it is to be set, i.e., it can handle the operation (SETTER
> FOO) and return a setter procedure, which then does the setting appropriately.
Pages 94-107 of Common Lisp The Language will probably clarify Common Lisp's
SETF semantics.
All SETF does is to provide a connection between an accessor and its
corresponding mutator. I suggested that an appropriate naming convention
served many of the same purposes as SETF.
SETF is a macro. It does more complicated source-to-source transformations
than simple name substitution.
(LDB (BYTE 4 2) (AREF MY-ARRAY 0))
returns four bits from MY-ARRAY's first element (a number).
(SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0))
sets the four bits in MY-ARRAY's first element (a number).
This is a case which can't be modeled as simply turning LDB into a call to
SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to
SET-LDB, but that won't change the number that's stored in MY-ARRAY.
For the interested, here's a brief description of SETF.
(SETF place value)
`place' is something that looks syntactically like a function call.
You define a SETF method for a given place. The SETF method tells how to
access and modify that place.
For example:
(SETF (CAR xxx) value) The "place" is (CAR xxx)
The SETF method for CAR says that to change the value in a CAR place, expand
into (RPLACA xxx value). To access the value in the place, expand into
(CAR xxx).
Macros other than SETF use this information. (INCF place) increments the value
stored in a place. For INCF, `place' has to be read as well as written.
(INCF MY-VARIABLE)
has roughly the same effect as (SETF MY-VARIABLE (+ 1 MY-VARIABLE)).
But SETF methods give a little more precision than that. If the expansion was
just (INCF xxx) => (SETF xxx (+ 1 xxx)), consider:
(INCF (AREF *MY-ARRAY* (INCF *SUBSCRIPT*)))
expanding into:
(SETF (AREF *MY-ARRAY* (INCF *SUBSCRIPT*))
(+ 1 (AREF *MY-ARRAY* (INCF *SUBSCRIPT*))))
We'd only like (INCF *SUBSCRIPT*) evaluated once. It only occurs once in the
source code. But the straightforward expansion includes it twice.
SETF methods take care of making sure that \subforms of `place'/ are only
evaluated once.
Written using SETF methods, INCF actually expands into:
(LET ((SUBSCRIPT (INCF *SUBSCRIPT*))
(ARRAY *MY-ARRAY*))
(ARRAY-STORE ARRAY SUBSCRIPT (1+ (AREF ARRAY SUBSCRIPT))))
--------------------
So SETF is NOT a function, and actually provides a set of source code
transformations that can be used to disassemble references to `place's and
reassemble them.
In the simplest case, SETF can be thought of as a simple link between an
accessor and a mutator. But SETF's underlying mechanism, SETF methods, give
far more power.
unfortunately, as Bard Bloom has pointed out to me, a simple naming convention
does not work if we wish to use the relationship between accessor and mutator in
a more abstract way. An example derived from the one Bard showed me is:
(define (act-foolishly-on accessor object)
(setf (accessor object) (list (accessor object) "silly"))
object)
Common LISP's SETF won't work in this example. SETF does a syntactic
transformation on its first operand. It doesn't evaluate the first operand.
Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined
for "accessor."
Notice: these are only the Common Lisp semantics for SETF. It's entirely
possible that some functional (vs. macrological) definition of SETF can be
reached. But my hunch is that it \will/ require some special evaluation rules.
-- Stephen
∂10-May-88 1111 @MC.LCS.MIT.EDU,@WAIKATO.S4CC.Symbolics.COM,@JEWEL-CAVE.S4CC.Symbolics.COM:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 11:11:36 PDT
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 10 May 88 12:17:26 EDT
Received: from JEWEL-CAVE.S4CC.Symbolics.COM (JEWEL-CAVE.S4CC.Symbolics.COM) by WAIKATO.S4CC.Symbolics.COM via INTERNET with SMTP id 177644; 10 May 88 12:16:05 EDT
Date: Tue, 10 May 88 12:15 EDT
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: ``Update functions'' in Scheme.
To: bard@THEORY.LCS.MIT.EDU, lyn@BASEL.AI.MIT.EDU, scheme@mc.lcs.mit.edu
In-Reply-To: <8805100302.AA01261@TOUCAN.LCS.MIT.EDU>
Message-ID: <19880510161546.8.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Mon, 9 May 88 23:02:20 ast
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
I'm not exactly sure what a language extension is. I am pretty sure that
SETF in Lisp is a macro.
Yep [see my previous message].
(SETF (UNKNOWN-SETTER v) y) expands to something like Lyn's or T's method,
where the setter is looked up dynamically.
This will give a compiletime error that no SETF method is known for
UNKNOWN-SETTER.
- Stephen
∂10-May-88 1203 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET Re: ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 12:02:55 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 10 May 88 12:18:25 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1870; Tue, 10 May 88 10:19:53 EDT
Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
id 1759; Tue, 10 May 88 10:07:53 EDT
Received: by tub.UUCP; Tue, 10 May 88 10:35:01 +0200; AA17323
Date: Tue, 10 May 88 10:35:01 +0200
From: Oliver Laumann <net%TUB.BITNET@MITVMA.MIT.EDU>
Message-Id: <8805100835.AA17323@tub.UUCP>
To: lyn@basel.ai.mit.edu
Subject: Re: ``Update functions'' in Scheme.
Cc: Ram-Ashwin@yale-zoo.arpa, scheme@mc.lcs.mit.edu
> [example where a function (setter accessor) obtains the mutator for
> a given accessor function by table lookup]
> The key point here is that Scheme already has enough power to express
> the abstract relationship between accessors and mutators; there is no
> need to "extend" the language to provide this feature.
If this is true, then please tell me how you would do the following
using the method you described.
Suppose I want to write a new print function that involves a ``print length''.
The function (print-length) should serve both as an accessor and as a
mutator for the actual print length. That is,
(print-length)
simply returns the current print length, while
(set! (print-length) 20)
should be used to change the print length (changing it would include some
kind of sanity check).
Using the extension to Scheme I outlined in a previous message, the actual
variable holding the print length (say, *print-length*) could be a local
variable to the combined accessor/mutator function:
(define print-length
(let ((*print-length* 100))
(lambda ...
How would you do something like this using the method you proposed
without employing a global variable?
--
Regards,
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
∂10-May-88 1716 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: Update functions in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 17:15:49 PDT
Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 10 May 88 19:45:00 EDT
Date: 10 May 1988 18:55-EDT
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
To: scheme@mc.lcs.mit.edu
Cc: bap@f
Subject: Re: Update functions in Scheme.
Message-Id: <Tue.May.10.18:55:49.1988/bap@F.GP.CS.CMU.EDU>
Interestingly, in Oaklisp the interaction between COMPOSE and SETTER
that Bard Bloom desires is easy to obtain in a modular way, due to the
way that settable operations are plugged into the type system:
(define compose (make operation))
(add-method (compose (operation) f g)
(lambda (z) (f (g z))))
(add-method (compose (settable-operation) f g)
(let ((fg (make settable-operation)))
(add-method (fg (object) z) (f (g z)))
(add-method ((setter fg) (object) z x)
(set! (f (g z)) x))
fg))
[ Lets exhibit modularity by making this work for locatable operation too:
(add-method (compose (locatable-operation) f g)
(let ((fg (make locatable-operation)))
(add-method ((locater fg) (object) z)
(make-locative (f (g z))))
fg)) ]
==================
Of course, the problem of getting (DEFINE (FOO X) (BAR X)) to make FOO
just as settable as BAR is not so easily addressed. The difficulty here
is local variables, so one approach is to get rid of all the variable by
translating everything down to a set of combinators. For instance,
(define (foo a b) (if a (car b) (car (cdr b))))
would first get curried to
(define foo (lambda (a) (lambda (b) (if a (car b) (car (cdr b)))))),
while we note that (SET! (FOO X Y) Z) gets curried to (SET! ((FOO X) Y) Z).
Some nesting gets removed
(define foo (lambda (a) (lambda (b) (if a (car b) (((compose car) cdr) b))))),
we get rid of B
(define foo (lambda (a) (if a car ((compose car) cdr)))),
and use the combinator which could be defined as follows:
(define %if
(lambda (f)
(lambda (g)
(lambda (test)
(if test f g)))))
to rewrite FOO to
(define foo (%if car ((compose car) cdr))).
Now, assuming that %IF carries through settableness (which it should do
automatically the way Oaklisp COMPOSE did above), i.e.
(setter ((%if f) g)) <=> ((%if (setter f)) (setter g)),
our side effect attempt
(set! ((foo x) y) z)
gets macroexpanded to
(((setter (foo x)) y) z)
which works.
In order to demonstrate that it works, we can work things through.
Substituting in foo's definition, we have
(((setter ((%if car) ((compose car) cdr))) y) z)
which is the same as
((((%if (setter car)) (setter ((compose car) cdr))) y) z)
which is the same as
((((%if (setter car)) ((compose (setter car)) cdr)) y) z)
which, decurrying and reintroducing some variables, is the same as
((%if (lambda (b) ((setter car) b z))
(lambda (b) ((setter car) (cdr b) z))
x) y z)
which is the same as
(if x (set! (car y) z)
(set! (car (cdr y)) z)).
I find it more than a little perverse to use combinators in an effort to
make side effects more convenient.
--Barak.
Acknowledgments: I would like to thank Peter Lee for his moral support.
∂10-May-88 1917 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 19:17:49 PDT
Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 10 May 88 21:45:29 EDT
Received: by BASEL.AI.MIT.EDU; Tue, 10 May 88 22:37:46 edt
Date: Tue, 10 May 88 22:37:46 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
Message-Id: <8805110237.AA09496@basel>
To: Stever@WAIKATO.S4CC.Symbolics.COM
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Stephen Robbins's message of Tue, 10 May 88 12:12 EDT <19880510161237.7.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Subject: ``Update functions'' in Scheme.
> So SETF is NOT a function, and actually provides a set of source code
> transformations that can be used to disassemble references to `place's and
> reassemble them.
I never claimed that SETF was a function, just that you could achieve
much of its functionality with an ordinary Scheme procedure.
> Common LISP's SETF won't work in this example. SETF does a syntactic
> transformation on its first operand. It doesn't evaluate the first operand.
>
> Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined
> for "accessor."
This is exactly what I *DON'T* like about a "macrological" SETF - you
can't abstract over it! If in fact we want to think about and manipulate
the abstract relationship between accessors and mutators, a text-based
model is simply not sufficient.
> (LDB (BYTE 4 2) (AREF MY-ARRAY 0))
> returns four bits from MY-ARRAY's first element (a number).
> (SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0))
> sets the four bits in MY-ARRAY's first element (a number).
>
> This is a case which can't be modeled as simply turning LDB into a call to
> SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to
> SET-LDB, but that won't change the number that's stored in MY-ARRAY.
This seems to be another version of Bard's "composition" example - is
it possible to get a functional SETF-like frob to work in
"higher-order" cases? Like Bard, I'd be interested in any ideas on this
matter.
- Lyn -
∂10-May-88 1953 @MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 19:53:16 PDT
Received: from basel (TCP 2206400245) by MC.LCS.MIT.EDU 10 May 88 21:45:51 EDT
Received: by BASEL.AI.MIT.EDU; Tue, 10 May 88 22:22:13 edt
Date: Tue, 10 May 88 22:22:13 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
Message-Id: <8805110222.AA09484@basel>
To: net%TUB.BITNET@MITVMA.MIT.EDU
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Oliver Laumann's message of Tue, 10 May 88 10:35:01 +0200 <8805100835.AA17323@tub.UUCP>
Subject: ``Update functions'' in Scheme.
> > The key point here is that Scheme already has enough power to express
> > the abstract relationship between accessors and mutators; there is no
> > need to "extend" the language to provide this feature.
>
> If this is true, then please tell me how you would do the following
> using the method you described.
>
> Suppose I want to write a new print function that involves a ``print length''.
> The function (print-length) should serve both as an accessor and as a
> mutator for the actual print length. That is,
>
> (print-length)
>
> simply returns the current print length, while
>
> (set! (print-length) 20)
>
> should be used to change the print length (changing it would include some
> kind of sanity check).
>
> . . .
>
> How would you do something like this using the method you proposed
> without employing a global variable?
We can get a version of PRINT-LENGTH without using a global variable
to hold the state as follows:
; --------------------------------------------------------------------------
; Wrap up the print-length state variable into a "generating"
; procedure that can provide us with both the accesor and mutator
(define print-length-maker
(let ((*print-length* 100)) ; This state is local to the following procedure
(lambda (m)
(cond ((eq? m 'accessor)
(lambda () *print-length*))
((eq? m 'mutator)
(lambda (new-val) (set! *print-length* new-val)))
; Could also include "sanity check" here
(else (error "Don't understand!"))))))
; Now define the accessor . . .
(define print-length (print-length-maker 'accessor))
; . . . and insert the mutator into the SETTER table we defined before.
(table-insert! *setter-table* print-length (print-length-maker 'mutator))
; Test it out:
(print-length)
;Value: 100
((setter print-length) 20)
;Value: 100
(print-length)
;Value: 20
; --------------------------------------------------------------------------
Note that the same idea could be used to get rid of the global
*setter-table* as well.
- Lyn -
∂10-May-88 2256 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 88 22:56:07 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 10 May 88 23:38:39 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Tue, 10 May 88 23:08:02 edt
Date: Tue, 10 May 88 23:08:02 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8805110308.AA04003@chamarti>
To: lyn@BASEL.AI.MIT.EDU
Cc: Stever@WAIKATO.S4CC.Symbolics.COM, scheme@mc.lcs.mit.edu
In-Reply-To: Franklyn Turbak's message of Tue, 10 May 88 22:37:46 edt <8805110237.AA09496@basel>
Subject: ``Update functions'' in Scheme.
Reply-To: jinx@zurich.ai.mit.edu
Kludge of the week:
(define (compose f g)
(let ((the-composition
(lambda (x)
(f (g x)))))
(if (has-setter? f)
(declare-setter the-composition
(let ((core (setter f)))
(lambda (new-value x)
(core new-value (g x))))))
the-composition))
PS: Aren't first-class procedures fun? :-)
∂11-May-88 0506 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:IS7397@JPNSUT30.BITNET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 May 88 05:06:14 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 May 88 08:02:44 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9131; Wed, 11 May 88 08:00:10 EDT
Received: from JPNSUT30.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
9130; Wed, 11 May 88 08:00:09 EDT
Received: by JPNSUT30 (Mailer X1.25) id 8953; Wed, 11 May 88 17:36:53 JST
DATE: WED, 11 MAY 1988 17:35 JST
FROM: Toshio Matsuda <IS7397%JPNSUT30.BITNET@MITVMA.MIT.EDU>
TO: <SCHEME@MC.LCS.MIT.EDU>
Please enter my name in your mailing list.
∂11-May-88 1331 @MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 May 88 13:30:44 PDT
Received: from WAIKATO.S4CC.Symbolics.COM (TCP 20024231532) by MC.LCS.MIT.EDU 11 May 88 16:14:56 EDT
Received: from JEWEL-CAVE.S4CC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177839; Wed 11-May-88 08:53:28 EDT
Date: Wed, 11 May 88 08:53 EDT
From: Stephen Robbins <Stever@WAIKATO.S4CC.Symbolics.COM>
Subject: ``Update functions'' in Scheme.
To: lyn@BASEL.AI.MIT.EDU
cc: scheme@mc.lcs.mit.edu
In-Reply-To: <8805110237.AA09496@basel>
Message-ID: <19880511125310.0.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Tue, 10 May 88 22:37:46 edt
From: lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
> Common LISP's SETF won't work in this example. SETF does a syntactic
> transformation on its first operand. It doesn't evaluate the first operand.
>
> Compiling ACT-FOOLISHLY-ON will give the error that no SETF method is defined
> for "accessor."
This is exactly what I *DON'T* like about a "macrological" SETF - you
can't abstract over it! If in fact we want to think about and manipulate
the abstract relationship between accessors and mutators, a text-based
model is simply not sufficient.
I agree. That's one reason I'm watching this discussion so closely.
> (LDB (BYTE 4 2) (AREF MY-ARRAY 0))
> returns four bits from MY-ARRAY's first element (a number).
> (SETF (LDB (BYTE 4 2)) (AREF MY-ARRAY 0))
> sets the four bits in MY-ARRAY's first element (a number).
>
> This is a case which can't be modeled as simply turning LDB into a call to
> SET-LDB. (AREF MY-ARRAY 0) may fetch a number from MY-ARRAY and pass it to
> SET-LDB, but that won't change the number that's stored in MY-ARRAY.
This seems to be another version of Bard's "composition" example - is
it possible to get a functional SETF-like frob to work in
"higher-order" cases? Like Bard, I'd be interested in any ideas on this
matter.
Question: The LDB example is "one order higher" than a straight SETQ. Are
there any examples that are more than one order higher?
- Stephen
∂11-May-88 1913 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU ``Update functions'' in POP2.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 May 88 19:13:38 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 May 88 21:54:59 EDT
Date: Wed, 11 May 88 10:50:47 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: ``Update functions'' in POP2.
To: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 9 May 88 22:51:49 edt from lyn@BASEL.AI.MIT.EDU (Franklyn Turbak)
Message-ID: <375448.880511.JAR@AI.AI.MIT.EDU>
Someone, I don't remember who, pointed out that the "setter" idea (i.e.
a function that maps an access procedure (not its name) to a
corresponding mutator) is not original with T, but was in the language
POP2. Does anyone know of a reference for this? Does anyone know how
this was implemented (global table as in Lyn's message, or local
association as in T)?
∂11-May-88 2010 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 May 88 20:10:24 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 May 88 21:55:38 EDT
Date: Wed, 11 May 88 12:36:21 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: cells
To: umb!gerald%husc6.harvard.edu@XX.LCS.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 10 May 88 02:16:56 GMT from umb!gerald@husc6.harvard.edu (Gerald Ostheimer)
Message-ID: <375517.880511.JAR@AI.AI.MIT.EDU>
Date: 10 May 88 02:16:56 GMT
From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer)
*** Why didn't the designers of Scheme include locations (~anonymous
variables) as first-class values in the language? ***
A variable would then be an identifier bound to a location, and we
would have true constants as well, by binding identifiers to values
that are not locations. All identifier bindings would then be
irreversible, only locations could be updated (thus indirectly
updating identifiers bound to them).
I think Steele considers this possibility in one of the notes in the
Rabbit tech report. Probably it had to do with fitting in with existing
Lisp implementations gracefully and efficiently; there are some sticky
performance problems with locations (if pairs always consist of two
locations, how do you represent those locations? Do you allocate three
objects when you create the pair? That makes pairs too expensive. Do
you allocate stored objects representing the locations on demand (like
locatives in T)? That makes locations too expensive to be useful. Are
locations immediate objects (like locatives on the MIT-derived Lisp
Machine systems)? This complicates data representations and the gc.
Are pairs immutable? What about arrays? Etc. etc.).
Any takers?
Plenty, including the designers of Algol 68, PLASMA, and ML. If you did
this to Scheme I think you'd have quite a different language, different
enough that it would require significant changes to implementation
strategies.
∂11-May-88 2149 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 May 88 21:49:40 PDT
Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 12 May 88 00:05:54 EDT
Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Tue, 10 May 88 11:52:58 ast
Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Tue, 10 May 88 11:52:55 ast
Date: Tue, 10 May 88 11:52:55 ast
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
Message-Id: <8805101552.AA02100@TOUCAN.LCS.MIT.EDU>
To: umb!gerald@husc6.harvard.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Gerald Ostheimer's message of 10 May 88 02:16:56 GMT <632@umb.umb.edu>
Subject: ``Update functions'' in Scheme.
> Following the discussion on assignments in Scheme, and how to have them
> performed in subroutines, the following question strikes my mind:
>
> *** Why didn't the designers of Scheme include locations (~anonymous variables)
> as first-class values in the language? ***
One possible reason (for T at any rate) is that setting is more general than
simply putting a value into a location. For a slightly contrived example,
let's take an abstract data type of complex numbers in which all the
coordinates are settable:
(LSET C (MAKE-COMPLEX-FROM-RECTANGULAR 0.3 10.8))
(SET (COMPLEX-THETA C) (/ PI 2))
(SET (COMPLEX-X C) 0.0)
Now, the X, Y, R, and THETA attributes of a complex number aren't all going
to be stored in variables. Even if they were it wouldn't help: setting (X C)
will usually change the values that (R C) and (THETA C) should have.
In general, the operation of stuffing a value into a location is
inappropriate for abstract data types: even when it works, it is too
implementation-dependent. There's no choice but to use mutator procedures.
Since we have to use them anyways, why not be clean and not bother with
locations? Do you really want to imitate BLISS and require explicit
dereferencing for every mutable variable?
-- Bard the (LAMBDA (X) GARGOYLE)
(P.S.: That's a good enough argument for theoreticians like me. T actually
has locatives. I don't know how they work.)
∂12-May-88 0004 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 00:04:25 PDT
Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 12 May 88 02:58:33 EDT
Date: 12 May 1988 02:18-EDT
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: scheme@mc.lcs.mit.edu
Subject: Re: cells
Message-Id: <Thu.May.12.02:18:44.1988/bap@F.GP.CS.CMU.EDU>
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
... If you did this [added locatives] to Scheme I think you'd have
quite a different language, different enough that it would require
significant changes to implementation strategies.
Well, I don't know. Even though I'm not a big fan of locatives we
included them in our implementation of Oaklisp and I'm not sure if they
haired things up at all when you take the final tally. We used two low
tag bits and allocated #b10 for locatives, so they were immediates.
Data representation wasn't any hairier to speak of, but the presence of
"raw cells" did make the gc code about 3 times as long as it would
otherwise have been, and maybe 20% slower.
It's hard to say whether they were a net win, but they certainly weren't
a big complication. If "computer science" really deserved its name I
guess I'd reimplement Oaklisp again without them and find out. They do
let vectors and structures (including environments) get gc'ed when all
that's left is a pointer to something in their innards, which is nice,
and they did simplify the internals considerably, especially
representing environments and closing over instance variables and
dealing with globals and low level stuff like that.
--Barak.
∂12-May-88 0225 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com Meeting 24 July 1988
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 02:25:20 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 May 88 20:26:11 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ag02468; 11 May 88 14:53 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ew09393; 11 May 88 14:38 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA14832; Tue, 10 May 88 12:05:29 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA24380; Tue, 10 May 88 12:06:05 PDT
Message-Id: <8805101906.AA24380@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: willc%tekchips.crl.tek.com@RELAY.CS.NET
Subject: Meeting 24 July 1988
Date: 10 May 88 12:06:02 PDT (Tue)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
The third occasional meeting of the Revised↑n Report authors will
take place on Sunday, 24 July 1988, at Snowbird, Utah. This is the
day before the ACM Conference on Lisp and Functional Programming,
also at Snowbird. The exact time and place will be announced later,
as will the registration fee (if any); I have requested a room for
thirty people from 8:30 am to 5 pm. Hal Abelson will chair the meeting.
Please let me know immediately if you intend to attend. If it appears
that too many people are planning to come, we'll have to do something
about it. If you are coming, please send me your address and telephone
number.
Detailed proposals for changes to the R3RS should be submitted to me
by 15 June. This should allow the agenda committee (Jonathan Rees and
myself?) to collate and edit the proposals in time to distribute them
two weeks before the meeting. Participants should study these proposals
before coming to Snowbird.
This meeting of the RRRS authors is entirely separate from the IEEE
Scheme standardization meeting that is planned for the afternoon of
Wednesday, 27 July 1988, following the conference.
William Clinger
Semantic Microsystems, Inc.
4470 SW Hall Blvd, Suite 340
Beaverton OR 97005
(503) 643-4539
∂12-May-88 0418 @MC.LCS.MIT.EDU:sas@alice.bbn.com ``Update functions'' in POP2.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 04:18:35 PDT
Received: from BBN.COM (TCP 20026200172) by MC.LCS.MIT.EDU 12 May 88 07:15:18 EDT
Received: from alice.bbn.com by BBN.COM id aa15193; 12 May 88 7:13 EDT
Date: Thu May 12 07:20:04 EDT 1988
From: sas@BBN.COM
To: JAR@ai.ai.mit.edu
CC: scheme@mc.lcs.mit.edu
In-reply-to: Jonathan A Rees's message of Wed, 11 May 88 10:50:47 EDT <375448.880511.JAR@AI.AI.MIT.EDU>
Subject: ``Update functions'' in POP2.
What is POP2?
I remember SIMSCRIPT had setter functions back in the late 60's. It
had a FORTRAN/PL/I syntax and allowed you define a function for use on
the left hand side OR the right hand side of the equal sign in an
assignment. They also had an inheritence based type system which was
kind of neat.
Does anyone want to count Algol 60's call by name as an example of
implicit generation of setter functions?
Seth
P.S. Any other grand old approaches/solutions to the setter problem
flopping around in your memory banks?
∂12-May-88 0721 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Meeting 24 July 1988
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 07:20:59 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 May 88 10:18:46 EDT
Received: from [129.10.1.2] by RELAY.CS.NET id aa11146; 12 May 88 10:12 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa04383; 12 May 88 10:11 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4)
id AA03810; Thu, 12 May 88 10:10:22 EDT
Date: Thu, 12 May 88 10:10:22 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Message-Id: <8805121410.AA03810@corwin.CCS.Northeastern.EDU>
To: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Cc: rrrs-authors@mc.lcs.mit.edu, willc%tekchips.crl.tek.com@RELAY.CS.NET
In-Reply-To: willc%tekchips.CRL%tektronix.tek.com@relay.cs.net's message of 10 May 88 12:06:02 PDT (Tue) <8805101906.AA24380@tekchips.CRL.TEK.COM>
Subject: Meeting 24 July 1988
Yes, I am planning to come to the Sunday R*RS meeting. (Also the IEEE
meeting).
--Mitch
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂12-May-88 0848 @MC.LCS.MIT.EDU:mac@uvacs.cs.virginia.edu Re: ``Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 08:48:28 PDT
Received: from uvaarpa.virginia.edu (TCP 20043601007) by MC.LCS.MIT.EDU 12 May 88 11:44:02 EDT
Received: from virginia.edu by uvaarpa.virginia.edu id aa02529;
12 May 88 11:42 EDT
Received: from uvacs.cs.virginia.EDU by virginia.acc.virginia.EDU id ac06432;
12 May 88 10:41 CDT
Received: by uvacs.cs.virginia.edu (5.51/5.1.UVA)
id AA04762; Thu, 12 May 88 11:32:10 EDT
From: Alex Colvin <mac@uvacs.cs.virginia.edu>
Posted-Date: Thu, 12 May 88 11:32:09 EDT
To: scheme@mc.lcs.mit.edu, mac@uvacs.cs.virginia.edu
Subject: Re: ``Update functions'' in Scheme.
In-Reply-To: Your message of Wed, 11 May 88 08:53:00 EDT.
<19880511125310.0.STEVER@JEWEL-CAVE.S4CC.Symbolics.COM>
Date: Thu, 12 May 88 11:32:09 EDT
SETL, the set language, used such left-hand-side ("sinister") update
functions and made them compose correctly. Unfortunately, I no longer have
a SETL manual available.
As I recall, evaluating nested updates can involve two calls to functions,
one in a dexter context and one in a sinister context.
F(G(A)) <- B
should ensure that, after assignment,
F(G(A)) = B
It seems like you need
T1 <- G(A) G dexter
F(T1) <- B F sinister
G(A) <- T1 G sinister
Now
F(G(A)) = F(T1) = B
As for about F(G(A),H(B)) <- C
T1 <- G(A), T2 <- H(B)
F(T1,T2) <- C
G(A) <- T1,H(B) <- T2
Anyone know SETL? Jeff?
∂12-May-88 1138 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU CPS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 11:37:58 PDT
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 12 May 88 14:34:27 EDT
Received: from A.ISI.EDU (a.isi.edu) by ZURICH.AI.MIT.EDU; Thu, 12 May 88 14:32:31 edt
Date: Thu 12 May 88 14:28:37-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: CPS
To: scheme@ZURICH.AI.MIT.EDU
Message-Id: <12397778009.46.MKATZ@A.ISI.EDU>
Does anyone know of any good references on continuation passing style? (My
apologies in advance for the fact that I am sure that this question has been
addressed at some point in the past on this mailing list.)
Morry Katz
-------
∂12-May-88 1545 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: ``Update functions'' in POP2.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 15:45:46 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 May 88 18:41:57 EDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02290; 12 May 88 23:22 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 12 May 88 21:53:25 bst
Message-Id: <5748.8805122053@aiva.ed.ac.uk>
To: JAR@ai.ai.mit.edu, scheme@mc.lcs.mit.edu
Subject: Re: ``Update functions'' in POP2.
Cc: aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK,
rhr%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
> Date: Wed, 11 May 88 10:50:47 EDT
> From: Jonathan A Rees <JAR@edu.mit.ai.ai>
> Subject: ``Update functions'' in POP2.
> Someone, I don't remember who, pointed out that the "setter" idea
> (i.e. a function that maps an access procedure (not its name) to a
> corresponding mutator) is not original with T, but was in the language
> POP2. Does anyone know of a reference for this? Does anyone know how
> this was implemented (global table as in Lyn's message, or local
> association as in T)?
Two recent references are:
Jonathan Laventhol. Programming in Pop-11.
Blackwell Scientific Publications, Oxford, 1987.
Rosalind Barrett, Allan Ramsay, and Aaron Sloman.
Pop-11: A Practical Language for Artificial Intelligence.
Ellis Horwood, 1985.
Pop-11 is the descendent of Pop2 that is part of Poplog.
In Pop, every object is of some type or "class". The class is re-
resented by an object called a "key". So part of each object is a
pointer to a key. There is, as one might expect, a "key key" for
key objects, including the key key. The procedure datakey returns
an object's key.
The key contains a procedure for each of the primitive operations such
as cons(truct), print, equal, and apply. For each primitive P, there
is a procedure class_P that takes a key and returns the appropriate
procedure. For example, class_apply of the vector key is a sub-
scripting procedure (subscripting may therefore be written as a
function call.)
Note that the key contains entries only for certain built-in
operations. You cannot, as far as I know, define new operations
of this sort. Anyway...
Class_access(i,key) returns an access procedure for the i-th field of
a record class. Vector classes are similar, except there is only one
accessing procedure. It takes a subscript as an argument and is
obtained by class_subscr(key).
So we have these access and subscipting procedures.
They, and other procedures, have various fields. The field of
interest here is the updater. The procedure updater returns the
updater of a procedure. It has an updater too, used to assign
the updater of a procedure.
If you do
set_whatever -> updater(whatever);
where whatever and set_whataver are procedures and -> is assignment
(in the obvious, but unusual, direction) then
x -> whatever(y).
will put x in the whatever part of y.
There is a symtax for defining updaters. You say
define updater whatever(newval, object) ... enddefine;
instead of
define set_whatever(newval, object) ... endefine;
set_whatever -> updater(whatever);
You can do the 'define updater' even if the accessing procedure
has not yet been defined, which may put some interesting constraints
on the implementation, but I do not know what the actual
implementation is.
-- Jeff
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂12-May-88 1732 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 17:32:28 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 12 May 88 20:29:13 EDT
Date: Thu 12 May 88 20:26:02-EDT
From: Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>
Subject: Cells
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12397843074.44.NIKHIL@XX.LCS.MIT.EDU>
From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer)
*** Why didn't the designers of Scheme include locations (~anonymous
variables) as first-class values in the language? ***
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Plenty, including the designers of Algol 68, PLASMA, and ML. If you did
this to Scheme I think you'd have quite a different language, different
enough that it would require significant changes to implementation
strategies.
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
... There's no choice but to use mutator procedures.
Since we have to use them anyways, why not be clean and not bother with
locations? Do you really want to imitate BLISS and require explicit
dereferencing for every mutable variable?
I don't understand why the introduction of locations in the sense that
Gerald Ostheimer suggested would make Scheme such a different or
unclean language.
I don't have his original message, but his proposal was something like
this (ala ML): The expression ``(VAR E1)'' would allocate a cell
containing the value of E1, and return a reference to it. If X is
bound to such a reference, then ``(GET-VAR X)'' returns the value in the cell,
and ``(SET-VAR! X E2)'' replaces the value in the cell with the value of E2.
Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the
one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of
SET-CAR!/SET-CDR!. So, why does it make the language so
different/unclean?
Such cells normally must be heap-allocated, so this may seem like
extra cost. But this is not obvious: A) Lifetime analysis could move
them to stack frames, and B) in many situations where one currently
must use a frame-variable in the heap, the one-slot cell may be a
cheaper alternative.
Nikhil
(I agree that arbitrary locatives, e.g. pointers to the middle of cons-cells,
would make things very unclean, but I don't think that was what Gerald O.
was proposing).
-------
∂12-May-88 1815 @MC.LCS.MIT.EDU:aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK updaters in POP-11/POP-2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 18:15:32 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 12 May 88 20:59:25 EDT
Received: from cvaxa.sussex.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00777; 13 May 88 1:52 BST
Received: from csuna (csuna.ARPA) by cvaxa.sussex.ac.uk; Fri, 13 May 88 01:37:29 bst
From: Aaron Sloman <aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 13 May 88 01:37:16 BST
Message-Id: <21107.8805130037@csuna.cvaxa.sussex.ac.uk>
To: jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: updaters in POP-11/POP-2
Cc: JAR@ai.ai.mit.edu, scheme@mc.lcs.mit.edu,
rhr%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Jeff,
Thanks for sending me a copy of your reply to the enquiry about
updaters. I had not seen the original. Which news group was it in?
Just a few comments, some of which Robert may already have made direct
to you.
(a) There is at present no complete published specification of POP-11
(the most recent descendent of POP-2) apart from the online "REF" files
distributed with Poplog. We plan to publish a proper reference manual,
but other work keeps getting in the way. The two books you referred to
both describe subsets of POP-11. The one by Laventhol (deliberately)
describes a smaller subset corresponding to the version for the Mac
known as Alphapop, reviewed in Byte May 1988. e.g. the book does
not include lexical variables.
Alphapop is distributed with a complete specification of Alphapop. In
the USA it is distributed by Prof Robin Popplestone, Dept of computer
science univ. of Amherst, and he can answer just about any question
about Pop-2 or Pop-11, being one of the main inventors of the original
language. (pop@cs.umass.edu)
(b) adding key fields
You say.
>Note that the key contains entries only for certain built-in
>operations. You cannot, as far as I know, define new operations
>of this sort.
Right. Keys as such are not extendable. However, Pop-11 also includes
"properties", i.e. hash tables, and if you wished to define the notion
of the class_something associated with each key, you'd make
class_something a property, set up the associations, then the syntax for
accessing or changing the class_something of a key would be the same as
for the built in class_ procedures, e.g.
'funny string' -> class_something(datakey(1))
would do it for the integer key. (Note that properties are treated
as a special type of function, and they therefore have updaters.)
The main limitation of Pop-11 keys is not the lack of extendability but:
1. There is no notion of a sub-class inheriting features from
a super-class (though there are OOP libraries)
2. It is hard to associate a key with a derived data type.
E.g. there is a key for pairs, but no notion of a key for
lists, built from pairs. Thus we can't give lists a different
class_print from pairs (e.g.pairs whose backs are neither pairs
nor nil).
(c) A minor correction. You say
>If you do
> set_whatever -> updater(whatever);
> then
> x -> whatever(y).
> will put x in the whatever part of y.
This is misleading. There need not be any notion of "the whatever
part of y". Strictly the only way to understand
x -> whatever(y)
is as follows:
put x on the stack,
put y on the stack,
call the updater of whatever
The updater of whatever can be any arbitrary procedure. It need not put
x (or anything else) anywhere, although putting x somewhere associated
with y is the NORMAL use of the updater mechanism.
(d) Another minor correction
You give the following incorrect Pop-11 syntax for defining updaters:
define updater whatever(newval, object) ... enddefine;
The actual keyword is not "updater" but "updaterof"
This syntax was not available in Pop2 - updaters had to be assigned
explicitly, using the updater of updater.
(e) A point of clarification
>You can do the 'define updater' even if the accessing procedure
>has not yet been defined, which may put some interesting constraints
>on the implementation, but I do not know what the actual
>implementation is.
It's simple. If "whatever" has not been defined, and you do
define updaterof whatever; ... enddefine;
Then a default un-executable procedure is created for whatever, and the
defined updater is associated with it. So you can do
x -> whatever(y)
even though the procedure whatever has not been defined, only its
updater. If you try running the procedure
whatever(999);
you'll get an error message
whatever(x);
;;; MISHAP - ONLY UPDATER DEFINED
;;; INVOLVING: <procedure whatever>
This could be (and probably is) achieved by making the default procedure
the Pop-11 closure:
mishap(%0,'ONLY UPDATER DEFINED'%);
i.e. the error procedure mishap "partially applied" to the number
0 (no error objects) and the string defining the error. A new closure
would be created for each undefined procedure.
Since in Pop-11 a closure is just a type of procedure (as is an array
or a property), it can be given an updater.
If you later define whatever, itself, then its previously defined
updater is transferred to the new version. This is because any time
you redefine a procedure its old updater (if any) is transferred to the
new procedure so that you don't have to do it explicitly.
Not all users appreciate that the convenience of updaters has a slight
speed penalty compared with having a separate "set" function: an extra
indirection is needed to get the updater. (This is optimised away if the
updater is one defined in the system or declared as a constant procedure
by the user.)
Cheers
Aaron
∂12-May-88 1915 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 19:15:47 PDT
Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 12 May 88 21:09:58 EDT
Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Thu, 12 May 88 21:07:38 ast
Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Thu, 12 May 88 21:07:29 ast
Date: Thu, 12 May 88 21:07:29 ast
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
Message-Id: <8805130107.AA03042@TOUCAN.LCS.MIT.EDU>
To: NIKHIL@XX.LCS.MIT.EDU
Cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: Rishiyur S. Nikhil's message of Thu 12 May 88 20:26:02-EDT <12397843074.44.NIKHIL@XX.LCS.MIT.EDU>
Subject: Cells
> I don't have his original message, but his proposal was something like
> this (ala ML): The expression ``(VAR E1)'' would allocate a cell
> containing the value of E1, and return a reference to it. If X is
> bound to such a reference, then ``(GET-VAR X)'' returns the value in the cell,
> and ``(SET-VAR! X E2)'' replaces the value in the cell with the value of E2.
>
> Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the
> one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of
> SET-CAR!/SET-CDR!. So, why does it make the language so
> different/unclean?
I withdraw most of my insult (which was "unclean"). It doesn't make the
language unclean. It's actually quite nice.
But I don't withdraw all of it. My point was that, in general (with most
abstract datatypes), stuffing a value into a location is the wrong thing to
do, and typically will break the abstraction. So, I want SETF in the
language, as the way to set an arbitrary mutable object. There is a
difference in connotation, if not denotation, between (SETF (VAR X) Y) and
(SET-VAR! X Y): the SETF emphasizes the abstraction, the SET-VAR! emphasizes
the pointers. Once we have SETF, I don't see any particular point to
SET-VAR!; hence my opinion that the language would be cleaner without it.
For that matter, Nihkil's "one-slot CONS" is a nice little mutable abstract
data type, and a good one with an efficient implementation. Just the thing
for building a lot of the abstract data types with mutators, I imagine.
-- Bard the (LAMBDA (X) GARGOYLE)
∂12-May-88 2106 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Updaters in Pop (reply to query)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 88 21:06:46 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 May 88 23:47:25 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA10974@BLOOM-BEACON.MIT.EDU>; Thu, 12 May 88 23:32:45 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 12 May 88 12:44:19 GMT
From: otter!kers@hplabs.hp.com (Christopher Dollin)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Subject: Updaters in Pop (reply to query)
Message-Id: <1510012@otter.hple.hp.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have seen lots of discussion in the Scheme mailing list about "setters",
including this one from Jonathan A Rees (which gives just about enough
context):
| Someone, I don't remember who, pointed out that the "setter" idea (i.e.
| a function that maps an access procedure (not its name) to a
| corresponding mutator) is not original with T, but was in the language
| POP2. Does anyone know of a reference for this? Does anyone know how
| this was implemented (global table as in Lyn's message, or local
| association as in T)?
I don't know how it was done in Pop2, but I *do* know how it is done in Pop11,
its indirect descendant (alive and kicking in Sussex University's Poplog and
Cognitive Applications Ltd AlphaPop).
Every procedure has a component called its _updater_, which is either a
procedure or the object _false_. When a procedure call appears as the target of
an assignment, this is treated as a call to its updater. Thus the command
E -> f( x ) (Pop assignments run left-to-right)
is treated as
updater( f )( E, x )
The updater component is an actual field of the procedure record, although it
could of course be implemented as a property (hash table) mapping procedures to
their updaters. This however would make access to the updater rather expensive.
_updater_ has an updater with the obvious effect, allowing the user to define
the update effect of her own procedures; the language has syntax to facilitate
this. Note that is the *procedure* that has the updater, not its name, so the
updaters of procedures passed as parameters are accessible in the same way as
procedures defined at the outermost level (well, of course they would. Wouldn't
they?).
I would be happy to answer any queries this incomplete account raises in email.
Regards, Kers. | If anything anyone lacks, they'll find it all ready in stacks.
∂13-May-88 0358 @MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu Snowbird
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 03:58:28 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 13 May 88 06:35:13 EDT
Received: by iuvax.cs.indiana.edu; id AA20624; Thu, 12 May 88 23:03:28 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Thu, 12 May 88 23:03:28 EST
From: Dan Friedman <dfried@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Snowbird
I will be at the Sunday and Wednesday afternoon meetings.
Dan
∂13-May-88 0732 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET readable code to SET recordfields
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 07:32:12 PDT
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 13 May 88 10:29:24 EDT
Received: from MITVMA.MIT.EDU (mitvma.mit.edu) by ZURICH.AI.MIT.EDU; Fri, 13 May 88 10:27:50 edt
Message-Id: <8805131427.AA26893@zurich>
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8136; Fri, 13 May 88 10:25:59 EDT
Received: from HNYKUN52.BITNET (EDH) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 8135; Fri, 13 May 88 10:25:56 EDT
Date: Fri, 13 May 88 13:25 N
From: <EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU>
Subject: readable code to SET recordfields
To: SCHEME@ZURICH.AI.MIT.EDU
X-Original-To: SCHEME@ZURICH.AI.MIT.EDU, EDH
To: scheme@zurich.ai.mit.edu
Cc:
Subject: readable code to SET recordfields
From: Edward Hoenkamp <EDH at HNYKUN52.BITNET>
(Arpa: EDH%HNYKUN52.BITNET@CUNYVM.CUNY.EDU)
Date: Fri May 13 13:20:13 1988
---
;;; What about this simple way of constructing and selecting records
;;; that will allow the fields to be globally 'set' even if the
;;; record is referred to by a variable.
;;; Edward Hoenkamp.
(define (make-bar struct)
(lambda (select . new-value)
(if (null? (car new-value)) ; if no new-value passed
(car (select struct)) ; select and leave as is
(set-car! (select struct) (caar new-value)))))
;;; choose appropriate selector names
(define (first:of name . new) (name (lambda(x) x) new))
(define (second:of name . new) (name cdr new))
(define (third:of name . new) (name cddr new))
;;; etcetera.
;;; Example
; >>> (define foo (make-bar '(a b c)))
; foo
; >>> (first:of foo)
; a
; >>> (second:of foo)
; b
; >>> (define baz '(d e))
; baz
; >>> ((lambda (x)
; (second:of x baz)) foo)
; ((d e) c)
; >>> (third:of foo)
; c
; >>> (second:of foo)
; (d e)
;
;;; Add your own syntactic sugar for macro expansion
;;; (and/or use vectors instead of lists).
∂13-May-88 0840 @MC.LCS.MIT.EDU:gls@Think.COM cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 08:40:13 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 11:17:55 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 13 May 88 11:13:56 EDT
Received: by kali.think.com; Fri, 13 May 88 11:13:52 EDT
Date: Fri, 13 May 88 11:13:52 EDT
From: gls@Think.COM
Message-Id: <8805131513.AA15052@kali.think.com>
To: JAR@ai.ai.mit.edu
Cc: umb!gerald%husc6.harvard.edu@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Jonathan A Rees's message of Wed, 11 May 88 12:36:21 EDT <375517.880511.JAR@AI.AI.MIT.EDU>
Subject: cells
Date: Wed, 11 May 88 12:36:21 EDT
From: Jonathan A Rees <JAR@ai.ai.mit.edu>
Date: 10 May 88 02:16:56 GMT
From: umb!gerald@husc6.harvard.edu (Gerald Ostheimer)
*** Why didn't the designers of Scheme include locations (~anonymous
variables) as first-class values in the language? ***
A variable would then be an identifier bound to a location, and we
would have true constants as well, by binding identifiers to values
that are not locations. All identifier bindings would then be
irreversible, only locations could be updated (thus indirectly
updating identifiers bound to them).
I think Steele considers this possibility in one of the notes in the
Rabbit tech report.
If so, I must yield credit to intellectual influence from Hewitt's PLASMA
system and Wegbreit's EL1 (ECL) language and system at Harvard. In EL1
everything was consistently an lvalue. In effect, you were always one
level of pointer indirection removed from the way you would do it in Lisp.
To pass a cons cell to a subroutine, the argument register would contain
the address of a location containing the pointer to the two-word cell.
Taking the car of this cons cell resulted in the address of the cell (i.e.,
the address of the memory word containing the CAR pointer), and taking the
cdr resulted in the address of the cell plus 1. PDP-10 byte pointers
made all this fairly convenient for objects smaller than one word.
--Guy
∂13-May-88 1052 @MC.LCS.MIT.EDU:gls@Think.COM Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 10:52:04 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 13:48:29 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 13 May 88 12:00:46 EDT
Received: by kali.think.com; Fri, 13 May 88 12:00:40 EDT
Date: Fri, 13 May 88 12:00:40 EDT
From: gls@Think.COM
Message-Id: <8805131600.AA15096@kali.think.com>
To: NIKHIL@xx.lcs.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Rishiyur S. Nikhil's message of Thu 12 May 88 20:26:02-EDT <12397843074.44.NIKHIL@XX.LCS.MIT.EDU>
Subject: Cells
Date: Thu 12 May 88 20:26:02-EDT
From: Rishiyur S. Nikhil <NIKHIL@xx.lcs.mit.edu>
...
Now, VAR is nothing more than a ``one-slot CONS''. GET-VAR is the
one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of
SET-CAR!/SET-CDR!. So, why does it make the language so
different/unclean?
...
The one-slot CONS
Is just a cell.
The two-slot CONS
Makes lists as well.
And I will bet
A coin of bronze
There isn't any
Three-slot CONS.
--The Great Quux
(apologies to Ogden Nash)
∂13-May-88 1202 @MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 12:02:09 PDT
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 13 May 88 14:11:14 EDT
Received: by GENEVA.AI.MIT.EDU; Fri, 13 May 88 14:10:36 edt
Date: Fri, 13 May 88 14:10:36 edt
From: jrm@GENEVA.AI.MIT.EDU (Joe Marshall)
Message-Id: <8805131810.AA22242@geneva>
To: gls@Think.COM
Cc: NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 13 May 88 12:00:40 EDT <8805131600.AA15096@kali.think.com>
Subject: Cells
I've heard a rumor
(dismissed as bunk)
A three-slot CONS
is called a HUNK.
∂13-May-88 1418 @MC.LCS.MIT.EDU:gls@Think.COM Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 14:18:19 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 13 May 88 17:12:57 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 13 May 88 17:08:58 EDT
Received: by kali.think.com; Fri, 13 May 88 17:08:51 EDT
Date: Fri, 13 May 88 17:08:51 EDT
From: gls@Think.COM
Message-Id: <8805132108.AA15361@kali.think.com>
To: edsel!jlm@labrea.stanford.edu
Cc: gls@Think.COM, NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Jim McDonald's message of Fri, 13 May 88 12:17:38 PDT <8805131917.AA28001@bhopal.lucid.com>
Subject: Cells
Date: Fri, 13 May 88 12:17:38 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Guy, is that a trick bet?
No, just goofing around.
The CDC 6500 had a lisp (UTEXAS?) with CAR, CDR, and CZR slots for the
three 18-bit addresses in their 60-bit words. However, if I remember
correctly, you would technically win your bet, since there still
wasn't a three-slot cons. You had to do something like:
(SETQ CELL (CONS A B))
(RPLACZ CELL C)
jlm
One of the earliest Lisp systems, when it was still just
a set of Fortran subroutines, had a four-slot cons.
"Therefore, ... car ... and its analogs cdr, cpr, and ctr
were defined. At some point a cons(a, d, p, t) was defined,
but it was regarded as a subroutine and not as a function
with a value."
--John McCarthy, "History of Lisp"
in Wexelblat, Richard L. (ed.) History of Programming Languages.
Academic Press, New York (1981), p. 175.
--Guy
∂13-May-88 1503 @MC.LCS.MIT.EDU:edsel!jlm@labrea.stanford.edu Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 15:00:46 PDT
Received: from labrea.stanford.edu (TCP 4402000057) by MC.LCS.MIT.EDU 13 May 88 17:14:09 EDT
Received: by labrea.stanford.edu; Fri, 13 May 88 13:17:00 PDT
Received: from bhopal.lucid.com by edsel id AA12859g; Fri, 13 May 88 12:14:28 PDT
Received: by bhopal id AA28001g; Fri, 13 May 88 12:17:38 PDT
Date: Fri, 13 May 88 12:17:38 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8805131917.AA28001@bhopal.lucid.com>
To: gls@think.com
Cc: NIKHIL@xx.lcs.mit.edu, scheme@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 13 May 88 12:00:40 EDT <8805131600.AA15096@kali.think.com>
Subject: Cells
Guy, is that a trick bet?
The CDC 6500 had a lisp (UTEXAS?) with CAR, CDR, and CZR slots for the
three 18-bit addresses in their 60-bit words. However, if I remember
correctly, you would technically win your bet, since there still
wasn't a three-slot cons. You had to do something like:
(SETQ CELL (CONS A B))
(RPLACZ CELL C)
jlm
∂13-May-88 1617 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Change proposals
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 88 16:17:13 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 May 88 18:58:05 EDT
Date: Fri, 13 May 88 15:25:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Change proposals
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <377357.880513.JAR@AI.AI.MIT.EDU>
Date: 10 May 88 12:06:02 PDT (Tue)
From: willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET
Detailed proposals for changes to the R3RS should be submitted to me
by 15 June. This should allow the agenda committee (Jonathan Rees and
myself?) to collate and edit the proposals in time to distribute them
two weeks before the meeting. Participants should study these proposals
before coming to Snowbird.
Please send your proposals to me, not to Will. Proposals should be
submitted in LaTeX format, if possible, using the macros that are
already used in the report sources. There is no documentation for these
macros, and some are very poorly designed, for which I make no
apologies. (Improved versions are welcome.) I'll mail partial or
complete R↑3.5 Report sources to anyone who wants them (e.g. to learn
how to use the macros or to modify existing text), and I'll also make
them available by FTP shortly.
If you don't have a LaTeX with which to debug your source, then
just do the best you can and I'll cope with it.
∂15-May-88 0019 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MIT Scheme for Unix
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 May 88 00:19:05 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 May 88 02:48:10 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA01829@BLOOM-BEACON.MIT.EDU>; Sun, 15 May 88 02:43:55 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 13 May 88 16:15:06 GMT
From: mnetor!utzoo!utgpu!bnr-vpa!bnr-di!borynec@uunet.uu.net (James Borynec)
Organization: DI, Bell-Northern Research, Ottawa, Ont.
Subject: MIT Scheme for Unix
Message-Id: <128@bnr-di.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Could some kind soul mail me a copy of MIT's scheme that would
run on UNIX SysV (in particular microport's SysV/AT). If you
think that it would be too big to mail but are willing to help
in some other way (establishing direct phone connection or
via floppynet) please contact me.
James Borynec
utzoo!bnr-vpa!bnr-di!borynec
borynec@bnr.bitnet
(613) 765 4856
22 Westcliffe Rd
Nepean, Ontario
K2H 7X4
∂15-May-88 1750 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT Scheme for Unix
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 May 88 17:50:39 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 May 88 20:48:19 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA18763@BLOOM-BEACON.MIT.EDU>; Sun, 15 May 88 20:29:40 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 15 May 88 18:01:05 GMT
From: voder!wlbr!mh@bloom-beacon.MIT.EDU (Mike Hoegeman)
Organization: Eaton IMS, Westlake Village, CA
Subject: Re: MIT Scheme for Unix
Message-Id: <15180@wlbr.EATON.COM>
References: <128@bnr-di.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <128@bnr-di.UUCP> borynec@bnr-di.UUCP (James Borynec) writes:
>
>Could some kind soul mail me a copy of MIT's scheme that would
>run on UNIX SysV (in particular microport's SysV/AT). If you
>think that it would be too big to mail but are willing to help
>in some other way (establishing direct phone connection or
>via floppynet) please contact me.
I think a lot of people (myself included) are interested in how to obtain
scheme. If you know how/where to get it could you please post that information?
Thanks.
-mike
∂16-May-88 1258 @MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU Re: cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 88 12:58:28 PDT
Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 16 May 88 15:51:40 EDT
Date: 16 May 1988 15:20-EDT
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
To: Paul Robertson <probertson@MEAD.SCRC.Symbolics.COM>
Cc: scheme@mc.lcs.mit.edu
Subject: Re: cells
Message-Id: <Mon.May.16.15:20:42.1988/bap@F.GP.CS.CMU.EDU>
From: Barak Pearlmutter
They [locatives] do let vectors and structures
(including environments) get gc'ed when all that's left is a
pointer to something in their innards, which is nice,
From: Paul Robertson
It is?
This issue is like to the question of whether to do "tail recursion
optimization." As in that case, it seems to me that the burden of proof
is on you, since ceteris paribus it is better that garbage be reclaimed.
In response to the "debugging ease" argument which the above analogy
suggests you will use, it is simple enough to arrange things so that one
can get to the object containing the cell a locative points to if the
object has not been deallocated, thus complicating debugging only when
the containing object has actually been freed.
Do you have some coherent argument in mind, or are you just loyal to the
current Symbolics technology?
--Barak.
∂16-May-88 1337 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 88 13:37:46 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 May 88 16:19:13 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7
id <AA09790@BLOOM-BEACON.MIT.EDU>; Mon, 16 May 88 16:09:46 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 10 May 88 15:41:48 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Subject: Re: Re : set in Scheme
Message-Id: <683@thalia.rice.edu>
References: <12073@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Here's my invaluable ;-) comment about _set_ in Scheme. As it is fairly easy
to build up a case for loss of program readability with the addition of _set_
(as opposed to _set!_), we should perhaps be pleased that it is probably
impossible (with macros, extend-syntax, what-not) to define _set_ in Scheme.
The most "correct" version of _set_ in terms of _set!_ given on the net,
(herein transliterated to extend-syntax) is probably
(extend-syntax (set)
[(set x y) (eval (list 'set! x (quote y)))]).
However, Scheme does not offer 'eval' to the user. The most it does is offer
a *global* eval, which ain't the same thing. So,
(define x 0)
==> x
(define y 'x)
==> y
(let ([x 1])
(let ([y 'x])
(set y 2)
x))
==> 1 {instead of 2}
x
==> 2 {instead of 0}
Continuing { with global x = 2, y = x }
(define z 3)
==> z
(let ([z 4])
(set y z)
x)
==> 3 {instead of 4}
The second problem can be appeased by evaluating the settend (to coin a
word) beforehand as in,
(extend-syntax (set)
[(set x y) (begin (set! |weird-identifier| y)
(eval (list 'set! x (quote |weird-identifier|))))])
{|weird-identifier| HAS to be a global variable, because of the globalness
of eval.}
But the first problem remains. A modified version of the second problem can
occur if there are _set_'s inside the settee (to coin a not-so-new word), as
in
(set (set <blah> <foo>) <hukares>)
Any amount of tweaking the extend-syntax for set, seems destined to lead
nowhere. That, as they (and Magnum) say, is "the hell of it".
--dorai
∂16-May-88 1446 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU MIT Scheme for Unix
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 88 14:46:24 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 16 May 88 10:43:28 EDT
Received: by kleph.AI.MIT.EDU; Mon, 16 May 88 10:44:03 edt
Date: Mon, 16 May 88 10:44:03 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8805161444.AA01205@kleph>
To: voder!wlbr!mh@bloom-beacon.MIT.EDU
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Mike Hoegeman's message of 15 May 88 18:01:05 GMT <15180@wlbr.EATON.COM>
Subject: MIT Scheme for Unix
Reply-To: cph@zurich.ai.mit.edu
Date: 15 May 88 18:01:05 GMT
From: voder!wlbr!mh@bloom-beacon.MIT.EDU (Mike Hoegeman)
I think a lot of people (myself included) are interested in how to obtain
scheme. If you know how/where to get it could you please post that information?
MIT CScheme can be obtained in the following ways:
* Internet FTP:
Telnet to "prep.ai.mit.edu" as user "scheme", password "scheme".
Use the `ftp' program to obtain either the file "dist.tar" or
"dist.tar.Z" (a compressed version). The directory "dist.split"
contains the file "dist.tar.Z" split up into 250 kbyte pieces.
Alternatively, use anonymous ftp to "zurich.ai.mit.edu" (user
"anonymous", any password) and read the file "pub/scheme/README"
for more directions.
* Magtape:
The cost of a distribution tape is $200 to cover our copying and
administrative expenses.
Send a check for $200 payable to MIT to:
Scheme Distribution
MIT Artificial Intelligence Laboratory
545 Technology Square
Cambridge, Ma. 02139
Please specify the tape format:
* Unix tar format, 9-track magtape, 1600 bpi
* VMS backup format, 9-track magtape, 1600 bpi
* Unix tar format, HP CS/80 cartridge tape
∂16-May-88 1446 @MC.LCS.MIT.EDU:probertson@MEAD.SCRC.Symbolics.COM Re: cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 88 14:46:42 PDT
Received: from MEAD.SCRC.Symbolics.COM (TCP 20024224752) by MC.LCS.MIT.EDU 16 May 88 13:40:04 EDT
Received: from JAYHAWK.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 158318; Mon 16-May-88 12:21:48 EDT
Date: Mon, 16 May 88 12:21 EDT
From: Paul Robertson <probertson@MEAD.SCRC.Symbolics.COM>
Subject: Re: cells
To: Barak.Pearlmutter@F.GP.CS.CMU.EDU, JAR@AI.AI.MIT.EDU
cc: scheme@mc.lcs.mit.edu
In-Reply-To: <Thu.May.12.02:18:44.1988/bap@F.GP.CS.CMU.EDU>
Message-ID: <880516122117.8.PROBERTSON@JAYHAWK.SCRC.Symbolics.COM>
They do
let vectors and structures (including environments) get gc'ed when all
that's left is a pointer to something in their innards, which is nice,
It is?
∂16-May-88 1645 @MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU Re : set in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 88 16:45:42 PDT
Received: from THEORY.LCS.MIT.EDU (TCP 2206400134) by MC.LCS.MIT.EDU 16 May 88 19:43:37 EDT
Received: from TOUCAN.LCS.MIT.EDU by THEORY.LCS.MIT.EDU (4.12/4.7); Mon, 16 May 88 19:39:53 ast
Received: by TOUCAN.LCS.MIT.EDU (4.12/4.7); Mon, 16 May 88 19:39:50 ast
Date: Mon, 16 May 88 19:39:50 ast
From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>
Message-Id: <8805162339.AA03068@TOUCAN.LCS.MIT.EDU>
To: titan!dorai@rice.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Dorai Sitaram's message of 10 May 88 15:41:48 GMT <683@thalia.rice.edu>
Subject: Re : set in Scheme
> Here's my invaluable ;-) comment about _set_ in Scheme. As it is fairly easy
> to build up a case for loss of program readability with the addition of _set_
> (as opposed to _set!_), we should perhaps be pleased that it is probably
> impossible (with macros, extend-syntax, what-not) to define _set_ in Scheme.
T has something more or less like the LISP SET, but it requires you to
specify the environment you're modifying:
(*VALUE LOCALE IDENTIFIER) gives the value of IDENTIFIER in LOCALE
(locales seem to be more or less synonymous with environments)
(SET (*VALUE LOCALE IDENTIFIER) NEW-VALUE)
sets that value.
To avoid and engender confusion, I remark that T's SET is roughly Common
Lisp's SETF.
How do people feel about this? It still allows some extremely confusing
things. Who has used Lisp's SET, and what has it been good for?
-- Bard the (LAMBDA (X) GARGOYLE)
∂17-May-88 1336 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Uses of SET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 May 88 13:36:07 PDT
Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 17 May 88 09:09:12 EDT
Date: 17 May 88 08:39:55 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: scheme@mc.lcs.mit.edu
Message-Id: <051788.083956.alberga@ibm.com>
Subject: Uses of SET
I am a unashamed (albeit sparing) user of SET in Lisp. The majority of
uses are in functions which define, redefine or embed (? our local term
for redefining a function in terms of it's previous definition) functions.
(Note that our dialect of Lisp does NOT have function-value cells and
assignment is used for function definition.) These function (NOT macros)
accept lists of names (identifiers) and definitions, process the definitions
in various ways, then use SET to install the result. This assignment
is expected to modify the dynamic environment, not the global environment(s)
exclusively.
A second use of set is possibly more interesting. I have a function which
accepts an a-list of properties and uses it to initialize a collection
of dynamic variables. The a-list contains only those name/value pairs
which are to differ from various defaults. The code used is:
(Note that we use a-list format for property lists, not flat lists, hence
GET works on a-lists.)
(MAPC
(LAMBDA (PROP VAR DEFLT)
(SET VAR
(COND
( (GET OPTIONLIST PROP) )
( 'T
DEFLT ) )) )
'(:MACRO-APP-SD :OP-RECOGNITION-SD :MESSAGE :LISTING :FILE :NOLINK
:SOURCELIST :TRANSLIST :LAPLIST :BPILIST :NOMERGE :OPTIMIZE
:LISPLIB-ACTION-CLASS :NOSTOP :QUIET :SILENT :DELAY-COMPILATION)
'(MACRO-APP-SD OP-RECOGNITION-SD MESSAGESTREAM LISTSTREAM FILESTREAM NOLINK
SOURCELIST TRANSLIST LAPLIST BPILIST NOMERGE OPTIMIZE MEMBERCLASS NOSTOP
QUIET SILENT DELAY-COMPILATION)
(LIST S,MACRO-APP-SD S,OP-RECOGNITION-SD CUROUTSTREAM CUROUTSTREAM
() () () () () () () 4 0 () () () ()))
Since this is not a common operation it was felt that the simplicity of
maintaining parallel lists of property-names/variables/default values
was better than writing out seventeen (currently) SETQs with conditional
arguments and calls to GET.
Subject: new question; macro definitions
I am a new user of PCScheme (sp?), and have just ciphered out the way
macros are hidden. I find it odd that macros have only global definitions,
i.e. on property lists. This seems most un-Scheme-like. In our Lisp we
use a distinguished form (MLAMBDA ...) for macro definitions, and use the
same definition methods as we use for functions. Of course this leads to
other complexities and confusions. Could anyone direct me to commentary
on the relative merits of various macro definition schemes (pun intended)?
Thank you,
Cyril N. Alberga
∂17-May-88 1336 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MIT Scheme for Unix
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 May 88 13:36:28 PDT
Received: from BLOOM-BEACON.MIT.EDU.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 17 May 88 14:07:12 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA10221@BLOOM-BEACON.MIT.EDU>; Tue, 17 May 88 13:57:59 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 17 May 88 13:54:47 GMT
From: ubvax!smegma!mdg@ames.arpa (Marc de Groot)
Organization: A moving point in 4-space
Subject: Re: MIT Scheme for Unix
Message-Id: <398@smegma.UUCP>
References: <128@bnr-di.UUCP>, <15180@wlbr.EATON.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <15180@wlbr.EATON.COM> mh@wlbr.UUCP (0000-Mike Hoegeman) writes:
>In article <128@bnr-di.UUCP> borynec@bnr-di.UUCP (James Borynec) writes:
>>
>>Could some kind soul mail me a copy of MIT's scheme that would
>>run on UNIX SysV (in particular microport's SysV/AT). If you
>>think that it would be too big to mail but are willing to help
>>in some other way (establishing direct phone connection or
>>via floppynet) please contact me.
>I think a lot of people (myself included) are interested in how to obtain
>scheme. If you know how/where to get it could you please post that information?
>Thanks.
Ditto. Please post to the net when you get a copy.
Thanks.
-Marc
--
Marc de Groot (KG6KF)
UUCP: {hplabs, sun, ucbvax}!amdcad!uport!smegma!mdg
AMATEUR PACKET RADIO: KG6KF @ KB6IRS
"Look, he's mounting a tape!" "Quick, throw cold water on him!"
∂17-May-88 1542 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Scheme standardization meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 May 88 15:42:17 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 May 88 18:06:51 EDT
Received: by iuvax.cs.indiana.edu; id AA00423; Tue, 17 May 88 17:04:27 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Tue, 17 May 88 17:04:27 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: Scheme standardization meeting
The proposal to form an IEEE Working Group on Scheme (let's call it
the "working group" from now on) mentioned in my last note has been
approved by the Microprocessor Standards Committee (MSC). There are a
few more administrative steps before it is completely official, but no
difficulty is expected. The standardization process has begun; wish
us luck!
The first meeting of the working group will be on Wednesday, July
27th, 1988, from 1:00 pm to 5:00 pm (or later if really necessary)
following the Lisp and Functional Programming Conference at Snowbird,
Utah. The meeting room will be posted at the conference facility.
The agenda for the first working group meeting should at least include
discussion of the following items:
- introductions and brief remarks about the standards process
- scope and purpose of standardization effort
- expected time schedule for standard development
- time and place of next meeting
- netmail and other means of communicating between meetings
- proposed ways for the standard to differ from the Revised↑3 Report.
The last point is clearly the most important and should take most of
the time. Specific proposals should be stated in advance and included
in the agenda if possible.
Very briefly, my current expectation (reflecting the wishes of the
study group mentioned in my last note) is that the working group will
serve to "filter" the work of the Revised↑n Report authors, removing
features deemed too experimental for standardization and adding nothing
of substance to the language. The following meeting will be in about
six months, at a place as yet unknown. A "trial standard" should be
completed in about two years, with a full standard perhaps two years
after that.
Let's use the general Scheme news group (now comp.lang.scheme) for
discussion of the agenda and related matters prior to the meeting.
At the meeting we may agree to form another news group for subsequent
communication.
Your suggestions on agenda items and candidates for filtering are
welcome.
-- Chris Haynes
∂17-May-88 2034 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu scheme on AIX
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 May 88 20:34:15 PDT
Received: from clover.ucdavis.edu (TCP 20036034401) by MC.LCS.MIT.EDU 17 May 88 23:24:24 EDT
Received: by clover.ucdavis.edu (5.51/4.7)
id AA03350; Tue, 17 May 88 19:24:23 PDT
Received: by iris.ucdavis.edu (5.51/3.14)
id AA24354; Tue, 17 May 88 19:25:15 PDT
Message-Id: <8805180225.AA24354@iris.ucdavis.edu>
Qotw: If you can't do it with an editor,
I don't want to do it.
Pointers: (916) 752-7324/3168
To: scheme@mc.lcs.mit.edu
Subject: scheme on AIX
Date: Tue, 17 May 88 19:25:13 PDT
From: Phil Windley <windley@iris.ucdavis.edu>
Does anyone have any version of Scheme that runs on an IBM RT under AIX
(IBM's SysV derivative)?
Phil Windley | windley@iris.ucdavis.edu
Robotics Research Lab | ucbvax!ucdavis!iris!windley
University of California, Davis |
∂18-May-88 1932 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@bostonu.BITNET Boston Sigplan Seminar on Continuation Semantics
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 19:32:11 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 18 May 88 22:29:20 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5751; Wed, 18 May 88 22:25:35 EDT
Received: from BOSTONU.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
5750; Wed, 18 May 88 22:25:31 EDT
Received: by BOSTONU (Mailer X1.25) id 9113; Wed, 18 May 88 22:26:55 EDT
Date: Wed, 18 May 88 22:24:08 EDT
From: "Peter Mager" <met9i7n%BOSTONU.BITNET@MITVMA.MIT.EDU>
Subject: Boston Sigplan Seminar on Continuation Semantics
To: scheme@mc.lcs.mit.edu
The following seminar may be of interest to members of the Scheme
community in the Boston area:
Received: from CUNYVM.BITNET by BOSTONU.BITNET (Mailer X1.25) with BSMTP id
6547; Fri, 06 May 88 16:14:19 EDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer X1.25) with BSMTP id 2999; Fri,
06 May 88 16:11:25 EDT
Received: from SH.CS.NET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Fri, 06
May 88 16:11:17 EDT
Subject: SICPLAN Mtg, 19 May 88. G F Johnson: Partial Continuations and Stores
in a Programming Environment
From: SICPLAN <Mooers@SH.CS.NET>
To: Sicplan-list@SH.CS.NET
Cc: mooers@SH.CS.NET, met9i7n%BOSTONU.BITNET@SH.CS.NET
Date: Fri, 06 May 88 15:58:18 -0400
Sender: mooers@SH.CS.NET
ACM GREATER BOSTON CHAPTER SICPLAN
Thursday, May 19, 1988
8 P.M.
Intermetrics Atrium
725 Concord Ave., Cambridge
Partial Continuations and Stores in a Programming Environment
Gregory F. Johnson
Computer Science Department
University of Maryland
ACM GREATER BOSTON CHAPTER SICPLAN
It is becoming widely recognized that the quality of a programming
environment has a significant impact on the productivity of
programmers. The discipline of creating a formal language semantics
has had a major positive influence on the design of programming
languages, and we hypothesize that a similar formal approach will
result in better programming environments. To test this hypothesis,
we have initiated the GL research project, in which a new (small)
programming language, an environment, and a denotational semantics
are being designed together. In particular, both partial
continuations (functions representing part of the future execution of
a partially completed program execution) and stores (finite functions
representing the content of a computer's memory) can be obtained from
the programming environment during execution of a program. These
objects can then be invoked and manipulated in a variety of ways,
allowing the user a great deal of flexibility and room for
interactive experimentation in arriving at understanding of the
behavior of programs. These facilities give rise to a new style of
interaction with a programming environment that appears to be
promising.
ACM GREATER BOSTON CHAPTER SICPLAN
Dear Colleague,
Our speaker for May has been actively investigating continuation
passing semantics and the use of continuations in programming
environments for a number of years. He is currently on the faculty
of the University of Maryland. Some of the material in this talk was
presented in papers at the Sigplan'87 Interpreters Conference and at
POPL'88.
Our February talk by Robert Schwartz and John Yates showed us a new
and promising approach to compiler code generation based on extending
table driven pattern selection through the use of vector-valued
predicates and dynamic programming techniques. The resulting partial
ordering of possible instruction sequences allows the code generation
algorithm to achieve quasi-optimal (i.e. optimal with respect to the
defined patterns and evaluation criteria) code sequences in linear
time. The presentation led to some interesting discusions among the
100 or so people who attended.
We will be meeting for dinner as usual at Joyce Chen's restaurant,
390 Rindge Ave., Cambridge at 6:00 p.m. before the meeting. If you
wish to come, please call Karen Kelly or "Sigplan dinner" at
Intermetrics (661-1840) as early as possible so we can make the
appropriate dinner reservation.
Peter Mager
chairperson, Boston SICPLAN
∂19-May-88 0832 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: Cells
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 May 88 08:32:02 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 88 11:29:05 EDT
Received: from [129.10.1.2] by RELAY.CS.NET id ac10314; 19 May 88 10:49 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa19437; 19 May 88 10:33 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4)
id AA16884; Thu, 19 May 88 10:33:31 EDT
Date: Thu, 19 May 88 10:33:31 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Message-Id: <8805191433.AA16884@corwin.CCS.Northeastern.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Re: Cells
Scheme 84 at Indiana had a notion of cells essentially identical to that
proposed by Ostheimer & Nikhil. We had objects called "refs".
(REF val) created a ref initially containing val
(DEREF ref) got the contents
(SET-REF! ref val) changed the contents.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂19-May-88 0908 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Re: ''Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 May 88 09:08:34 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 May 88 11:29:50 EDT
Received: from [129.10.1.2] by RELAY.CS.NET id ad10314; 19 May 88 10:49 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa19534; 19 May 88 10:35 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4)
id AA16901; Thu, 19 May 88 10:35:23 EDT
Date: Thu, 19 May 88 10:35:23 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Message-Id: <8805191435.AA16901@corwin.CCS.Northeastern.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Re: ''Update functions'' in Scheme.
One ought not to say things like:
"F(G(C)) := D ought to ensure that F(G(C)) = D afterwards."
too blithely. Consider the array assignment:
A[A[1]] := 2
in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had
program verifiers confused for a good while in the early 70's.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂20-May-88 0959 @MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM Re: ''Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 09:59:12 PDT
Received: from VALLECITO.SCRC.Symbolics.COM (TCP 20024224534) by MC.LCS.MIT.EDU 20 May 88 12:57:31 EDT
Received: from MERLIN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 233375; Fri 20-May-88 12:55:25 EDT
Date: Fri, 20 May 88 12:54 EDT
From: Howard Shrobe <hes@VALLECITO.SCRC.Symbolics.COM>
Subject: Re: ''Update functions'' in Scheme.
To: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, scheme@mc.lcs.mit.edu
In-Reply-To: <8805191435.AA16901@corwin.CCS.Northeastern.EDU>
Message-ID: <19880520165408.4.HES@MERLIN.SCRC.Symbolics.COM>
Date: Thu, 19 May 88 10:35:23 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
One ought not to say things like:
"F(G(C)) := D ought to ensure that F(G(C)) = D afterwards."
too blithely. Consider the array assignment:
A[A[1]] := 2
in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had
program verifiers confused for a good while in the early 70's.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
I wrote a paper that was distributed by hand to friends in the late '70s
called "Floyd-Hoare Verifiers Considered Harmful" that pointed this
ought. It was somewhat tongue in cheek but was based on catching Vaughn
Pratt making exactly this kind of mistake. I just moved my office and
found copies of the paper. Sussman would remember it well.
∂20-May-88 1146 @MC.LCS.MIT.EDU:gls@Think.COM ''Update functions'' in Scheme.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 11:45:56 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 20 May 88 14:43:02 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 20 May 88 14:38:44 EDT
Received: by kali.think.com; Fri, 20 May 88 14:38:40 EDT
Date: Fri, 20 May 88 14:38:40 EDT
From: gls@Think.COM
Message-Id: <8805201838.AA04646@kali.think.com>
To: wand%corwin.ccs.northeastern.edu@relay.cs.net
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 19 May 88 10:35:23 EDT <8805191435.AA16901@corwin.CCS.Northeastern.EDU>
Subject: ''Update functions'' in Scheme.
Date: Thu, 19 May 88 10:35:23 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@relay.cs.net>
One ought not to say things like:
"F(G(C)) := D ought to ensure that F(G(C)) = D afterwards."
too blithely. Consider the array assignment:
A[A[1]] := 2
in a two element array A, where initially A[1]=A[2]=1 . This sort of thing had
program verifiers confused for a good while in the early 70's.
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
Now consider the array assignment Y(A[.]) := 2 . :-)
--Quux
∂20-May-88 1224 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 12:23:54 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 20 May 88 15:02:45 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 88 11:50:00 PDT
Date: Fri, 20 May 88 11:49:26 PDT
From: Pavel.pa@Xerox.COM
Subject: A Proposal for Environments in Scheme
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880520-115000-2371@Xerox>
I'd like to offer the following proposal for a facility for first-class
environments in Scheme. We have found it to work quite cleanly and powerfully
in Cedar Scheme and thus believe that it is worthy of consideration for
inclusion in the standard language.
Pavel Curtis
Xerox PARC/CSL
INTRODUCTION
If Scheme is to grow and be used by more people, one of the problems it must
solve is the robust isolation of different pieces of the system and user code
from each other. The system described in this section is an attempt to cleanly
and simply solve this problem, with an eye toward making the addition of a true
file-compiler a simple extension with clean semantics. It is fully implemented
in Cedar Scheme.
Note that this system does not attempt to address the questions of interfaces
vs. implementations, interface-version compatibility checking, etc. We simply
want it to be possible for normal users to write code that is insulated
reasonably well from the system and from other users.
The presented solution owes a debt to the designers of T (in many obvious ways)
and probably those of other Scheme dialects. As well, it is influenced by our
extensive experience programming in the Cedar language and environment, with its
heavy emphasis on well-defined interfaces. The proposal given here is not,
however, truly the same as any other system of which we're aware; in particular,
it departs strongly from T in some fundamental ways, so draw no premature
conclusions.
The proposal begins by specifying a Scheme interface to first-class
environments, a cornerstone of the new facility. It then describes the initial
set of environments in the system; this arrangement is in place >before< the
first file of code is LOADed. Next, it suggests a syntax and semantics for
files of Scheme code that allows fine-grained but convenient control over the
environment structure. Finally, it presents an example of a file using the new
facility.
The proposal proper is followed by some answers to questions that we anticipate
conerning the proposal.
FIRST-CLASS ENVIRONMENTS
We propose the addition to Scheme of first-class environment values. These are
precisely the environments currently used by the Scheme interpreter with one
cosmetic addition, a human-readable >identifier< for the environment. The
procedures defined on environments are as follows:
MAKE-ENVIRONMENT <id> <parent> ... [Procedure]
Creates and returns a new environment with the given <parents> (if any) and
the given identifying value, <id>, usually a string. <Id> is strictly for
debugging purposes; it is output as a part of the printed representation of
the new environment. The <parents>, on the other hand, are of semantic
interest, since variable-lookup in the resulting environment will continue
into the parents if the requested symbol has no binding in the child
environment. Variable lookup is depth-first and left-to-right among
multiple parents.
ENVIRONMENT? <object> [Procedure]
Returns true if and only if <object> is an environment.
ENVIRONMENT-ID <env> [Procedure]
Return the value specified for the <id> parameter to the call to
MAKE-ENVIRONMENT that created <env>, or #F if none was specified.
ENVIRONMENT-PARENTS <env> [Procedure]
Return a list of the values specified for the <parent> parameters to the
call to MAKE-ENVIRONMENT that created <env>. It is an error to perform
destructive operations on this list.
ENVIRONMENT-REF <env> <symbol> [Procedure]
Return the value bound to <symbol> in <env> (or its ancestors), signalling
an error if no such binding exists.
ENVIRONMENT-SET! <env> <symbol> <value> [Procedure]
Change the value bound to <symbol> in <env> (or its ancestors) to <value>,
signalling an error if no such binding exists.
ENVIRONMENT-DEFINE! <env> <symbol> <value> [Procedure]
Change the value bound to <symbol> in <env> (NOT its ancestors) to <value>,
adding such a binding to <env> if none exists. Note that
ENVIRONMENT-DEFINE! never affects any ancestor of <env>, only <env> itself.
ENVIRONMENT-BOUND? <env> <symbol> [Procedure]
Return true if and only if there exists a binding for <symbol> in <env>
(or its ancestors).
WALK-ENVIRONMENT <fn> <env> [Procedure]
<Fn> should be a procedure of two arguments, a symbol and a value. It is
applied to every binding in <env> itself, NOT including bindings in its
ancestors.
In addition to these procedures, We propose a change to the meanings of
identifiers whose names include colons:
-- No identifier may begin or end with a colon.
(Alternatively, such identifiers behave as they do now.)
-- An identifier of the form a:b1:...:bk (k >= 1) is entirely equivalent to
the expression
(ENVIRONMENT-REF a:b1:...:bk-1 'bk)
This change allows convenient reference to the values of bindings in an
environment that is bound to some variable in the current environment. For
example, the identifier STRINGS:COPY is equivalent to the expression
(ENVIRONMENT-REF STRINGS 'COPY)
and the identifier CEDAR:IO:RESET is equivalent to the expression
(ENVIRONMENT-REF (ENVIRONMENT-REF CEDAR 'IO) 'RESET)
THE INITIAL ENVIRONMENT STRUCTURE
The initial structure of environments, as seen by the first file LOADed into the
system, consists of at least the following four environments:
"SCHEME-ESSENTIALS"
Contains exactly those bindings described as "essential" in the Scheme
specification, with the semantics given there. Thus, in this environment,
APPEND takes exactly two arguments, LET does not allow the "named-LET"
variant, internal DEFINEs are not allowed, etc.
In addition, the name SCHEME-ESSENTIALS is bound to the environment
itself.
This environment is intended for use by those laboring under severe
portability constraints.
"SCHEME"
Contains exactly those bindings described in the Scheme specification,
except that a given implementation may not provide all of the optional
features. Thus, in this environment, APPEND may or may not accept an
arbitrary number of arguments, LET may or may not allow the named variant,
etc. The strongest statement that can be made about this environment is
that it certainly contains no more than what is described in R3RS and no
less than the "SCHEME-ESSENTIALS" environment.
In addition, the names SCHEME-ESSENTIALS and SCHEME are bound to the
"SCHEME-ESSENTIALS" environment and this environment itself, respectively.
This environment is intended for those who want to work in a reasonably
portable setting with no extras.
Some implementation-dependent name
Contains whatever the implementation considers the bindings of the
language it implements. It should contain everything found in the
"SCHEME" environment, though some may have been extended upward-
compatibly. In addition, other facilities, not described in R3RS,
may be visible here.
Some name should be bound to the environment itself. In addition, the names
SCHEME-ESSENTIALS and SCHEME are bound to the "SCHEME-ESSENTIALS" and
"SCHEME" environments, respectively.
It is assumed that most code written in the implementation will be
evaluated in an environment descended from this one.
In the rest of this proposal, this environment will be called the "full-
language" environment.
"GLOBAL"
Has as its only parent the full-language environment. In addition, the name
GLOBAL is bound to this environment itself.
The GLOBAL environment is distinguished in the definition of the semantics
of code files, below.
By convention, most files of code are evaluated in environments descended
from this one and most other "public" environments will be accessible
through names in the GLOBAL environment.
Implementation Note: In Cedar Scheme, for example, the initial environment
structure is created by code like the following:
(let* ((scheme-essentials (make-environment "SCHEME-ESSENTIALS"))
(scheme (make-environment "SCHEME" scheme-essentials))
(cedar-scheme (make-environment "CEDAR-SCHEME" scheme))
(global (make-environment "GLOBAL" cedar-scheme)))
(environment-define! scheme-essentials
'scheme-essentials
scheme-essentials)
(environment-define! scheme 'scheme scheme)
(environment-define! cedar-scheme 'cedar-scheme cedar-scheme)
(environment-define! global 'global global)
...)
Though it is not required by this proposal, all four environments in the initial
structure in Cedar Scheme form a chain through the parent relation. Only the
GLOBAL and full-language environments are required to be so linked.
[End note]
THE SYNTAX AND SEMANTICS OF FILES
In the usual case, a file of Scheme code contains the definitions of a few
variables (most frequently bound to procedures) intended for use by clients of
the software and several more ``helper'' variables intended only for use by the
package itself. The variables to be externally available usually belong in a
separate space of names from those in any other package. The following syntax
and semantics of files, which is upwardly-compatible with what is currently in
use in most dialects of Scheme, is intended to make the usual case easy while
allowing more complex cases to be handled smoothly as well.
A file of Scheme code, under this proposal, may optionally begin with a piece of
syntax, called a >herald<, that arranges for special treatment of the
environmental context of the code in the file. Heralds obey the following
syntax:
(HERALD <option>+)
where each <option> is one of the following:
(ENV <expression>)
The given <expression> is evaluated in the GLOBAL environment described
above before loading the rest of the file. <Expression> should yield an
environment in which the rest of the file will be evaluated. This option
may only appear once, if at all. It it does not appear, LOAD behaves as if
the option
(ENV (MAKE-ENVIRONMENT <file-name> GLOBAL))
had been given, where <file-name> is a string naming the file from which the
code is being loaded. This default is proper for most single-file packages.
Larger applications might have an initial file that creates a new
environment and binds it to some name in the GLOBAL environment; later files
would specify an ENV option naming that environment. In this way, a multi-
file application can share a single environment among many files.
(EXPORT <expression> <export-spec>+)
An <export-spec> is either a simple identifier (one without colons) or a
list of two simple identifiers; an <export-spec> that is a simple identifier
<id> is exactly equivalent to the <export-spec> (<id> <id>). The given
<expression> is evaluated in the same environment as the rest of the file
(see the description of the ENV herald option, above) after the rest of the
file has been loaded. It should yield an environment, say <env>. For each
<export-spec> (<id>1 <id>2), the environment <env> is side-effected such
that the binding for <id>1 in <env> is identical to that for <id>2 in the
environment for this file. Two bindings are ``identical'' if a change to
the value of one produces the same change to the value of the other. In
denotational terms, the two environments map the corresponding identifiers
to the very same location.
This option may appear as many times as desired. The intent is that during
the course of loading a file, it will define a variable, local to the file,
bound to a fresh environment. An EXPORT option will be used to bind this
environment to some name, either in the USER environment or in some other
environment accessible from the GLOBAL environment. Further EXPORT options
will be used to share certain of the bindings in the file with that
now-public environment. Naturally, those bindings that are not mentioned in
EXPORT options will remain entirely local to the environment of the file.
Further herald options might be added in the future, in particular to aid in the
specification of a compiler's early-evaluation environment.
If no herald appears at the beginning of a file of code, the LOAD procedure will
behave as if this herald had be given:
(HERALD
(ENV GLOBAL))
That is, such files are evaluated in the normal global environment, as all files
are now.
AN EXAMPLE FILE UNDER THE PROPOSAL
Here is an skeletal example of a file that might be part of a Scheme
implementation of the standard string-handling functions. In this ficticious
Scheme implementation, the full-language environment is named "FOO-SCHEME" and
is bound to that name as well.
Since it implements a low-level structure like strings, the code in the file
uses certain "sub-primitives" from an environment bound to the name PRIVATE in
the FOO-SCHEME environment.
After the file is loaded, the various procedures defined in the Revised↑3 Report
will be bound both to their normal names in the SCHEME-ESSENTIALS and SCHEME
environments and also to more concise names in a new STRINGS environment, itself
bound to the name STRINGS in the GLOBAL environment.
Thus, a client of the string-handling procedures can either use the names
described in the Revised↑3 Report (e.g., STRING-REF, STRING-SET!, STRING-COPY)
or the more ``generic'' names from the STRINGS environment (e.g., STRINGS:REF,
STRINGS:SET!, STRINGS:COPY). The latter might fit in well with analogous
procedures from environments named LISTS, VECTORS, TABLES, ENVIRONMENTS, etc.
(herald
(env (make-environment "StringsImpl" global foo-scheme:private))
(export scheme-essentials
(string-ref ref) (string-set! set) ...)
(export scheme
(string-copy copy) ...)
(export strings
ref copy (set! set) ...)
(export global
strings))
(define strings (make-environment "STRINGS"))
(define (ref string index)
...)
(define (copy string)
...)
(define (set string index value)
...)
...
Q&A ON THE PROPOSAL
Q: Why is the GLOBAL environment separate from the full-language environment?
Why not just load files into the full-language environment?
A: There are two answers to this, one based upon modularity and aesthetic
considerations and the other on future plans for the facility.
The modularity argument is that the full-language environment, like the
SCHEME or SCHEME-ESSENTIALS environments, should present an unchanging
interface. Applications should be able to count on the documented behavior
of the variables in these environments and should not be affected by the
presence or absence of other applications except where explicitly arranged
for.
The future plans argument relates to an idea for eliminating the dependence,
found in many Lisp implementations, of the semantics of code being compiled
on the presence or absence of other applications in the system running the
compiler. For example, it is frequently the case that macros defined
globally in the running system are available to code files compiled in that
system. This can (and does) lead to confusing, hidden dependencies. Within
this proposal, a compiler could create a new GLOBAL environment (again with
the full-language environment as its sole parent) and use some new herald
option as a description of what files to load into that environment to
establish the proper "early-evaluation" environment for the compilation of
the file. When the compilation is done, the ersatz GLOBAL environment can be
discarded, taking with it any side-effects that might have occurred in the
process of compilation. Under such a scheme, we would expect that the
various language environments would be "locked" against redefinition of any
of their bindings before the time that any user code is loaded, thus ensuring
that these environments do, indeed, present an unchanging interface.
Q: In what environment should an implementation's read-eval-print loop evaluate
the forms typed to it?
A: Certainly any such facility should provide a mechanism whereby any
environment can be used, but our advice for the choice of an initial or
default environment would be a "scratch" environment (as it is called in T)
whose sole parent is the GLOBAL environment. The use of a separate
environment here is intended to make it easier for a user to avoid
accidentally redefining names in the GLOBAL environment, thus possibly
breaking running applications. Of course, the Scheme report (properly)
avoids mention of read-eval-print loops, so no implementation is required to
have one at all.
Q: Why does the EXPORT herald option share actual bindings, rather than simply
sharing values?
A: This enables the use of shared, set!-able variables. Code wishing to take
advantage of this would simply specify an environment containing the binding
as an ancestor of the file environment.
Q: Why isn't there an IMPORT herald option that shares bindings in the other
direction? It would make the use of such shared variables more controllable
since one would not have to share all of the variables in the given
environment.
A: Such an option would not be antithetical to this proposal.
∂20-May-88 1305 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:WROGERS@UDCVAX.BITNET Sources to C-Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 13:05:35 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 May 88 16:03:33 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8720; Fri, 20 May 88 15:59:38 EDT
Received: from UDCVAX.BITNET (WROGERS) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 8717; Fri, 20 May 88 15:59:34 EDT
Date: Fri, 20 May 88 15:55 EST
From: <WROGERS%UDCVAX.BITNET@MITVMA.MIT.EDU>
Subject: Sources to C-Scheme
To: scheme@mc.lcs.mit.edu
X-Original-To: scheme@mc.lcs.mit.edu, WROGERS
How do I get sources to C-Scheme? I'm currently on BITNET
so I don't have access to files on USENET or ARPANET. Is
there a server on BITNET that has the sources or perhaps an
mailing address I can send a 9 track tape?
Thanks
Will Rogers, WROGERS@UDCVAX.BITNET
University of DC
∂23-May-88 0824 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 08:24:34 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 23 May 88 11:18:06 EDT
Received: by ti.com id AA27140; Mon, 23 May 88 10:14:39 CDT
Received: from mips by tilde id AA00645; Mon, 23 May 88 10:13:49 CDT
Received: by mips id AA27855; Mon, 23 May 88 10:13:45 CDT
Date: Mon, 23 May 88 10:13:45 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8805231513.AA27855@mips>
To: Pavel.pa@XEROX.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@XEROX.COM's message of Fri, 20 May 88 11:49:26 PDT <880520-115000-2371@Xerox>
Subject: A Proposal for Environments in Scheme
Thanks for your proposal; I imagine it will stimulate some discussion
on the topic. Could you please clarify the following?
-- Suppose we had (HERALD (EXPORT ENV (FOO BAR))). What is the effect
if FOO already has a binding in ENV? What is the effect if BAR is
bound in an ancestor of the current (file's) environment but not
directly in the current environment?
-- What is the effect of (HERALD (EXPORT ENV (A B) (C B)))? Is this
an error or are all three identifiers bound to the same location?
-- In your Q&A section, you mention "locking" of environments to
protect them against change. This is an intriguing idea. Would this
be done at the environment level or a binding at a time? Can one
export a binding from an unlocked environment into a locked
environment? If so, does the binding become locked? If so, are uses
of both identifiers having that binding locked? Likewise, what
happens if you export a binding from a locked environment into an
unlocked one?
-- The EXPORT mechanism doesn't require any hierarchical or other
structural relationship between the specified environment and the
current environment, so it is possible to inject a shared binding into
any environment you can get your hands on. Such a binding could be a
trojan horse. Perhaps it should be possible to "lock" an environment
against being exported into (?!) as well?
-- Have you found it to be important to have the `:' notation as a
short-hand for ENVIRONMENT-REF ? My previous proposals to reserve the
`:' character for CL-style package notation have been soundly drubbed.
Just for grins, how would you react to a notation using curly braces, so
your A:B1:B2 becomes {{A}B1}B2, and STRINGS:SET! becomes {STRINGS}SET!.
Regards,
David Bartley
∂23-May-88 1101 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu first class variables.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 11:00:54 PDT
Received: from BLOOM-BEACON.MIT.EDU.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 May 88 13:09:20 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA23503@BLOOM-BEACON.MIT.EDU>; Mon, 23 May 88 12:58:29 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 17 May 88 02:13:45 GMT
From: pitt!darth!tl-vaxa!grover@cadre.dsl.pittsburgh.edu (Vinod Grover)
Organization: Tartan Laboratories, Pittsburgh, Pa.
Subject: first class variables.
Message-Id: <478@tl-vaxa.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
>*** Why didn't the designers of Scheme include locations (~anonymous variables)
>as first-class values in the language? ***
>
>Wouldn't that fit the Scheme philosophy of orthogonality and 'first-class
>everything'? After all, locations are part of the denotational semantics of
>Scheme, so this wouldn't be much of an extension to Scheme from an abstract
>point of view.
Such an idea was explored by J.C. Reynolds in a language called GEDANKEN.
GEDANKEN had functions, labels (continuations), and references (locations)
as first class values. Furthermore, this domain of values is also storable
in locations. A formal denotational semantics of GEDANKEN was given by
R.D. Tennent.
For anyone interested in following up this stuff the references are given
below.
1. Reynolds, J.C., [1970], GEDANKEN - a simple typless language based on
the principle of completeness and reference concept., Communications
of the ACM (13, 5) May 1970.
2. Tennent, R.D., [1976], The Denotational semantics of Programming Languages,
Communications of the ACM, (19,8), August 1976.
disclaimer: of course, my opinions belong to me.
--
Vinod
∂23-May-88 1147 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 11:47:42 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 May 88 13:47:44 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 10:38:45 PDT
Date: Mon, 23 May 88 10:38:32 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880523-103845-4763@Xerox>
Forwarded by request.
Morris Katz 23 May 88 Re: A Proposal for Environments i ...
Return-Path: <MKATZ@A.ISI.EDU>
Received: from A.ISI.EDU by Xerox.COM ; 23 MAY 88 10:18:55 PDT
Date: Mon, 23 May 88 13:15:01 EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: A Proposal for Environments in Scheme
To: Pavel.pa
In-Reply-To: <880520-115000-2371@Xerox>
Message-ID: <12400648194.42.MKATZ@A.ISI.EDU>
I have a number of concerns about the environment proposal which I will
try to express as suscinctly as possible. I will begin with the simple,
syntactic ones and progress from there.
1) I believe it is a big mistake to require that all environments have a name.
There was a good reason(s) for deciding that not all procedures in Lisp should
have to be named, and I believe that those arguments apply equally well to this
case. Either there should be two forms (make-environment <parents>) and
(make-named-environment <id> <parents>) or the order of the arguments should be
reversed and <id> should be made optional in dialects that support optional
arguemnts. In the latter case, <parents> would either be an environment or a
list of environments.
2) I have been interested in the semantics and use of multiple environment
inheritance for some time; but, I am not sure that it is well enough understood
to become part of R3RS. (Maybe someone else understands it better than I do
and can convince me otherwise.) In particular, I am concerned about efficient
implementations for interpreted code, difficulty in understanding code which
utilizes this feature, and the development of suitable browser technology to
make debugging of programs using it tractable.
3) It is my belief that the loader should load the contents of files into the
environment of the REP LOOP from which the load was initiated, unless
specified otherwise in the load command. (e.g., (load "foo" bar) would load
the file "foo" into the environment bar.) Making all files load into the
global environment unless specified otherwise in a herald seems artificial and
constraining. What if one wants to load two slightly different copies of a
system into two sets of environments and compare their execution? Using the
herald approach I believe this would require copying all of the files and
changing the heralds. The logical extension of thiproach would be that
<expression> in (env <expresssion>) in a herald be evaluated in the load
environment, rather than the global environment.
4) I can't quite explain why, but the entire export section makes me feel a
little uneasy. While there are some things that can be done convieniently
through the unification of two symbols in different environments, I get the
feeling that this feature can very quckly get one into trouble. How do we
build debuggers to help support its use? What are the costs added to normal
lexical lookup due to this feature? Does it interact pathologically with
incremental definition, or is this just an erroneous gut level feeling? Maybe
those who are more familiar witsimilar features in CommonLisp can answer some
of these questions.
Morry Katz
-------
∂23-May-88 1210 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 12:09:52 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 May 88 14:48:44 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 11:40:10 PDT
Date: Mon, 23 May 88 11:39:41 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
In-reply-to: <8805231513.AA27855@mips>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880523-114010-4967@Xerox>
I've received four responses to the environments proposal. Let me try to answer
the questions posed in those responses.
From: David Bartley <bartley@mips.csc.ti.com>
-- Suppose we had (HERALD (EXPORT ENV (FOO BAR))). What is the effect
if FOO already has a binding in ENV?
In our current implementation of Cedar Scheme, the effect is to lose the old
binding for FOO. This qoesn't quite feel right, but I don't see a way around it
if exporting is really going to share bindings. It may be that exported
SET!-able variables are frowned upon enough that sharing bindings is not
considered worthwhile; it that case, we could just set the current binding of
FOO. This has the pleasant implication that the binding of a symbol in an
environment is constant; thus code can look up that binding exactly once at
load-time and count on seeing changes to the name-value mapping that happen
later, such as by redefinition.
What is the effect if BAR is
bound in an ancestor of the current (file's) environment but not
directly in the current environment?
There is no difference between this cad the usual case; the binding is shared.
-- What is the effect of (HERALD (EXPORT ENV (A B) (C B)))? Is this
an error or are all three identifiers bound to the same location?
All three identifiers are bound to the same location.
-- In your Q&A section, you mention "locking" of environments to
protect them against change. This is an intriguing idea. Would this
be done at the environment level or a binding at a time?
My intent was that the locking would happen at the environment level. That is,
all bindings in the environment would be rendered un-SET!-able and no new
bindings would be allowed.
Can one
export a binding from an unlocked environment into a locked
environment?
Since this would involve the addition of a new binding to the locked
environment, the answer is no.
Likewise, what
happens if you export a binding from a locked environment into an
unlocked one?
Hmm. I suppose that this would imply that that binding was un-SET!-able,
regardless of what environment you found it in. This seems to imply that
locking is happening both at the environment level and at the level of the
individual bindings.
-- The EXPORT mechanism doesn't require any hierarchical or other
relationship between the specified environment and the
current environment, so it is possible to inject a shared binding into
any environment you can get your hands on. Such a binding could be a
trojan horse. Perhaps it should be possible to "lock" an environment
against being exported into (?!) as well?
This is precisely the question you asked earlier about exporting from an
unlocked environment into a locked one.
-- Have you found it to be important to have the `:' notation as a
short-hand for ENVIRONMENT-REF ? My previous proposals to reserve the
`:' character for CL-style package notation have been soundly drubbed.
We like to think about environments like STRINGS in the example as
``interfaces'' in the sense of languages like Cedar (surprise...) and Modula-2.
Thus, in general, we believe that programs will not have environments that
inherit from environments like STRINGS but will explicitly ``qualify'' all
references to names in such environments. We have found that when systems like
this get going and there are a large number of environments/interfaces around,
inheriting from an interface environment (it's called OPENing the interface in
Cedar) is very confusing in general. There are cases where it makes sense to
OPEN exactly one interface (for example, all of the Cedar code implementing the
Scheme interpreter and primitives OPENs the Scheme interface, which provides the
type declarations and useful procedures like LookupVariableValue), but the vast
majority of references to names in other environments are fully-qualified. If
one had to use an explicit call to ENVIRONMENT-REF (or even ACCESS in C-Scheme,
which is shorter), then the typing/reading penalty for separating environments
would likely outweigh the modularity benefits. Thus, we feel quite strongly
that some low-overhead notation for ``structured names'' is necessary.
Just for grins, how would you react to a notation using curly braces, so
your A:B1:B2 becomes {{A}B1}B2, and STRINGS:SET! becomes {STRINGS}SET! ?
Hmm. Well, it's not entirely grotesque, but I think that the colons work
better. Cedar uses periods where we use colons, but I think too many people use
periods to separate words in identifiers for this to go over well. Besides, the
colons here have a purpose not entirely unlike colons in Common Lisp, though
they have much cleaner semantics here.
From: Morris Katz <MKATZ@A.ISI.EDU>
1) I believe it is a big mistake to require that all environments have a
name.
There was a good reason(s) for deciding that not all procedures in Lisp
should
have to be named, and I believe that those arguments apply equally well to
this
case.
I think that you misunderstood the purpose of the <id> argument to
MAKE-ENVIRONMENT. It is not a name in the sense that a given name maps to a
single environment. Its only purpose is to be some nice thing to show as a part
of the printed representation of the environment. It also helps humans have a
more reasonable handle for talking about environments. The <id> has absolutely
no semantic content except that it can be extracted from the environment with
the procedure ENVIRONMENT-ID. There are no guarantees that <id>'s are unique
and no functions for mapping an <id> into the environments having it.
2) I have been interested in the semantics and use of multiple environment
inheritance for some time; but, I am not sure that it is well enough
understood
to become part of R3RS. (Maybe someone else understands it better than I do
and can convince me otherwise.) In particular, I am concerned about
efficient
implementations for interpreted code, difficulty in understanding code which
utilizes this feature, and the development of suitable browser technology to
make debugging of programs using it tractable.
It is easy to implement multiple parents efficiently in the interpreter. In
Cedar Scheme, environments have two field for parent information; one of the
fields holds the first parent and the other holds a list of the other parents.
In almost all cases, single inheritance is used and the otherParents field is
NIL. Thus, no consing of environment lists occurs in the interpreter. The
variable lookup procedure is straightforward and, in the case where otherParents
is NIL, is precisely the same as the single inheritance case.
As I pointed out above, extensive use of multiple parents can indeed make code
hard to read. On the other hand, judicious and controlled use works quite well
to improve readability. The best use is to include certain optional language
features that are kept in separate environments for just this purpose. For
example, in Cedar Scheme, there is an environment called ITERATE that provides
the entry points for a fancy iteration facility. Not everyone likes the
facility, so it is not a part of the full language we export. However, programs
wishing to use the facility can include ITERATE as a parent of their
environments and thus get seamless access to it.
I have not found fancy browser technology necessary for debugging such code.
The fact that environments print with a useful name (like the name of the file
for most code) and the fact that our debugger prints out the environment of the
current expression has made it very reasonable to work with these environments.
3) It is my belief that the loader should load the contents of files into
the
environment of the REP LOOP from which the load was initiated, unless
specified otherwise in the load command. (e.g., (load "foo" bar) would load
the file "foo" into the environment bar.) Making all files load into the
global environment unless specified otherwise in a herald seems artificial
and
constraining. What if one wants to load two slightly different copies of a
system into two sets of environments and compare their execution? Using the
herald approach I believe this would require copying all of the files and
changing the heralds. The logical extension of thiproach would be that
<expression> in (env <expresssion>) in a herald be evaluated in the load
environment, rather than the global environment.
Please note that, under our proposal, any file containing a herald is loaded
into a *fresh* environment inheriting from the GLOBAL environment. Thus,
programs in different files are protected from each other. I have no objection
to an optional argument to LOAD that provided it with a different idea of what
the GLOBAL environment was. This would allow you to load the same program into
multiple environments for the effect you ask for above.
We're trying, in this proposal, to make it possible for large numbers of
applications to coexist with some reasonable assurances about namespace
protection. We envision systems the size of Cedar or the Symbolics Genera
system with many hundreds of software packages all loaded into the same address
space and working together well because of separate namespaces and well-defined
interfaces. This level of modularity is new to Scheme and the other Lisp-like
languages but is now commonplace in systems like Cedar and Modula-2+. The
proposal lets this happen while still allowing smaller systems the very same
flexibilities currently allowed in most implementations.
4) I can't quite explain why, but the entire export section makes me feel a
little uneasy. While there are some things that can be done convieniently
through the unification of two symbols in different environments, I get the
feeling that this feature can very quckly get one into trouble. How do we
build debuggers to help support its use?
In Cedar Scheme, the binding object contains more information that the value of
the binding. It also contains the original name for the binding in the
environment in which it was created. If we wished, we could also store that
original environment in there and any other information that one might care to
have around for debugging. I don't see that this proposal makes debugging any
more difficult.
What are the costs added to normal lexical lookup due to this feature?
The only cost is that ``top-level'' environments (the kind made by
MAKE-ENVIRONMENT) must use an extra level of indirection to get to the value for
a name. Local environments, used by the interpreter for normal lambda-binding,
need not do this, since they can never be accessed by a program and can thus
never be named in an export clause.
Does it interact pathologically with incremental definition, or is this
just an erroneous gut level feeling?
As I described in answer to David's questions above, there is a funny
interaction here with REdefinition, but not with simple incremental definition.
From: Andy Freeman <andy@polya.stanford.edu>
In the herald, env is bad for the same reasons that exp would be.
Granted. I would not object to the use of ``environment'' instead of ``env''.
Regarding the presentation, it would be nice you mentioned using (or
not, as appropriate) the scheme-essentials environment to implement
the scheme and <implementation> environment. At first reading, it
looks like these environments have to have bindings for all of the
language even if they could inherit it from scheme-essentials but your
example makes it clear that they can use inheritance.
I wanted the semantics of the environments to be clear. In particular, I did
not want to make it seem as if the various environments were required to inherit
in the obvious fashion. The only required inheritance link is between the
GLOBAL and full-language environments.
I understand why you didn't write much about the default environment
in various situations, but someone should.
I'm not sure I understand what you mean here. I think that I described all of
the environments in which evaluation takes place in R3RS Scheme.
I know that it can be written, but it would be nice if one of the
optional functions told which environment a symbol was bound in. <I
forget>-bound? tells you whether a symbol is bound in an environment
or one of its ancestors, but knowing which one would be nice. Argh,
it might even be worth knowing all of the environments that a symbol
is bound in.
I took the view of the rest of R3RS Scheme, that those things a user could write
for themself need not be included in the language.
Should there be an environment analog of call-with-current-continuation?
I've not yet seen a good use for this.
BTW - Why did you chose to use strings for identifying environments
instead of say, symbols?
Let me point out that the <id> value can be any Scheme value at all, since it
has no semantics. I chose strings instead of symbols in order to reduce
confusion of <id>'s with the names to which environments are bound in certain
other environments. Thus the difference between the "SCHEME" environment and
the value bound to the symbol 'scheme in that environment.
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
What exactly is an identifier? Is it a symbol whose print name does
not end or begin with a colon? If so, the print name determines the
interpretation of an identifier. This mixes up the concept of how to
print a symbol with the concept of how to use it as an identifier.
Maybe colon is a read time macro, and no symbol is allowed to contain
colon.
[1] a:b ==> (eval (ENVIRONMENT-REF B (QUOTE A)))
[2] 'a:b ==> (ENVIRONMENT-REF B (QUOTE A))
[3] (string->symbol "A:B") ==> ?
By your description [1] is true, what about [2]? What is [3]?
An identifier is a token precisely as described in R3RS. Its internal
representation is less clear. In the same way that R3RS waffles about what
happens when I type
''foo
to my read-eval-print loop, I guess I'd better waffle about colon here. I can
tell you that in Cedar Scheme, when the reader finds an identifer by R3RS
syntax, it looks for colons in the name and, if found, constructs an
ENVIRONMENT-REF expression to return. Thus, in a sense, colons are treated as a
read macro in Cedar Scheme.
By the way, in your choices above, you've got the arguments to ENVIRONMENT-REF
backwards. In both cases, the expression should be
(ENVIRONMENT-REF A (QUOTE B))
This is all of the responses I've received so far. Further comment?
Pavel
∂23-May-88 1315 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 13:12:05 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 May 88 16:12:55 EDT
Date: Mon, 23 May 88 16:15:16 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: A Proposal for Environments in Scheme
To: Pavel.pa@XEROX.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 20 May 88 11:49:26 PDT from Pavel.pa at Xerox.COM
Message-ID: <383749.880523.JAR@AI.AI.MIT.EDU>
A dissenting opinion:
I agree that Scheme sorely needs some kind of facility for controlling
visibility of names between program components. However, I think it
would be a mistake to add first-class environments a la T or MIT Scheme.
They are too powerful and unconstrained. I would rather see a module
facility of the more conventional kind, based on declarative scoping
constructs of the same quality as LAMBDA and LETREC, rather than on
procedures that manipulate environments by side effect. In particular,
one should be able to modularize one's programs without having to resort
to a side-effecty style. (This does not imply that modules should not
be first-class.)
I would like to some way to support block compilation (like what one has
now with LETREC), and an official way to specify interfaces (which in an
untyped world are simply lists of names).
I'm working on such a facility, inspired to some extent by ML's modules,
and have had some experience with an early version of it, but it's at
too early a stage to propose here.
∂23-May-88 1323 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU [Pavel.pa: A Proposal for Environments in Scheme]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 13:22:48 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 May 88 16:15:22 EDT
Date: Mon, 23 May 88 16:17:43 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [Pavel.pa: A Proposal for Environments in Scheme]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <383755.880523.JAR@AI.AI.MIT.EDU>
A number of people seem to have not received this, so I am re-sending it.
- Jonathan
Date: Fri, 20 May 88 11:49:26 PDT
From: Pavel.pa at Xerox.COM
To: rrrs-authors at mc.lcs.mit.edu
Re: A Proposal for Environments in Scheme
I'd like to offer the following proposal for a facility for first-class
environments in Scheme. We have found it to work quite cleanly and powerfully
in Cedar Scheme and thus believe that it is worthy of consideration for
inclusion in the standard language.
Pavel Curtis
Xerox PARC/CSL
INTRODUCTION
If Scheme is to grow and be used by more people, one of the problems it must
solve is the robust isolation of different pieces of the system and user code
from each other. The system described in this section is an attempt to cleanly
and simply solve this problem, with an eye toward making the addition of a true
file-compiler a simple extension with clean semantics. It is fully implemented
in Cedar Scheme.
Note that this system does not attempt to address the questions of interfaces
vs. implementations, interface-version compatibility checking, etc. We simply
want it to be possible for normal users to write code that is insulated
reasonably well from the system and from other users.
The presented solution owes a debt to the designers of T (in many obvious ways)
and probably those of other Scheme dialects. As well, it is influenced by our
extensive experience programming in the Cedar language and environment, with its
heavy emphasis on well-defined interfaces. The proposal given here is not,
however, truly the same as any other system of which we're aware; in particular,
it departs strongly from T in some fundamental ways, so draw no premature
conclusions.
The proposal begins by specifying a Scheme interface to first-class
environments, a cornerstone of the new facility. It then describes the initial
set of environments in the system; this arrangement is in place >before< the
first file of code is LOADed. Next, it suggests a syntax and semantics for
files of Scheme code that allows fine-grained but convenient control over the
environment structure. Finally, it presents an example of a file using the new
facility.
The proposal proper is followed by some answers to questions that we anticipate
conerning the proposal.
FIRST-CLASS ENVIRONMENTS
We propose the addition to Scheme of first-class environment values. These are
precisely the environments currently used by the Scheme interpreter with one
cosmetic addition, a human-readable >identifier< for the environment. The
procedures defined on environments are as follows:
MAKE-ENVIRONMENT <id> <parent> ... [Procedure]
Creates and returns a new environment with the given <parents> (if any) and
the given identifying value, <id>, usually a string. <Id> is strictly for
debugging purposes; it is output as a part of the printed representation of
the new environment. The <parents>, on the other hand, are of semantic
interest, since variable-lookup in the resulting environment will continue
into the parents if the requested symbol has no binding in the child
environment. Variable lookup is depth-first and left-to-right among
multiple parents.
ENVIRONMENT? <object> [Procedure]
Returns true if and only if <object> is an environment.
ENVIRONMENT-ID <env> [Procedure]
Return the value specified for the <id> parameter to the call to
MAKE-ENVIRONMENT that created <env>, or #F if none was specified.
ENVIRONMENT-PARENTS <env> [Procedure]
Return a list of the values specified for the <parent> parameters to the
call to MAKE-ENVIRONMENT that created <env>. It is an error to perform
destructive operations on this list.
ENVIRONMENT-REF <env> <symbol> [Procedure]
Return the value bound to <symbol> in <env> (or its ancestors), signalling
an error if no such binding exists.
ENVIRONMENT-SET! <env> <symbol> <value> [Procedure]
Change the value bound to <symbol> in <env> (or its ancestors) to <value>,
signalling an error if no such binding exists.
ENVIRONMENT-DEFINE! <env> <symbol> <value> [Procedure]
Change the value bound to <symbol> in <env> (NOT its ancestors) to <value>,
adding such a binding to <env> if none exists. Note that
ENVIRONMENT-DEFINE! never affects any ancestor of <env>, only <env> itself.
ENVIRONMENT-BOUND? <env> <symbol> [Procedure]
Return true if and only if there exists a binding for <symbol> in <env>
(or its ancestors).
WALK-ENVIRONMENT <fn> <env> [Procedure]
<Fn> should be a procedure of two arguments, a symbol and a value. It is
applied to every binding in <env> itself, NOT including bindings in its
ancestors.
In addition to these procedures, We propose a change to the meanings of
identifiers whose names include colons:
-- No identifier may begin or end with a colon.
(Alternatively, such identifiers behave as they do now.)
-- An identifier of the form a:b1:...:bk (k >= 1) is entirely equivalent to
the expression
(ENVIRONMENT-REF a:b1:...:bk-1 'bk)
This change allows convenient reference to the values of bindings in an
environment that is bound to some variable in the current environment. For
example, the identifier STRINGS:COPY is equivalent to the expression
(ENVIRONMENT-REF STRINGS 'COPY)
and the identifier CEDAR:IO:RESET is equivalent to the expression
(ENVIRONMENT-REF (ENVIRONMENT-REF CEDAR 'IO) 'RESET)
THE INITIAL ENVIRONMENT STRUCTURE
The initial structure of environments, as seen by the first file LOADed into the
system, consists of at least the following four environments:
"SCHEME-ESSENTIALS"
Contains exactly those bindings described as "essential" in the Scheme
specification, with the semantics given there. Thus, in this environment,
APPEND takes exactly two arguments, LET does not allow the "named-LET"
variant, internal DEFINEs are not allowed, etc.
In addition, the name SCHEME-ESSENTIALS is bound to the environment
itself.
This environment is intended for use by those laboring under severe
portability constraints.
"SCHEME"
Contains exactly those bindings described in the Scheme specification,
except that a given implementation may not provide all of the optional
features. Thus, in this environment, APPEND may or may not accept an
arbitrary number of arguments, LET may or may not allow the named variant,
etc. The strongest statement that can be made about this environment is
that it certainly contains no more than what is described in R3RS and no
less than the "SCHEME-ESSENTIALS" environment.
In addition, the names SCHEME-ESSENTIALS and SCHEME are bound to the
"SCHEME-ESSENTIALS" environment and this environment itself, respectively.
This environment is intended for those who want to work in a reasonably
portable setting with no extras.
Some implementation-dependent name
Contains whatever the implementation considers the bindings of the
language it implements. It should contain everything found in the
"SCHEME" environment, though some may have been extended upward-
compatibly. In addition, other facilities, not described in R3RS,
may be visible here.
Some name should be bound to the environment itself. In addition, the names
SCHEME-ESSENTIALS and SCHEME are bound to the "SCHEME-ESSENTIALS" and
"SCHEME" environments, respectively.
It is assumed that most code written in the implementation will be
evaluated in an environment descended from this one.
In the rest of this proposal, this environment will be called the "full-
language" environment.
"GLOBAL"
Has as its only parent the full-language environment. In addition, the name
GLOBAL is bound to this environment itself.
The GLOBAL environment is distinguished in the definition of the semantics
of code files, below.
By convention, most files of code are evaluated in environments descended
from this one and most other "public" environments will be accessible
through names in the GLOBAL environment.
Implementation Note: In Cedar Scheme, for example, the initial environment
structure is created by code like the following:
(let* ((scheme-essentials (make-environment "SCHEME-ESSENTIALS"))
(scheme (make-environment "SCHEME" scheme-essentials))
(cedar-scheme (make-environment "CEDAR-SCHEME" scheme))
(global (make-environment "GLOBAL" cedar-scheme)))
(environment-define! scheme-essentials
'scheme-essentials
scheme-essentials)
(environment-define! scheme 'scheme scheme)
(environment-define! cedar-scheme 'cedar-scheme cedar-scheme)
(environment-define! global 'global global)
...)
Though it is not required by this proposal, all four environments in the initial
structure in Cedar Scheme form a chain through the parent relation. Only the
GLOBAL and full-language environments are required to be so linked.
[End note]
THE SYNTAX AND SEMANTICS OF FILES
In the usual case, a file of Scheme code contains the definitions of a few
variables (most frequently bound to procedures) intended for use by clients of
the software and several more ``helper'' variables intended only for use by the
package itself. The variables to be externally available usually belong in a
separate space of names from those in any other package. The following syntax
and semantics of files, which is upwardly-compatible with what is currently in
use in most dialects of Scheme, is intended to make the usual case easy while
allowing more complex cases to be handled smoothly as well.
A file of Scheme code, under this proposal, may optionally begin with a piece of
syntax, called a >herald<, that arranges for special treatment of the
environmental context of the code in the file. Heralds obey the following
syntax:
(HERALD <option>+)
where each <option> is one of the following:
(ENV <expression>)
The given <expression> is evaluated in the GLOBAL environment described
above before loading the rest of the file. <Expression> should yield an
environment in which the rest of the file will be evaluated. This option
may only appear once, if at all. It it does not appear, LOAD behaves as if
the option
(ENV (MAKE-ENVIRONMENT <file-name> GLOBAL))
had been given, where <file-name> is a string naming the file from which the
code is being loaded. This default is proper for most single-file packages.
Larger applications might have an initial file that creates a new
environment and binds it to some name in the GLOBAL environment; later files
would specify an ENV option naming that environment. In this way, a multi-
file application can share a single environment among many files.
(EXPORT <expression> <export-spec>+)
An <export-spec> is either a simple identifier (one without colons) or a
list of two simple identifiers; an <export-spec> that is a simple identifier
<id> is exactly equivalent to the <export-spec> (<id> <id>). The given
<expression> is evaluated in the same environment as the rest of the file
(see the description of the ENV herald option, above) after the rest of the
file has been loaded. It should yield an environment, say <env>. For each
<export-spec> (<id>1 <id>2), the environment <env> is side-effected such
that the binding for <id>1 in <env> is identical to that for <id>2 in the
environment for this file. Two bindings are ``identical'' if a change to
the value of one produces the same change to the value of the other. In
denotational terms, the two environments map the corresponding identifiers
to the very same location.
This option may appear as many times as desired. The intent is that during
the course of loading a file, it will define a variable, local to the file,
bound to a fresh environment. An EXPORT option will be used to bind this
environment to some name, either in the USER environment or in some other
environment accessible from the GLOBAL environment. Further EXPORT options
will be used to share certain of the bindings in the file with that
now-public environment. Naturally, those bindings that are not mentioned in
EXPORT options will remain entirely local to the environment of the file.
Further herald options might be added in the future, in particular to aid in the
specification of a compiler's early-evaluation environment.
If no herald appears at the beginning of a file of code, the LOAD procedure will
behave as if this herald had be given:
(HERALD
(ENV GLOBAL))
That is, such files are evaluated in the normal global environment, as all files
are now.
AN EXAMPLE FILE UNDER THE PROPOSAL
Here is an skeletal example of a file that might be part of a Scheme
implementation of the standard string-handling functions. In this ficticious
Scheme implementation, the full-language environment is named "FOO-SCHEME" and
is bound to that name as well.
Since it implements a low-level structure like strings, the code in the file
uses certain "sub-primitives" from an environment bound to the name PRIVATE in
the FOO-SCHEME environment.
After the file is loaded, the various procedures defined in the
Revised↑3 Report will be bound both to their normal names in the
SCHEME-ESSENTIALS and SCHEME environments and also to more concise names
in a new STRINGS environment, itself bound to the name STRINGS in the
GLOBAL environment.
Thus, a client of the string-handling procedures can either use the
names described in the Revised↑3 Report (e.g., STRING-REF, STRING-SET!,
STRING-COPY) or the more ``generic'' names from the STRINGS environment
(e.g., STRINGS:REF, STRINGS:SET!, STRINGS:COPY). The latter might fit
in well with analogous procedures from environments named LISTS,
VECTORS, TABLES, ENVIRONMENTS, etc.
(herald
(env (make-environment "StringsImpl" global foo-scheme:private))
(export scheme-essentials
(string-ref ref) (string-set! set) ...)
(export scheme
(string-copy copy) ...)
(export strings
ref copy (set! set) ...)
(export global
strings))
(define strings (make-environment "STRINGS"))
(define (ref string index)
...)
(define (copy string)
...)
(define (set string index value)
...)
...
Q&A ON THE PROPOSAL
Q: Why is the GLOBAL environment separate from the full-language environment?
Why not just load files into the full-language environment?
A: There are two answers to this, one based upon modularity and aesthetic
considerations and the other on future plans for the facility.
The modularity argument is that the full-language environment, like the
SCHEME or SCHEME-ESSENTIALS environments, should present an unchanging
interface. Applications should be able to count on the documented behavior
of the variables in these environments and should not be affected by the
presence or absence of other applications except where explicitly arranged
for.
The future plans argument relates to an idea for eliminating the dependence,
found in many Lisp implementations, of the semantics of code being compiled
on the presence or absence of other applications in the system running the
compiler. For example, it is frequently the case that macros defined
globally in the running system are available to code files compiled in that
system. This can (and does) lead to confusing, hidden dependencies. Within
this proposal, a compiler could create a new GLOBAL environment (again with
the full-language environment as its sole parent) and use some new herald
option as a description of what files to load into that environment to
establish the proper "early-evaluation" environment for the compilation of
the file. When the compilation is done, the ersatz GLOBAL environment can be
discarded, taking with it any side-effects that might have occurred in the
process of compilation. Under such a scheme, we would expect that the
various language environments would be "locked" against redefinition of any
of their bindings before the time that any user code is loaded, thus ensuring
that these environments do, indeed, present an unchanging interface.
Q: In what environment should an implementation's read-eval-print loop evaluate
the forms typed to it?
A: Certainly any such facility should provide a mechanism whereby any
environment can be used, but our advice for the choice of an initial or
default environment would be a "scratch" environment (as it is called in T)
whose sole parent is the GLOBAL environment. The use of a separate
environment here is intended to make it easier for a user to avoid
accidentally redefining names in the GLOBAL environment, thus possibly
breaking running applications. Of course, the Scheme report (properly)
avoids mention of read-eval-print loops, so no implementation is required to
have one at all.
Q: Why does the EXPORT herald option share actual bindings, rather than simply
sharing values?
A: This enables the use of shared, set!-able variables. Code wishing to take
advantage of this would simply specify an environment containing the binding
as an ancestor of the file environment.
Q: Why isn't there an IMPORT herald option that shares bindings in the other
direction? It would make the use of such shared variables more controllable
since one would not have to share all of the variables in the given
environment.
A: Such an option would not be antithetical to this proposal.
∂23-May-88 1349 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 13:49:05 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 23 May 88 16:35:45 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 113999; Mon 23-May-88 16:32:34 EDT
Date: Mon, 23 May 88 16:32 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: A Proposal for Environments in Scheme
To: Pavel.pa@Xerox.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <880520-115000-2371@Xerox>
Message-ID: <19880523203243.9.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 20 May 88 11:49:26 PDT
From: Pavel.pa@Xerox.COM
...
"SCHEME"
Contains exactly those bindings described in the Scheme specification,
except that a given implementation may not provide all of the optional
features. Thus, in this environment, APPEND may or may not accept an
arbitrary number of arguments, LET may or may not allow the named variant,
etc....
Except LET isn't a variable.
Can you say:
(SCHEME:LET ...)?
Presumably not, if the ":" syntax is taken to be an abbreviation for a
call on the ENVIRONMENT-REF procedure.
∂23-May-88 1404 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 14:04:32 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 May 88 16:42:15 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 13:31:10 PDT
Date: Mon, 23 May 88 13:30:45 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
In-reply-to: <383749.880523.JAR@AI.AI.MIT.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880523-133110-5223@Xerox>
Jonathan says, ``In particular, one should be able to modularize one's programs
without having to resort to a side-effecty style.''
I want to point out that the proposal I presented does not required any use at
all of the environment-manipulation facilities except for MAKE-ENVIRONMENT and
ENVIRONMENT-REF. The other procedures are not provided for conventional use of
the facility but rather for more meta-level programming, such as a portable
interpreter or inspector. None of the programs written in Cedar Scheme use the
other environment-manipulation procedures at all.
As for block compilation, the same kinds of optimizations can be applied here in
those cases where a new environment is being used for the file (the usual case).
All unexported names are entirely internal to the file and calls between them
can be optimized arbitrarily, in precisely the same way as the block compilation
of LETREC.
I, also, would like an official way to specify interfaces (though I disagree
that they must simply be lists of names; Scheme is *not* untyped, it is not
*statically* type-checked, a big difference). This is no harder or easier with
the proposal I gave than with any other set-up. One simply makes some
declaration about the names visible in the environment bound to a certain
identifier in a certain environment. No facility can do any more than that and
it's clearly as feasible in our proposal as anywhere.
Jon, could you be more concrete about what kind of system you envision? I'm not
asking for a complete proposal, but perhaps a small motivating example in the
style of your early system would be possible. I'd like to understand the issues
that you perceive.
Pavel
∂23-May-88 1421 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 14:21:19 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 May 88 16:48:34 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 13:41:36 PDT
Date: Mon, 23 May 88 13:41:18 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
In-reply-to: <19880523203243.9.ALAN@PIGPEN.AI.MIT.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880523-134136-5254@Xerox>
Alan points out that LET is not a variable, implying (I guess) that its
behaviour cannot depend upon the environment.
The point is well taken, but I submit that the statements still make sense in
some implementations, in which the sematics of special forms are in some way
attached to the environment, whether by a special kind of value bound to the
name of the special form (as in Cedar Scheme) or by a entry for that name in a
special ``syntax table'' associated with the environment. In such
implementations, one would hope that the behaviour of the special forms would
obey the same kinds of environment inheritance rules as do normal names. This
was the intent of the comments in the specification of the various initial
environments.
Can you say:
(SCHEME:LET ...)?
Presumably not, if the ":" syntax is taken to be an abbreviation for a
call on the ENVIRONMENT-REF procedure.
True, you cannot use this form. Syntax must be directly inherited under the
proposal (in the kind of implementations I described above) and cannot be used
``remotely'' as shown above.
Pavel
∂23-May-88 1508 @MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET Floyd-Hoare Verification Harmful??
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 15:08:50 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 23 May 88 17:56:58 EDT
Received: from [129.10.1.2] by RELAY.CS.NET id cf03483; 23 May 88 16:19 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa01068; 22 May 88 11:55 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4)
id AA02999; Sat, 21 May 88 14:18:15 EDT
Date: Sat, 21 May 88 14:18:15 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Message-Id: <8805211818.AA02999@corwin.CCS.Northeastern.EDU>
To: hes@SCRC-VALLECITO.ARPA
Cc: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, scheme@mc.lcs.mit.edu
In-Reply-To: Howard Shrobe's message of Fri, 20 May 88 12:54 EDT <19880520165408.4.HES@MERLIN.SCRC.Symbolics.COM>
Subject: Floyd-Hoare Verification Harmful??
Date: Thu, 19 May 88 10:35:23 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
One ought not to say things like:
"F(G(C)) := D ought to ensure that F(G(C)) = D afterwards."
too blithely. Consider the array assignment:
A[A[1]] := 2
in a two element array A, where initially A[1]=A[2]=1 . This sort of
thing had program verifiers confused for a good while in the early
70's.
Date: Fri, 20 May 88 12:54 EDT
From: Howard Shrobe <hes@scrc-vallecito.arpa>
I wrote a paper that was distributed by hand to friends in the late '70s
called "Floyd-Hoare Verifiers Considered Harmful" that pointed this ought.
It was somewhat tongue in cheek but was based on catching Vaughn Pratt
making exactly this kind of mistake. I just moved my office and found
copies of the paper. Sussman would remember it well.
That seems like an awfully rash conclusion to draw from this kind of bug. It
would be more reasonable to say something like "Unrestricted Pointer
Manipulation Considered Harmful" or "Hiding Nasty Pointer Manipulation in
Innocuous-Looking Array Manipulation Considered Harmful" or... :-)
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
∂23-May-88 1620 @MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM Floyd-Hoare Verification Harmful??
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 16:20:08 PDT
Received: from VALLECITO.SCRC.Symbolics.COM (TCP 20024224534) by MC.LCS.MIT.EDU 23 May 88 18:19:41 EDT
Received: from MERLIN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 233764; Mon 23-May-88 18:17:12 EDT
Date: Mon, 23 May 88 18:15 EDT
From: Howard Shrobe <hes@VALLECITO.SCRC.Symbolics.COM>
Subject: Floyd-Hoare Verification Harmful??
To: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET, hes@VALLECITO.SCRC.Symbolics.COM
cc: scheme@mc.lcs.mit.edu
In-Reply-To: <8805211818.AA02999@corwin.CCS.Northeastern.EDU>
Message-ID: <19880523221557.1.HES@MERLIN.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 14:18:15 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Date: Thu, 19 May 88 10:35:23 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
One ought not to say things like:
"F(G(C)) := D ought to ensure that F(G(C)) = D afterwards."
too blithely. Consider the array assignment:
A[A[1]] := 2
in a two element array A, where initially A[1]=A[2]=1 . This sort of
thing had program verifiers confused for a good while in the early
70's.
Date: Fri, 20 May 88 12:54 EDT
From: Howard Shrobe <hes@scrc-vallecito.arpa>
I wrote a paper that was distributed by hand to friends in the late '70s
called "Floyd-Hoare Verifiers Considered Harmful" that pointed this ought.
It was somewhat tongue in cheek but was based on catching Vaughn Pratt
making exactly this kind of mistake. I just moved my office and found
copies of the paper. Sussman would remember it well.
That seems like an awfully rash conclusion to draw from this kind of bug. It
would be more reasonable to say something like "Unrestricted Pointer
Manipulation Considered Harmful" or "Hiding Nasty Pointer Manipulation in
Innocuous-Looking Array Manipulation Considered Harmful" or... :-)
Mitchell Wand
College of Computer Science
Northeastern University
360 Huntington Avenue #161CN
Boston, MA 02115
CSNet: wand@corwin.ccs.northeastern.edu
I did say that the paper was tongue in cheek and that I never circulated
it, except to friends. The reason for the title at the time was that V.
Pratt (who was in the next office to me) claimed to have a complete
Floyd-Hoare axiom system for languages that manipulated arrays and
pointers and furthermore claimed that it was proven correct with respect
to a semantics based on Dynamic Logic. However, both the axiom system
and the semantics had a bug similar to the one you pointed out. I chose
such an obnoxious title as a way of chiding people about making
inflated claims for the power of their techniques.
Indeed the problem is that when allows arbitrary pointer and array
manipulations one can get aliasing problems. It is very hard to write
an axiom set in the Floyd-Hoare tradition that does not screw up for
such languages. There are two responses, one is to weaken the language
in such a way as to prevent aliasing. The other is to create a
different technique stating the language axioms and verifying programs.
To date, I haven't seen a proposal in either direction that seems
workable. Attempts to constrain pointer manipulation seem to constrain
more than you'd like.
Anyhow, I'm hardly trying to resurrect my paper. I was just amused to
see someone pointing out the same problem after all these years.
∂23-May-88 1717 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 17:17:22 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 23 May 88 20:09:07 EDT
Date: Mon 23 May 88 19:03:20-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: A Proposal for Environments in Scheme
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12400711603.24.MKATZ@A.ISI.EDU>
1) I believe it is a big mistake to require that all environments have a
name. There was a good reason(s) for deciding that not all procedures
in Lisp should have to be named, and I believe that those arguments
apply equally well to this case.
I think that you misunderstood the purpose of the <id> argument to
MAKE-ENVIRONMENT. It is not a name in the sense that a given name maps to
a single environment. Its only purpose is to be some nice thing to show as
a part of the printed representation of the environment. It also helps
humans have a more reasonable handle for talking about environments. The
<id> has absolutely no semantic content except that it can be extracted
from the environment with the procedure ENVIRONMENT-ID. There are no
guarantees that <id>'s are unique and no functions for mapping an <id> into
the environments having it.
It is precisely because the <id> is so often unnecessary, and even possible
misleading, that I feel it should not be required. I suspect that most people
in the Scheme community would baulk at a required syntax of
(lambda (<id> <args>) <body>) for lambda expressions. Why should environments
be any different?
2) I have been interested in the semantics and use of multiple environment
inheritance for some time; but, I am not sure that it is well enough
understood to become part of R3RS. (Maybe someone else understands it
better than I do and can convince me otherwise.) In particular, I am
concerned about efficient implementations for interpreted code,
difficulty in understanding code which utilizes this feature, and the
development of suitable browser technology to make debugging of
programs using it tractable.
It is easy to implement multiple parents efficiently in the interpreter.
In Cedar Scheme, environments have two field for parent information; one of
the fields holds the first parent and the other holds a list of the other
parents. In almost all cases, single inheritance is used and the
otherParents field is NIL. Thus, no consing of environment lists occurs in
the interpreter. The variable lookup procedure is straightforward and, in
the case where otherParents is NIL, is precisely the same as the single
inheritance case.
I am well aware of the obvious implementation of multiple inheritance presented
above. I was more concerned about whether variable caching schemes like those
used by MIT Cscheme still work with multiple inheritance. (i.e. Does one still
get the same performance benefits from caching? If so, how much greater is the
cost of an incremental definition due to multiple inheritance?)
Should there be an environment analog of
call-with-current-continuation?
I've not yet seen a good use for this.
MIT Cscheme has this feature and I have seen effective use made of it in the
past, although I don't seem to be able to come up with a clear, concise example
at this time.
Morry Katz
-------
∂23-May-88 1807 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU "Same Problem all these years" in Floyd-Hoare Verification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 18:07:31 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 23 May 88 21:03:25 EDT
Received: from bucsf (BUCSF.BU.EDU) by bu-it.BU.EDU (4.0/4.7)
id AA24883; Mon, 23 May 88 20:59:20 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA31865; Mon, 23 May 88 20:50:22 edt
Date: Mon, 23 May 88 20:50:22 edt
From: gjc%bucsf.BU.EDU@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8805240050.AA31865@bucsf>
To: hes@VALLECITO.SCRC.Symbolics.COM
Cc: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET,
hes@VALLECITO.SCRC.Symbolics.COM, scheme@mc.lcs.mit.edu
Subject: "Same Problem all these years" in Floyd-Hoare Verification
When you think about it you'll have to admit that that kind of problem
with arrays comes up all the time, even when writing lispmachine
microcode. Anyone who has written a decent compiler has had to think
about it, in fact, I've never seen a compiler book with a list price
over $15.00 which didnt mention it in some respect. Example: The
Manual for the Lattice C compiler version 4.0 for the AMIGA mentions
it on page 4-16.
∂23-May-88 1904 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 May 88 19:04:16 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 May 88 22:05:22 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 18:58:45 PDT
Date: Mon, 23 May 88 18:58:38 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
In-reply-to: <12400711603.24.MKATZ@A.ISI.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880523-185845-5883@Xerox>
Morry writes, ``It is precisely because the <id> is so often unnecessary, and
even possible misleading, that I feel it should not be required.''
I'm sorry; I misinterpreted your earlier comments. Your point is well taken, in
that no other R3RS data object carries an identifier with it. I suppose that I
have no problem with making the <id> optional, but I definitely want to be able
to specify it, since I always find it useful and never confusing or misleading.
I can't speak to your comments concerning the variable-caching mechanism in
C-Scheme. I believe that the usual case involves only single-inheritance,
though, so no mechanisms that work well for that should break down in the new
world. In particular, the normal environments that come up during the
evaluation of compound procedure applications (i.e., applications of the results
of lambda-expressions) will all have only single inheritance.
As for the environment analog of call-with-current-continuation, by which I
assume we mean something like THE-ENVIRONMENT in C-Scheme, I would truly
appreciate a clear, concise example.
Pavel
∂24-May-88 0906 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 May 88 09:06:51 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 24 May 88 11:42:02 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA08685; Mon, 23 May 88 13:49:09 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Mon, 23 May 88 13:49:04 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA04694; Mon, 23 May 88 13:49:04 EDT
Date: Mon, 23 May 88 13:49:04 EDT
Message-Id: <8805231749.AA04694@darwin.sun.uucp>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Fri, 20 May 88 11:49:26 PDT <880520-115000-2371@Xerox>
Subject: A Proposal for Environments in Scheme
Thank you for your interesting environment proposal. I am not sure
what I think of it, but I do have one question.
What exactly is an identifier? Is it a symbol whose print name does
not end or begin with a colon? If so, the print name determines the
interpretation of an identifier. This mixes up the concept of how to
print a symbol with the concept of how to use it as an identifier.
Maybe colon is a read time macro, and no symbol is allowed to contain
colon.
[1] a:b ==> (eval (ENVIRONMENT-REF B (QUOTE A)))
[2] 'a:b ==> (ENVIRONMENT-REF B (QUOTE A))
[3] (string->symbol "A:B") ==> ?
By your description [1] is true, what about [2]? What is [3]?
John
∂24-May-88 1019 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 May 88 10:16:18 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 24 May 88 13:17:02 EDT
Date: Tue 24 May 88 13:13:21-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Proposed modifications to R3RS
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12400910036.32.MKATZ@A.ISI.EDU>
The following is a series of proposed modifications to and
deletions from R3RS. They are all based on the following two
principals:
a) Syntactic sugar should only be added to the language if its
usefulness far outweighs the complexity it introduces
(e.g., I believe that (define (<name> <vars>) <body) as
syntactic sugar for (define <name> (lambda (vars) <body>))
and named-let both fulfill this criterion.) or it is important
for performance reasons that some construct which can be
built from a few primitives be a primitive itself.
b) Overspecification should be avoided as it artificially
prohibits reasonable implementations.
In at least one case, a suggestion to follow has been mentioned
before; but, I feel it is important enough to justify further
flag waving.
1) The DO construct should be eliminated from the language as it
is easily implemented using named-let's or letrec's. Its
syntax is difficult to follow at best, and it is not powerful
enough for many applications. (e.g. One often has a <test>
which is the disjunction of many different forms and wants to
return a different result depending on which form is true.
DO does not give a simple way of implementing this case short
of repeating the conditionals in the <expressions>.) If
people really want DO because of dusty deck problems or
compatibility with CL (Editorial comment: I think this is a
really bad motivation.) lets settle on a macro standard and
let those who want DO have it as a library function (special
form).
2) The CASE statement should be eliminated for the same reasons
as DO. How many of you have ever used a CASE? Would it
really have been less clear had you used a COND? This should
be a library function if it is going to exist at all.
3) I believe that AND is overspecified as it states that "The
<test> expressions are evaluated from left to right, and the
value of the first expression that evaluates to a false value
is returned. Any remaining expressions are not evaluated.
If all the expressions evaluate to true values, the value of
the last expression is returned." This should be replaced by
something like the following: "The <test> expressions are
evaluated from left to right, with evaluation terminating
with the first expression that evaluates to a false value.
Any remaining expressions are not evaluated. If some
expression evaluates to false then a false value is returned,
otherwise a true value is returned." (A similar change should
be made to OR.
A compiler should feel free to replace
(or (a) (not (a)))
with #t if it can prove that A is side-effect free and
terminates without generating an error. Similarly,
(and (fact n) (fact (-1+ n)))
should be replaceable by #t if FACT is the standard recursive
factorial function and N can be proven to be a nonnegative
integer. (These transformations are not possible given the
current specification.)
Also, an implementor is not free to introduce unique true and
false objects which are always returned by predicates.
If one actually wants the old semantics of AND they can
always write
(let ((test1 <test1>))
(if test1
test1
<test2>))
which I believe is much more transparent, anyway.
4) LAST-PAIR should be eliminated as it is gratuitous at best.
After all, its tail-recursive implementation appears directly
below it in R3RS. Personally, I can see no performance
reason for keeping it, which would be the only possible
justification.
Morry Katz
P.S. I erroneously stated in a previous message that MIT CScheme
has a feature like call-with-current-continuation for
environments. It does NOT. I was thinking at the time of its
IN-PACKAGE feature which allows one to evaluated an expression in
an existing environments and in my mind is a (loose) environment
analog to throwing to a continuation. I will have to reread
Johnson and Duggan's paper, "Stores and Partial Continuations as
First-Class Objects in a Language and its Environment," from POPL
1988 before I can appropriately comment on the original question
as to whether we should introduce a call-with-current-environment.
-------
∂25-May-88 0554 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 May 88 05:53:53 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 25 May 88 02:35:13 EDT
Received: by ti.com id AA08189; Tue, 24 May 88 16:01:37 CDT
Received: from mips by tilde id AA04707; Tue, 24 May 88 15:50:16 CDT
Received: by mips id AA07133; Tue, 24 May 88 15:50:08 CDT
Date: Tue, 24 May 88 15:50:08 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8805242050.AA07133@mips>
To: MKATZ@A.ISI.EDU
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Tue 24 May 88 13:13:21-EDT <12400910036.32.MKATZ@A.ISI.EDU>
Subject: Proposed modifications to R3RS
> From: Morris Katz <MKATZ@A.ISI.EDU>
> Subject: Proposed modifications to R3RS
> [...]
> 1) The DO construct should be eliminated from the language as it
> is easily implemented using named-let's or letrec's.
DO is inessential and so is perhaps a good candidate for excision from
the IEEE standard, but it is probably too commonly used for most of us
to want to remove support for it from our existing or planned
implementations. Thus it should remain in the informal standard to
ensure we all do it the same way. (For example, someone may make it
re-ASSIGN rather than re-BIND the variables at each iteration if they
didn't know better. That could introduce subtle portability bugs.)
> 2) The CASE statement should be eliminated for the same reasons
> as DO. How many of you have ever used a CASE? Would it
> really have been less clear had you used a COND? This should
> be a library function if it is going to exist at all.
CASE is also inessential syntax. I use CASE a lot, and find it to be
much more clear than COND when I use it. CASE makes it clear that I
am dispatching on a value; I have to inspect all of the clauses of a
COND to see if they all fit the same pattern otherwise. Since CASE is
syntax and not a function, we would need macros before we could demote
it to a library.
> 3) I believe that AND is overspecified [...]
I see both sides of this one. As an implementor, I hate for these
things to be overspecified. In fact, I have some logic in my compiler
to look for chances to simplify the true value returned by AND and its
kin. However, AND has such a long history that the dusty deck (and
dusty brain) factor can't be ignored.
> 4) LAST-PAIR should be eliminated as it is gratuitous at best.
Definitely.
See, I tried to be agreeable!
Regards,
David Bartley
∂25-May-88 0758 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu HELP ME!!!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 May 88 07:58:49 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 07:31:37 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA00194@BLOOM-BEACON.MIT.EDU>; Tue, 24 May 88 20:35:36 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 24 May 88 00:22:31 GMT
From: portal!cup.portal.com!JJ@uunet.uu.net
Organization: The Portal System (TM)
Subject: HELP ME!!!
Message-Id: <5813@cup.portal.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Poor College Student needs Your Help!! :-(
Hi. I just finished my junior year in college, and now I'm
faced with a major problem. I can't afford to pay for my senior
year. I've tried everything. I can't get any more student loans,
I don't qualify for any more scholarships, and my parents are as
broke as am I. So as you can see, I've got a major problem. But
as far as I can see, there is only one solution, to go forward.
I've come along way, and there is no chance in hell that I'm going
to drop out now! I'm not a quiter, and I'm not going to give up.
But here is why I'm telling you all this. I want to ask a favor of every
one out here on the net. If each of you would just send me a one
dollar bill, I will be able to finish college and go on with my life.
I'm sure a dollar is not much to any of you, but just think how it
could change a person's life. I'd really like to encourage all of you
to help me out, I've no other place to go, no other doors to knock
on. I'm counting on all of you to help me! (PLEASE!)
If you would like to help a poor boy out, please send $1 (you can
of course send more if you want!! :-)
Jay-Jay's College Fund
PO BOX 5631
Lincoln, NE 68505
PS. Please don't flame me for posting this to so many newsgroups,
I really am in dire need of help, and if any of you were as desparate
as I am, you just might resort to the same thing I am. Also, please
don't tell me to get a job! I already have one and work over 25 hrs
a week, plus get in all my classes, plus find time to study! So hey,
please consider it! It would really mean a lot to me. Thank you!
NOTE: Any extra money I receive will go to a scholarship fund to help
others in the same situation. :-)
∂25-May-88 0901 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 May 88 09:01:06 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 25 May 88 11:55:27 EDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09202; 24 May 88 20:18 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 24 May 88 20:16:15 bst
Message-Id: <15442.8805241916@aiva.ed.ac.uk>
To: MKATZ@a.isi.edu, rrrs-authors@mc.lcs.mit.edu
Subject: Re: Proposed modifications to R3RS
> b) Overspecification should be avoided as it artificially
> prohibits reasonable implementations.
> 3) I believe that AND is overspecified as it states that "[...]
> If all the expressions evaluate to true values, the value of
> the last expression is returned."
> (A similar change should be made to OR.)
Your complaint about AND is that it returns the value of the last form
instead of simply true or false. But calling that "overspecification"
is just another way of saying it should return simply true or false,
and so it is not an argument for returning true or false.
I guess what I'm trying to say is that it depends on what you want AND
and OR to be. Only if you want logical operations and no more are
they overspecified.
I don't much mind the change in AND. After all, only the last
expression can return anything other than #f. With OR, on the other
hand, it's useful to know which true value was obtained.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂25-May-88 0924 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: HELP ME!!!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 May 88 09:24:00 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 11:59:06 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA08604@BLOOM-BEACON.MIT.EDU>; Wed, 25 May 88 02:04:03 EDT
Received: from USENET by bloom-beacon with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon if you have questions)
Date: 25 May 88 03:35:19 GMT
From: relph@presto.ig.com (John M. Relph)
Organization: IntelliGenetics Inc., Mtn. View, Ca.
Subject: Re: HELP ME!!!
Message-Id: <6397@ig.ig.com>
References: <5813@cup.portal.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <5813@cup.portal.com> JJ@cup.portal.com writes:
$Poor College Student needs Your Help!! :-(
$
$Hi. I just finished my junior year in college, and now I'm
$faced with a major problem. I can't afford to pay for my senior
$year. I've tried everything. I can't get any more student loans,
$I don't qualify for any more scholarships, and my parents are as
$broke as am I. So as you can see, I've got a major problem. But
$as far as I can see, there is only one solution, to go forward.
$I've come along way, and there is no chance in hell that I'm going
$to drop out now! I'm not a quiter, and I'm not going to give up.
$
$But here is why I'm telling you all this. I want to ask a favor of every
$one out here on the net. If each of you would just send me a one
$dollar bill, I will be able to finish college and go on with my life.
$I'm sure a dollar is not much to any of you, but just think how it
$could change a person's life. I'd really like to encourage all of you
$to help me out, I've no other place to go, no other doors to knock
$on. I'm counting on all of you to help me! (PLEASE!)
$If you would like to help a poor boy out, please send $1 (you can
$of course send more if you want!! :-)
$
$Jay-Jay's College Fund
$PO BOX 5631
$Lincoln, NE 68505
$
$PS. Please don't flame me for posting this to so many newsgroups,
$I really am in dire need of help, and if any of you were as desparate
$as I am, you just might resort to the same thing I am. Also, please
$don't tell me to get a job! I already have one and work over 25 hrs
$a week, plus get in all my classes, plus find time to study! So hey,
$please consider it! It would really mean a lot to me. Thank you!
$
$NOTE: Any extra money I receive will go to a scholarship fund to help
$others in the same situation. :-)
Jay-Jay's original plea ended as follows:
$PS. Please don't flame me for posting this to so many conferences,
$I really am in dire need of help, and if any of you were as desparate
$as I am, you just might resort to the same thing I am.
Someone told him to get a job. Someone also mentioned mail fraud.
Jay-Jay has never replied, he just learned how to send to more
newsgroups. Please folks, send a message to portal and tell his sysop
to hang him up.
-- John
----
John M. Relph
IntelliGenetics, Inc.
Internet: Relph@Bionet-20.ARPA
∂25-May-88 2134 @MC.LCS.MIT.EDU:gls@Think.COM [wand@corwin.ccs.northeastern.edu: ''Update functions'' in Scheme.]
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 May 88 21:33:57 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 25 May 88 23:54:54 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 25 May 88 13:19:35 EDT
Received: by kali.think.com; Wed, 25 May 88 13:19:32 EDT
Date: Wed, 25 May 88 13:19:32 EDT
From: gls@Think.COM
Message-Id: <8805251719.AA12205@kali.think.com>
To: scheme@mc.lcs.mit.edu
Subject: [wand@corwin.ccs.northeastern.edu: ''Update functions'' in Scheme.]
In case anyone cares:
Date: Wed, 25 May 88 09:56:02 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Date: Mon, 23 May 88 18:01:34 EDT
From: gls@think.com
Date: Sat, 21 May 88 13:59:33 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Now consider the array assignment Y(A[.]) := 2 . :-)
Umm, I will admit my ignorance. Could you explain this joke? --Mitch
My notation was obscure, if not erroneous. By A[.] I meant the
array A considered as a unary function. So the assignment means
to change A so that its fixed point (or at least one of them) is 2.
Assuming a principle of least change, that means the same as
A[2] := 2. (Do you agree?)
I guess so. :-) --Mitch
∂26-May-88 0053 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET Macros; lexcial scope
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 00:53:29 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 May 88 03:38:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2992; Wed, 25 May 88 13:01:27 EDT
Received: from DB0TUI6.BITNET (NET) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP
id 2991; Wed, 25 May 88 13:01:24 EDT
Received: by tub.UUCP; Wed, 25 May 88 18:59:30 +0200; AA00682
Date: Wed, 25 May 88 18:59:30 +0200
From: Oliver Laumann <net%TUB.BITNET@MITVMA.MIT.EDU>
Message-Id: <8805251659.AA00682@tub.UUCP>
To: scheme@mc.lcs.mit.edu
Subject: Macros; lexcial scope
I would like to know how you would expect macros to work in Scheme
or generally in a lexically scoped Lisp.
(I'm not talking about a specific Scheme implementation here)
Suppose Scheme supported something like ``define-macro'' with the same
syntax as ``define'', so that you could, for instance, write
(define-macro (incr x) `(set! ,x (+ ,x 1)))
Now my question is whether macros are lexically scoped (like functions)
or whether macro expansion is performed in a purely syntactic way.
Consider the following example:
(define x 1)
(define-macro (m) x)
(let ((x 2))
(m))
Would you expect that (m) evaluates to 1 or to 2? Yes, I know, if I had
written (define-macro (m) 'x), it would evaluate to 2. However, in
both Common Lisp (using a different syntax, of course) and C-Scheme,
(m) returns 1 in the example above.
Thus, it looks as if the first time the macro body is evaluated, the
evaluation takes place in the lexical scope of the define-macro.
Now consider a slighly more complex example:
(define x 1)
(let ((x 2))
(define-macro (m) x)
(let ((x 3))
(m)))
In both Common Lisp and C-Scheme, this evaluates to 1. My mind boggles.
The macro is local to the outer let, why is the ``x'' inside the macro
body bound to the global variable? Are macro always implemented like
this (in lexically scoped Lisps)? If so, why?
[I'm sorry, if the answer to my question is obvious; I'm new to Scheme
and Lisp.]
--
Regards,
Oliver Laumann, Technical University of Berlin, Germany.
...!pyramid!tub!net or net@TUB.BITNET
...!mcvax!unido!tub!net
∂26-May-88 0207 @MC.LCS.MIT.EDU:gls@Think.COM Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 02:07:42 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 26 May 88 04:49:27 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 25 May 88 13:03:13 EDT
Received: by kali.think.com; Wed, 25 May 88 13:03:07 EDT
Date: Wed, 25 May 88 13:03:07 EDT
From: gls@Think.COM
Message-Id: <8805251703.AA12183@kali.think.com>
To: jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: MKATZ@a.isi.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jeff Dalton's message of Tue, 24 May 88 20:16:15 bst <15442.8805241916@aiva.ed.ac.uk>
Subject: Proposed modifications to R3RS
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 24 May 88 20:16:15 bst
...
I don't much mind the change in AND. After all, only the last
expression can return anything other than #f. With OR, on the other
hand, it's useful to know which true value was obtained.
Actually, in the current confused state of affairs I believe that
#f and () might be distinct values but both treated as false?
In which case it might be useful with AND to know which false
value was obtained. :-)
--Quux
∂26-May-88 0257 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Omission in R↑3.5 LETREC description?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 02:57:23 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 May 88 05:52:13 EDT
Date: Wed, 25 May 88 12:29:19 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Omission in R↑3.5 LETREC description?
To: Ziggy@VX.LCS.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <385093.880525.JAR@AI.AI.MIT.EDU>
Date: Mon, 23 May 88 23:46:05 EDT
From: Ziggy at VX
To: jar at ai
Re: Omission in R↑3.5 LETREC description?
Shouldn't the caveat: [p.10 or R↑3.5]
"...without referring to the value of any <variable>."
read
"...without referring to the value or location of any <variable>."
-----
Specifically, isn't the following a screw case:
(LETREC ((wanna-be-a-doctor 'DOCTOR)
(imagine-my-surprise! (BEGIN (SET! wanna-be-a-doctor 'NURSE)
'ZOWIE!!)))
wanna-be-a-doctor) ==> NURSE
-----
One could reasonably assume, based on the English description (and
desugaring on page 36) that the RHSs will each be evaluated then
their results will be stored thus the above should yield DOCTOR.
Note that the value of WANNA-BE-A-DOCTOR is not referred to, but the
location to which it is bound IS.
Yuck. I'm not sure we want to be quite this anal about it, and I'm a
little worried about formal description and implementation of the kind
of error checking you suggest. It would require making LETREC a
primitive, rather than derived, expression type, I think. I'm cc'ing
rrrs-authors to see whether anyone else has thought about this and has
opinions.
∂26-May-88 0307 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 03:07:18 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 May 88 05:52:25 EDT
Date: Wed, 25 May 88 13:07:23 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Proposed modifications to R3RS
To: MKATZ@A.ISI.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 24 May 88 13:13:21-EDT from Morris Katz <MKATZ at A.ISI.EDU>
Message-ID: <385117.880525.JAR@AI.AI.MIT.EDU>
Date: Tue 24 May 88 13:13:21-EDT
From: Morris Katz <MKATZ at A.ISI.EDU>
a) Syntactic sugar should only be added to the language if its
usefulness far outweighs the complexity it introduces.
It's difficult to make objective arguments on this rounds, because
different people have uses for different things.
b) Overspecification should be avoided as it artificially
prohibits reasonable implementations.
Underspecification effectively amounts to giving an axiomatic semantics
(proof system) for the language, as opposed to a denotational one (a
model). The problem with underspecification is that one can have a
program that works fine in one implementation and fails in another, so
the only way to produce portable code is by reasoning about it, and
testing doesn't help you a bit. While I agree that some
underspecifications are important, I believe you can go too far in
underspecifying things that really don't make much difference, requiring
reasoning in situations where testing ought to be sufficient.
Underspecifications makes the language harder to learn and use, since an
implementation cannot teach them very well. One must be aware of all
underspecifications all the time. I think they should be minimized, not
maximized.
1) The DO construct should be eliminated from the language as it
is easily implemented using named-let's or letrec's.
At first I thought I didn't make much use of it, but empirical evidence
shows that I think it's important to keep it. I just checked one large
recently-written system of mine, and I wrote 47 out of 88 loops using
DO.
I can't believe this question is being raised again. You would do us a
favpor by looking through the archives (in AI: LSPMAI; RRRS MAILnn) to
see how this issue was dealt with before. It was also argued at the
1984 meeting, as I remember.
2) The CASE statement should be eliminated for the same reasons
as DO. How many of you have ever used a CASE?
I use it all the time.
Would it really have been less clear had you used a COND?
Yes.
3) I believe that AND is overspecified ...
It has been proposed to eventually eliminate the possibility of multiple
false values. That would fix your complaint about AND. Until that
time, AND should be symmetric with OR. Thus in your arguments I would
prefer you use OR as your example rather than AND. It seems somewhat
unprincipled that you start out by saying you think AND is
underspecified and say only as an afterthought that you think OR is.
I think that rather than take the half-way measure you propose, you
should instead be in favor of making it an error for the predicate of an
IF to be a non-boolean. This would get you some of the results you
want for OR and AND, and it would get you many other beneficial
transformations as well.
By the way, it's clear that OR (and AND) must necessarily return the
value of the last form if previous forms evaluate to false (true);
otherwise you will lose tail recursion. (Unless you imagine one
sophisticated continuation garbage collector.)
4) LAST-PAIR should be eliminated as it is gratuitous at best.
After all, its tail-recursive implementation appears directly
below it in R3RS. Personally, I can see no performance
reason for keeping it, which would be the only possible
justification.
OK, let's flush LENGTH, APPEND, REVERSE, ASSOC, CHAR=?, VECTOR->LIST,
and all other easily-definable procedures as well. EQUAL? isn't so hard
to write either. There is no performance advantage to having these.
∂26-May-88 0930 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Macros; lexcial scope
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 09:30:16 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 May 88 12:27:13 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA12311@BLOOM-BEACON.MIT.EDU>; Thu, 26 May 88 12:22:44 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 May 88 14:53:24 GMT
From: krulwich-bruce@yale-zoo.arpa (Bruce Krulwich)
Organization: Yale University Computer Science Dept, New Haven CT 06520-2158
Subject: Re: Macros; lexcial scope
Message-Id: <30160@yale-celray.yale.UUCP>
References: <8805251659.AA00682@tub.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8805251659.AA00682@tub.UUCP> net@TUB.BITNET (Oliver Laumann)
writes:
>Consider the following example:
> (define x 1)
> (define-macro (m) x)
> (let ((x 2))
> (m))
>Would you expect that (m) evaluates to 1 or to 2? In both Common Lisp
>(using a different syntax, of course) and C-Scheme, (m) returns 1 in the
>example above. Thus, it looks as if the first time the macro body is
>evaluated, the evaluation takes place in the lexical scope of the
>define-macro.
Rather, that the macro is evaluated in the lexical scope in which it was
defined, just like regular functions.
>Now consider a slighly more complex example:
> (define x 1)
> (let ((x 2))
> (define-macro (m) x)
> (let ((x 3))
> (m)))
>In both Common Lisp and C-Scheme, this evaluates to 1.
T's DEFINE-SYNTAX does what you want in both of these cases, evaluating to 1
in the first case and 2 in the second case.
Bruce Krulwich
∂26-May-88 1045 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Macros; lexcial scope
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 10:45:33 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 May 88 13:27:27 EDT
Received: by kleph.AI.MIT.EDU; Thu, 26 May 88 13:27:07 edt
Date: Thu, 26 May 88 13:27:07 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8805261727.AA06410@kleph>
To: net%TUB.BITNET@MITVMA.MIT.EDU
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Oliver Laumann's message of Wed, 25 May 88 18:59:30 +0200 <8805251659.AA00682@tub.UUCP>
Subject: Macros; lexcial scope
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 25 May 88 18:59:30 +0200
From: Oliver Laumann <net%TUB.BITNET@MITVMA.MIT.EDU>
Consider the following example:
(define x 1)
(define-macro (m) x)
(let ((x 2))
(m))
in both Common Lisp (using a different syntax, of course) and
C-Scheme, (m) returns 1 in the example above.
You have an old version of C-Scheme. The current version (release 6
and later) gives an "unbound variable X" error while evaluating the
last expression.
Now consider a slighly more complex example:
(define x 1)
(let ((x 2))
(define-macro (m) x)
(let ((x 3))
(m)))
In both Common Lisp and C-Scheme, this evaluates to 1.
Again, this produces an "unbound variable X" error in the current
release.
As one of several people who has thought about the issues you raise,
I'll offer the following:
1. The semantics of special forms like `define-macro' is confusing.
The naive interpretation of the meaning requires that a macro created
this way should be closed in the environment in which it lexically
appears. Unfortunately, that environment usually does not exist until
run time, while for obvious reasons it is desirable that macros be
closed at compile time.
2. C-Scheme has "solved" this problem by forcing all such macros to be
closed in the global environment (actually, in a distinct child of the
global environment). This alternate environment is guaranteed to
exist at compile time, and under normal circumstances your other
definitions won't interact with it. Thus, this explains the "unbound
variable" errors. I say "solved" above because, rather than providing
an acceptable solution, all we've really done is try to make it
obvious when the user is confused about the closing environment.
3. My personal conclusion is that `define-macro' is a bad idea. I
rarely, if ever, use it. C-Scheme provides facilities for explicitly
constructing syntax tables (see the file "runtime/syntax.scm",
procedures `make-syntax-table' and `syntax-table-define', and the
special forms `macro' and `using-syntax') which do not have this
problem. Using these facilities, the macros are closed in the
environment in which they are loaded. They also appear in a different
file from their references, thus reducing the confusion.
4. The R*RS committee is in the process of generating a "standard"
macro facility. Keep tuned for more news.
∂26-May-88 1140 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: Proposed modifications to RRRS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 11:39:57 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 26 May 88 14:31:14 EDT
Date: Thu 26 May 88 14:27:49-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: Proposed modifications to RRRS
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12401447879.26.MKATZ@A.ISI.EDU>
>> 3) I believe that AND is overspecified [...]
>I see both sides of this one. As an implementor, I hate for these
>things to be overspecified. In fact, I have some logic in my compiler
>to look for chances to simplify the true value returned by AND and its
>kin. However, AND has such a long history that the dusty deck (and
>dusty brain) factor can't be ignored.
When one actually wants AND and OR to return the values currently specified
instead of just being boolean predicates, there is a simple and efficient
implementation in terms of the AND and OR semantics I advocate. However, the
reverse is not true. One could wrap all all uses of AND and OR as predicates
in a function which canonicalized the return values to #t and #f, but this
would be neither efficient nor esthetically pleasing. Furthermore, this
would add yet one more special case for the efficient compiler to worry about.
Lastly, I must repeat that I just don't buy the argument that language
designers must repeat the mistakes of the past in order to maintain
compatibility. Bad ideas should be purged from or memories, not reenforced.
>> 1) and 2) Do and CASE
My original proposal advocated standardizing macros and then relegating
these features to library status. I stand by this recommendation. To me the
distinction between essential and inessential is a bad one because those
attempting to write portable code can only depend on essential features,
anyway. This means that inessential features are effectively not part of the
language and a really just commonly used portions of a library. I therefore
make the previously discussed suggestion again:
5) Lets remove the distinction between essential and inessential features and
in each case decide that the feature either is or is not part of the language.
-------
∂26-May-88 1151 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Re: Proposed modifications to R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 11:51:04 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 26 May 88 14:42:31 EDT
Date: Thu 26 May 88 14:39:27-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Re: Proposed modifications to R3RS
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12401449998.26.MKATZ@A.ISI.EDU>
>> b) Overspecification should be avoided as it artificially
>> prohibits reasonable implementations.
>> 3) I believe that AND is overspecified as it states that "[...]
>> If all the expressions evaluate to true values, the value of
>> the last expression is returned."
>> (A similar change should be made to OR.)
>Your complaint about AND is that it returns the value of the last form
>instead of simply true or false. But calling that "overspecification"
>is just another way of saying it should return simply true or false,
>they overspecified.
If by true and false above the author meant #t and #f, this is not what I
advocated at all. I carefully specified that AND and OR should return a true
value or a false value (by which I meant something that acted as a true or a
false when used by IF and COND.). I strongly believe that specifying that
AND and OR return either #t or #f would be overspecification in the oposite
direction. My original specification makes all current implementations
adhere to the standard. It just allows new implementations to perform
more effective optimizations of the uses of AND and OR.
Morry Katz
-------
∂26-May-88 1207 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Proposed modifications to RRRS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 12:07:21 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 26 May 88 15:00:06 EDT
Received: by kleph.AI.MIT.EDU; Thu, 26 May 88 14:59:05 edt
Date: Thu, 26 May 88 14:59:05 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8805261859.AA06488@kleph>
To: MKATZ@A.ISI.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Morris Katz's message of Thu 26 May 88 14:27:49-EDT <12401447879.26.MKATZ@A.ISI.EDU>
Subject: Proposed modifications to RRRS
Reply-To: cph@zurich.ai.mit.edu
Regarding your suggestions to change the semantics of AND and OR:
I find the current semantics useful and desirable. I have long felt
that one of the good features of lisp was that, rather than having two
distinguished boolean values, there is only only one: #F. I have
often found it useful that all other values are true.
My feeling is that AND and OR are extensions of that philosophy, in
that they do not canonicalize the truth value as #T.
While I agree with you that we should not retain these for historical
reasons, I disagree in that I feel these constructs, with their
current semantics, have value in a modern lisp.
∂26-May-88 1329 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 13:29:16 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 May 88 16:22:57 EDT
Date: Thu, 26 May 88 16:20:53 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: opaque type proposal
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <386085.880526.JAR@AI.AI.MIT.EDU>
Opaque types / record structures for R↑4 Scheme
Draft #3, J. Rees, 26 May 1988
Norman Adams's message of 8 July 1987 to RRRS-Authors proposing record
types for Scheme met with a deafening silence. Here is my reiteration
of his proposal. This also is a counter-proposal to the
INJECT/PROJECT/IN? opaque type facility that Will and/or I proposed a
while back.
The proposal consists of the following 5 procedures. MAKE-RECORD-TYPE
creates a new "record type" object, and the other 4 procedures are
accessors for record types that return procedures. The type of the
value returned for each procedure is given after a ":".
(MAKE-RECORD-TYPE type-id field-names) : record-type
where type-id is a symbol, and field-names is a list of symbols
(RECORD-CONSTRUCTOR record-type) : (object X ...) -> record
(RECORD-PREDICATE record-type) : object -> boolean
(RECORD-ACCESSOR record-type name) : record -> object
(RECORD-UPDATER record-type name) : record X object -> unspecified
Example:
(define yow-record-type (make-record-type 'yow '(a b c)))
(define make-yow
(let ((construct-yow (record-constructor yow-record-type)))
(lambda (a-val other-val)
(let ((b-val (compute-b other-val))
(c-val (compute-c a-val b-val other-val)))
(construct-yow a-val b-val c-val)))))
(define yow? (record-predicate yow-record-type))
(define yow-a (record-accessor yow-record-type 'a))
(define yow-b (record-accessor yow-record-type 'b))
(define yow-c (record-accessor yow-record-type 'c))
(define set-yow-c! (record-updater yow-record-type 'c))
(yow? (make-yow 2 17)) => #t
(yow-a (make-yow 2 17)) => 2
It is an error to call an accessor or updater for a record type R on an
object that wasn't created by R's constructor. MAKE-RECORD-TYPE is a
side effect, like CONS. Every new record type is disjoint from every
old one and from other Scheme types such as pairs, vectors, and
procedures. In particular, records must answer false to existing type
predicates, including PAIR?, VECTOR?, and PROCEDURE?. Thus this
mechanism must be added primitively to Scheme.
The type-id argument to MAKE-RECORD-TYPE has no semantic content. It is
solely for the use of the printer and related routines, to make records
easier to identify during debugging. The field names are used only for
coordination between MAKE-RECORD-TYPE and RECORD-ACCESSOR/UPDATER.
-----
Notes:
The use of the word "type" for an object that describes a type is
somewhat inappropriate, and would raise the hackles of people who
believe they know what types are. The objects might better be called
"record type descriptors" even though that's a little long; the
constructor would then be MAKE-RECORD-TYPE-DESCRIPTOR.
This is essentially T's record package (MAKE-STYPE), except that the
constructor takes as arguments initial values for all the fields,
rather than for none of them.
No general record-type-defining macro is proposed. Defining a good one
is difficult or impossible; I have tried many times and failed to come
up with something that's both elegant and flexible enough. Once we have
macros, people can roll their own, so we shouldn't clutter the language
at this point.
Initial value arguments to constructors could be passed by keyword, as
in Common Lisp, but they're positional here for consistency with the
rest of Scheme, and for efficiency.
There is intentionally no way to go from a record to its record-type.
Clearly implementations can (and for debugging, would) provide such a
procedure, but it would have the same abstraction-breaking ability
that something like PROCEDURE-CODE have.
Question: should there be a (RECORD-COPIER record-type) as in CL?
- Will Clinger says no; a copier for a particular record type
can be written pretty easily.
- Richard Kelsey says yes, for performance and convenience.
Issues purposely avoided: subtyping (a.k.a. inheritance); print methods
(a.k.a. object-oriented programming); integration with modules and/or
environments (a.k.a. Pascal WITH). While these are all probably
desirable, they open many worm cans, and we should try to prevent the
consideration of such questions to slow the adoption of this proposal.
-----
Here is a sample implementation. It is not minimal, but is instead
intended to be somewhat realistic.
A real implementation would require that records not satisfy VECTOR? (or
any other existing Scheme type predicate).
(define (make-record-type type-id field-names)
(define (constructor . field-values)
(if (= (length field-values) (length field-names))
(apply vector the-record-type field-values)
(error "wrong number of arguments to record constructor"
type-id field-values)))
(define (predicate obj)
(and (vector? obj)
(> (vector-length obj) 0)
(eq? (vector-ref obj 0) the-record-type)))
(define (accessor name)
(let ((i (field-index name)))
(lambda (record)
(if (predicate record)
(vector-ref record i)
(error "not a record" record name)))))
(define (updater name)
(let ((i (field-index name)))
(lambda (record new-value)
(if (predicate record)
(vector-set! record i new-value)
(error "not a record" record name)))))
(define (field-index name)
(let loop ((l field-names) (i 1))
(if (null? l)
(error "bad field name" name)
(if (eq? name (car l))
i
(loop (cdr l) (+ i 1))))))
(define the-record-type
(lambda (request)
(case request
((constructor) constructor)
((predicate) predicate)
((accessor) accessor)
((updater) updater))))
the-record-type)
(define (record-constructor r-t) (r-t 'constructor))
(define (record-predicate r-t) (r-t 'predicate))
(define (record-accessor r-t field-name) ((r-t 'accessor) field-name))
(define (record-updater r-t field-name) ((r-t 'updater) field-name))
∂26-May-88 2005 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 20:05:00 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 26 May 88 23:06:01 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Thu, 26 May 88 23:02:23 edt
Date: Thu, 26 May 88 23:02:23 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8805270302.AA14916@chamarti>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Fri, 20 May 88 11:49:26 PDT <880520-115000-2371@Xerox>
Subject: A Proposal for Environments in Scheme
Reply-To: jinx@zurich.ai.mit.edu
I have some problems with your proposal:
MAKE-ENVIRONMENT <id> <parent> ... [Procedure]
1) The <id> seems spurious, although harmless.
2) What is the purpose of multiple inheritance? With single
inheritance there is still the "fiction" of lexical scoping: You can
picture the new environment as appearing virtually somewhere in its
parent, but with multiple inheritance this fiction goes away.
Is the confusion warranted?
In addition to these procedures, We propose a change to the meanings of
identifiers whose names include colons:
-- No identifier may begin or end with a colon.
(Alternatively, such identifiers behave as they do now.)
-- An identifier of the form a:b1:...:bk (k >= 1) is entirely equivalent to
the expression
(ENVIRONMENT-REF a:b1:...:bk-1 'bk)
I have strong objections against read syntax:
1) What is wrong with (ACCESS a b1 b2 ... bk)? If it is too long, I'm
perfectly happy with (: a b1 b2 ... bk), which only adds 4 characters
to your proposal, and no read syntax.
2) Read syntax has the following problem:
(set! a:b:c 3)
expands into
(set! (environment-ref (environment-ref a 'b) 'c) 3)
which is not valid syntax for SET! Clearly it would be desirable if
the above expanded into
(environment-set! (environment-ref a 'b) 'c 3)
but this is no longer read syntax.
A file of Scheme code, under this proposal, may optionally begin with a piece of
syntax, called a >herald<, that arranges for special treatment of the
environmental context of the code in the file. Heralds obey the following
syntax:
(HERALD <option>+)
etc.
I think this is not very well thought out. By placing a HERALD in a
file you are making the file "absolute" rather than "relative". I
can no longer load the file into multiple environments with different
contexts except by munging the loader (to change GLOBAL, or whatever,
temporarily).
I think you would be much better off separating the contents of the
file from the definition of the system that describes and creates the
context into which the file is supposed to be loaded.
∂27-May-88 0025 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU modules
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 May 88 00:25:35 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 May 88 02:32:48 EDT
Date: Fri, 27 May 88 01:13:52 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: modules
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <386391.880527.JAR@AI.AI.MIT.EDU>
Here is my answer to Pavel's request "could you be more concrete about
the kind of system you envision?".
Rather than try to say what I think is the right thing (I don't know),
I'll simply try to describe my understanding of the essence of the ML
module system. This has been the point of departure in my own recent
ponderage of the topic of modules. This message does NOT constitute a
proposal or endorsement of its content.
The names have been changed to offend the innocent (MacQueen et al.),
and other accomodations made to a schemish worldview. Equivalent ML
constructs are given at right.
<exp> ::= (STRUCTURE <sig> <form>*) ; struct ... end
| (STRUCTURE-REF <struct> <id>) ; .
| ... the usual ...
<form> ::= <exp>
| <definition>
| (OPEN-STRUCTURE <exp> <sig>) ; open
| (DEFINE-SIGNATURE <name> <sig>) ; signature ... = ...
<sig> ::= <name>
| (SIGNATURE <id>*) ; sig ... end
A signature is a list of variable names. Signature definitions, like
macro definitions, must be known at compile time. If Scheme had a way
to write types, a signature would give types for the variables; but then
so would any binding construct, including LAMBDA, LETREC, and DEFINE; so
this is an orthogonal design issue.
A STRUCTURE-expression evaluates to a structure, which is something you
can do STRUCTURE-REF on. The values exported by a structure are given
by the signature. (A signature is like an interface decsription, and a
structure is like an implementation of that interface.) The body of a
STRUCTURE-expression looks like the top level of a file. Simple
example:
(structure-ref (structure (signature a) (define a 5))
a)
=> 5
The contents of a file that participates in the module system is
typically a single STRUCTURE expression, or a LAMBDA whose body is a
STRUCTURE (in ML, a "functor"). LOAD then returns a structure (or a
procedure that returns a structure). This being a common case, a file
syntax could be invented (analogous to T's or Pavel's HERALD) that
doesn't leave that extra parenthesis dangling until the end. The
merits of this are debatable.
(OPEN-STRUCTURE struct sig) is equivalent to a series of DEFINE forms
that transfer values from the given structure to the current
environment. E.g.
(open-structure foo (signature a b))
is equivalent to
(define a (structure-ref foo a))
(define b (structure-ref foo b))
Of course, one doesn't generally write out (SIGNATURE ...) forms in
STRUCTURE and OPEN-STRUCTURE forms, but instead does a DEFINE-SIGNATURE:
(define-signature foo-sig (signature a b))
(define foo (structure foo-sig
(open-structure bar bar-sig)
(define a ...)
(define b ...)))
Multiple definitions in the same block are in error, so in particular,
if I do
(open-structure foo foo-sig)
(open-structure bar bar-sig)
within the same STRUCTURE body, and foo-sig and bar-sig both list
an identifier a, then you lose. (For the same reason that
(lambda (x x) ...) is an error -- and by the way, the report needs to
say that it is.)
If importing is by value rather than by reference, then all of this
mechanism can be implemented using macros. (Left as an exercise. Hint:
signatures are macros.) If importing is by reference, then it can be
done in terms of two new special forms, one for getting a variable's
location (like Zetalisp LOCF or T LOCATIVE) and another for doing an
"identity declaration" (DEFINE-LOCATION var exp), which would bind var
to the value of evaluating exp, which value must be something returned
by a LOCATIVE form. Of course, more sophisticated implementations are
possible.
Features of the this module system (and ML's) that make me like it
better than Pavel's:
- It's simple: really only four new things.
- File syntax is completely equivalent to some existing expression
syntax; the existence of files is an artifact. A call to LOAD
returns the value of the expression to which the file is equivalent.
(Actually ML doesn't work quite like this, but it's close.)
- A file is considered to be an expression that yields a value, rather
than a block of code that has a side-effect on some environment. Thus
LOAD is not generally a side-effect, and does not add new bindings to
any pre-existing environment. If a client wants to get at the values,
it has to fetch them itself using STRUCTURE-REF or OPEN-STRUCTURE;
that's not the file's business.
- Similarly, it is up to the loader of a file to decide in which
environment the file is to be closed.
- It certainly does not preclude the existence of more general
first-class environments, but it treats that (and meta-tools
generally) as an orthogonal question.
- Interfaces (signatures) are described centrally, so that multiple
implementations and the clients of those implementations can all share
a single definition. This makes code more concise and easier to change
than otherwise.
Things I don't want to talk about now:
- structures resemble records (concrete vs. abstract types?)
- importing could be by reference instead of by value
- inheritance among signatures and implementations
- signatures could be first class (echoes of PROGV)
- what about interactive development & debugging
- performance questions (e.g. how to avoid lots of copying) (I think Appel
has written a paper about this)
- open-structure is too powerful
- maybe allow open-structure in other contexts, or disallow it except at
top of a structure form, or banish it altogether
- multiple "views" on a structure
- syntactic file sugar to avoid dangling parentheses
- where do macros fit in (put them in signatures?)
- system configurations
- functors
- Felleisen & Friedman '85
- etc.
I didn't promise that I was going to give constructive criticism. Maybe
if you wait a few months I'll be able to answer these concerns and
propose something I like.
∂27-May-88 0529 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: HELP ME!!!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 May 88 05:29:11 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 May 88 08:27:22 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA15079@BLOOM-BEACON.MIT.EDU>; Fri, 27 May 88 08:16:14 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 May 88 16:01:00 GMT
From: sanders@osiris.cso.uiuc.edu
Subject: Re: HELP ME!!!
Message-Id: <39400001@osiris.cso.uiuc.edu>
References: <5813@cup.portal.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
But he DID reply, in another notesfile (can't think of the name of it just now).
He said he was working 25 hours/week and going to school full time.
∂27-May-88 0628 @MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: Proposed modifications to RRRS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 May 88 06:28:49 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 27 May 88 09:07:45 EDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05547; 27 May 88 13:52 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 27 May 88 13:51:28 bst
Message-Id: <7509.8805271251@aiva.ed.ac.uk>
To: MKATZ@a.isi.edu
Subject: Re: Proposed modifications to RRRS
Cc: rrrs-authors@mc.lcs.mit.edu
> Date: Thu 26 May 88 14:27:49-EDT
> From: Morris Katz <MKATZ@edu.isi.a>
> Subject: Re: Proposed modifications to RRRS
> When one actually wants AND and OR to return the values currently specified
> instead of just being boolean predicates, there is a simple and efficient
> implementation in terms of the AND and OR semantics I advocate.
What is it?
> Lastly, I must repeat that I just don't buy the argument that language
> designers must repeat the mistakes of the past in order to maintain
> compatibility.
To call what was done in the past a mistake is begging the question.
Perhaps the problem is that AND and OR are called AND and OR, suggesting
that they really are simple boolean operations with some bogosity tacked
on.
You might try suggesting that only #t be considered true. Then AND
and OR would have to change.
-- Jeff
∂27-May-88 1422 @MC.LCS.MIT.EDU:reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu Floyd-Hoare Verification Harmful??
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 May 88 14:21:52 PDT
Received: from a.cs.uiuc.edu (TCP 1200600045) by MC.LCS.MIT.EDU 27 May 88 17:17:57 EDT
Received: from reddy.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA16183; Fri, 27 May 88 12:01:22 CDT
Received: by reddy.cs.uiuc.edu (3.2/9.7)
id AA05772; Fri, 27 May 88 12:01:36 CDT
Date: Fri, 27 May 88 12:01:36 CDT
From: reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8805271701.AA05772@reddy.cs.uiuc.edu>
To: hes@VALLECITO.SCRC.Symbolics.COM
Cc: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET,
hes@VALLECITO.SCRC.Symbolics.COM, scheme@mc.lcs.mit.edu
In-Reply-To: Howard Shrobe's message of Mon, 23 May 88 18:15 EDT <19880523221557.1.HES@MERLIN.SCRC.Symbolics.COM>
Subject: Floyd-Hoare Verification Harmful??
Reply-To: reddy@a.cs.uiuc.edu
Howard Shrobe:
Indeed the problem is that when allows arbitrary pointer and array
manipulations one can get aliasing problems. It is very hard to write
an axiom set in the Floyd-Hoare tradition that does not screw up for
such languages. There are two responses, one is to weaken the language
in such a way as to prevent aliasing. The other is to create a
different technique stating the language axioms and verifying programs.
To date, I haven't seen a proposal in either direction that seems
workable. Attempts to constrain pointer manipulation seem to constrain
more than you'd like.
Well, that depends on what you mean by "workable". The standard
technique used for handling aliasing (for example, in denotational
semantics) is a two-level store. The first level called "environment"
binds variables to objects, and the second level called "store" binds
objects to values. We then have an accurate semantic formulation, but
reasoning is harder than in Floyd-Hoare tradition. A two-level store
formulation in predicate logic style is the recent "situational
calculus" semantics of Manna and Waldinger. It remains to be seen how
nice reasoning looks like in this framework.
Another technique, attributed to Landin, is to use an "equivalence
relation" on variables. Modifying any variable in an equivalence
class has the effect of modifying all the variables in the class.
Reasoning seems to be nicer in this framework. But, one has to be
careful about the order of evaluation. A version of the Church-Rosser
property gets lost when aliasing is introduced.
Uday Reddy
∂27-May-88 1614 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Miranda (functional programming system)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 May 88 16:13:59 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 May 88 19:12:39 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA05440@BLOOM-BEACON.MIT.EDU>; Fri, 27 May 88 18:58:49 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 May 88 18:05:45 GMT
From: eagle!dat@bloom-beacon.mit.edu (D.A.Turner)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Subject: Miranda (functional programming system)
Message-Id: <5107@eagle.ukc.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Miranda - release one
---------------------
Miranda is a very pure functional language designed by Professor David
Turner of the University of Kent. It has polymorphic strong typing and
a simple but powerful module system. This is to inform anyone who may
be interested that the first full release of the Miranda functional
programming system is now available for a number of UNIX machines,
including VAX's and SUN's. If you wish to receive a longer piece of
electronic mail telling you more about the Miranda system and how to
obtain it, this can be requested from
USENET: ...!mcvax!ukc!mira-request
ARPANET: mira-request@ukc%nss.cs.ucl.ac.uk
JANET: mira-request@ukc.ac.uk
∂30-May-88 1727 @MC.LCS.MIT.EDU:amgreene@athena.MIT.EDU PLEASE remove me from this list
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 May 88 17:27:36 PDT
Received: from CHARON.MIT.EDU (TCP 2224000015) by MC.LCS.MIT.EDU 29 May 88 23:28:11 EDT
Received: by CHARON.MIT.EDU (5.45/4.7)
id AA07377; Sun, 29 May 88 23:25:06 EDT
Date: Sun, 29 May 88 23:25:06 EDT
From: <amgreene@athena.MIT.EDU>
Message-Id: <8805300325.AA07377@CHARON.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: PLEASE remove me from this list
I'm sorry to send this to the whole list, but I sent to scheme-request
and I'm still on. I won't be here this summer and *really* can't afford
to have lots of mail pile up. Thanks again.
- Andrew Greene
∂31-May-88 0901 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu collect special form for streams
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 May 88 09:01:17 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 May 88 11:27:30 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA02567@BLOOM-BEACON.MIT.EDU>; Tue, 31 May 88 11:14:49 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 May 88 04:07:26 GMT
From: gt-eedsp!schw@gatech.edu (Dave Schwartz)
Organization: School of Electrical Engineering, Ga. Tech, Atlanta, GA 30332
Subject: collect special form for streams
Message-Id: <294@gt-eedsp.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Any help you can provide would be appreciated ...
How can the "collect" special form for streams (from Chap. 3 of
Structure and Interpretation of Computer Programs) be implemented for
TI PC-Scheme? I have Kent Dybvig's "extend-syntax," but this does not
appear to be powerful enough for this special form.
__ ()
/ ) / /\ / _/_
/ / __. , __o __/ / ) _. /_ , , , __. __ / __.
/__/_(_/|_\/ <__(_/_ /__/__(__/ /_(_(_/_(_/|_/ (_<__/ |_
(|
-------------------------------------------------------------
uucp: schw@gt-eedsp.uucp
domainizing internet mailers: schw@gteedsp.gatech.edu
dumb internet mailers: schw%gteedsp@gatech.gatech.edu
∂31-May-88 1340 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:C24880RL@WUVMD.BITNET Request for information
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 May 88 13:40:33 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 31 May 88 12:51:57 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0796; Tue, 31 May 88 09:25:45 EDT
Received: from WUVMD.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
0795; Tue, 31 May 88 08:13:06 EDT
Received: by WUVMD (Mailer X1.25) id 4630; Mon, 30 May 88 14:44:34 CST
Date: Mon, 30 May 88 14:40:51 CST
From: Ronald Lovett <C24880RL%WUVMD.BITNET@MITVMA.MIT.EDU>
Subject: Request for information
To: SCHEME@MC.LCS.MIT.EDU
Do you have a list of available SCHEME software?
I am interested in installing SCHEME on local lab computers. The two
closest to me are based on Motorola 6809 and Motorola 68020 processors
and we have C language software on these machines.
∂31-May-88 2124 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Macros in lexically scoped lisps
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 May 88 21:23:58 PDT
Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 31 May 88 22:46:15 EDT
Date: 31 May 88 09:01:50 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: SCHEME@MC.LCS.MIT.EDU
Message-Id: <053188.090151.alberga@ibm.com>
Subject: Macros in lexically scoped lisps
No, that is not the only way macros work in lexically scoped lisps. In LISP/VM
they work pretty much as you would expect, execpt sometimes.
Quick aside: LISP/VM uses a single value cell, a la SCHEME. It support
dynamic (FLUID) bindings, in the same binding contour as lexical bindings.
It has an operator, STATE, which can be used to duplicate CALL/CC. Macros
are first-class objects, written as (MLAMBDA ...). The scope rules for
macros are identical to those of functions.
The trouble is, this makes compilation hard. LISP/VM cheats. The compiler
is presented with two environments. One is used to resolve operators, the
other to apply macros. The first allows the compiler to receive macro
definitions which differ from the run-time definitions. For example, compiled
calls to functions with fixed numbers of arguments is faster than calls with
indefinite trailing arguments. On the other hand, macros may not be applied
(unlike FRANZ-LISP). Thus the run-time environment has a function, PLUS, which
takes indefinite numbers of arguments, while the compiler has a macro, PLUS,
which expands to nested calls to internal-PLUS, a two argument function.
The conceit is that compiler/interpreter equivalence only holds AFTER the
macro expansion phase of the compilation process. It turns out that in
most cases this causes not trouble. Since there are both EVAL and APPLY
operators, and since they accept environments, all lexical variables are
accessible to mixed compiled and interpreted code. (I know this is a
violation of lexicality, but it seemed like the lesser of many evils.)
I should comment that in LISP/VM thinks are a bit more complex. This is
because no operator is examined before evaluation. Thus a function is
not a list with first element LAMBDA, but a list whose first element
evaluates to LAMBDA. The problems arise when an operator evaluates
to (FOO ...), and then FOO evaluates to MLAMBDA. The currently defined
semantics in LISP/VM seem to cause minimal astonishment, but they are
still a bit too baroque for my taste. Trouble is, no-one has suggested better.
Yours,
Cyril N. Alberga
∂31-May-88 2206 @MC.LCS.MIT.EDU:howell%community-chest.mitre.org@gateway.mitre.org Miranda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 May 88 22:06:21 PDT
Received: from gateway.mitre.org (TCP 1200200157) by MC.LCS.MIT.EDU 1 Jun 88 00:05:51 EDT
Received: by gateway.mitre.org (5.54/SMI-2.2)
id AA05908; Tue, 31 May 88 15:26:59 EDT
Return-Path: <howell%community-chest.mitre.org@gateway.mitre.org>
Received: by boardwalk.mitre.org (3.2/SMI-2.2)
id AA01271; Tue, 31 May 88 15:26:35 EDT
From: howell%community-chest.mitre.org@gateway.mitre.org
Message-Id: <8805311926.AA01271@boardwalk.mitre.org>
To: scheme@mc.lcs.mit.edu
Cc: howell@mitre.ARPA
Subject: Miranda
Date: Tue, 31 May 88 15:26:33 -0400
An announcement of an implementation of Miranda was recently posted to
this mailing list; I apologize for sending this to the entire list, but I
deleted that mail message inadvertantly before I had a chance to respond.
If someone would re-post it to me, I'd appreciate it.
Thanks,
Chuck Howell
The MITRE Corporation, Mail Stop Z645
7525 Colshire Drive, McLean, VA 22102
NET: howell@mitre.arpa or
howell%community-chest.mitre.org@gateway.mitre.org
∂01-Jun-88 0016 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 00:16:25 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Jun 88 01:42:52 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA14590@BLOOM-BEACON.MIT.EDU>; Tue, 31 May 88 20:11:02 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 May 88 21:01:46 GMT
From: tness7!killer!pollux!ti-csl!mips!gateley@bellcore.bellcore.com (John Gateley)
Organization: TI Computer Science Center, Dallas
Subject: Re: collect special form for streams
Message-Id: <50472@ti-csl.CSNET>
References: <294@gt-eedsp.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <294@gt-eedsp.UUCP> schw@gt-eedsp.UUCP (Dave Schwartz) writes:
>How can the "collect" special form for streams (from Chap. 3 of
>Structure and Interpretation of Computer Programs) be implemented for
>TI PC-Scheme? I have Kent Dybvig's "extend-syntax," but this does not
>appear to be powerful enough for this special form.
Extend-syntax's pattern matching is not powerful enough to do this.
You have to use the "with" feature to generate the v functions. (by calling
a function which builds them, i.e. you do them by hand). I also used a
help macro to make the flatmap parts of the expression (watch out for
keywords). If this is not enough help, email me and I will send you my code.
John Gateley
gateley@tilde.csc.ti.com
∂01-Jun-88 1417 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 14:17:49 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 1 Jun 88 17:12:56 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA06718@BLOOM-BEACON.MIT.EDU>; Wed, 1 Jun 88 16:59:06 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Jun 88 19:09:26 GMT
From: leto!matthias@rice.edu (Matthias Felleisen)
Organization: Rice University, Houston
Subject: Re: collect special form for streams
Message-Id: <748@thalia.rice.edu>
References: <294@gt-eedsp.UUCP>, <50472@ti-csl.CSNET>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <50472@ti-csl.CSNET> gateley@mips.UUCP (John Gateley) writes:
>In article <294@gt-eedsp.UUCP> schw@gt-eedsp.UUCP (Dave Schwartz) writes:
>>How can the "collect" special form for streams (from Chap. 3 of
>>Structure and Interpretation of Computer Programs) be implemented for
>>TI PC-Scheme? I have Kent Dybvig's "extend-syntax," but this does not
>>appear to be powerful enough for this special form.
>
>Extend-syntax's pattern matching is not powerful enough to do this.
>You have to use the "with" feature to generate the v functions. (by calling
>a function which builds them, i.e. you do them by hand). I also used a
>help macro to make the flatmap parts of the expression (watch out for
>keywords). If this is not enough help, email me and I will send you my code.
>
>John Gateley
>gateley@tilde.csc.ti.com
John, what do you think of this one?
(syntax
(collect <result> ((<v1> <set1>) ...) <restriction>)
(map (lambda (tuple)
(help-res (<v1> ...) <result>))
(filter (lambda (tuple)
(help-res (<v1> ...) <restirction>))
(flat-help ((<v1> <set1>) ...) (list <v1> ...)))))
(extend-syntax (help-res)
[(help-res (<v1> <v2> ...) <res>)
(let ((<v1> (car tuple)) (tuple (cdr tuple)))
(help-res (<v2> ...) <res>))]
[(help-res () <res>) <res>])
(extend-syntax (flat-help)
[(flat-help ((<v1> <set1>) (<v2> <set2>) (<v3> <set3>) ...) last)
(flatmap (lambda (<v1>)
(flat-help ((<v2> <set2>) (<v3> <set3>) ...) last))
<set1>)]
[(flat-help ((<v1> <set1>)) last)
(map (lambda (<v1>) last) <set1>)])
-- Matthias
P.S. Eugene Kohlbecker invented extend-syntax.
∂01-Jun-88 1525 @MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU Bug in R3RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 15:25:25 PDT
Received: from A.ISI.EDU (TCP 3200600147) by MC.LCS.MIT.EDU 1 Jun 88 18:08:41 EDT
Date: Wed 1 Jun 88 18:06:28-EDT
From: Morris Katz <MKATZ@A.ISI.EDU>
Subject: Bug in R3RS
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12403060549.22.MKATZ@A.ISI.EDU>
I believe there is a bug in the R3RS specification of SET! (p. 8). It says that
"<Variable> must be bound in some region enclosing the SET! expression or at
top level." I believe that the reference to "top level" is either superfluos
or in error. If the top level environment is a lexically enclosing environment
then the reference is superfluos, and if the "top level" environment is not
lexically apparent (I am not even sure if this is possible given the current
environment semantics.) then it is presumably in error. This definition
becomes particularly onerous if we adopt some form of first-class environments
as then there is a distinct possibility that a SET! could be performed in an
environment that is not a child of "the top level" environment. I therefore
propose substituing the following wording for the above sentence:
"<Variable> must be bound in an enclosing lexical environment." Obviously,
adoption of first-class environments with multiple parents would require
yet further refinement of this sentence.
Morry Katz
-------
∂01-Jun-88 1925 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 19:20:27 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Jun 88 22:18:37 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 88 19:14:58 PDT
Date: Wed, 1 Jun 88 19:14:38 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <386085.880526.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880601-191458-6217@Xerox>
This looks fine modulo a couple of questions:
1 -- Why does the ``type-id'' argument have to be a symbol? I could well
imagine wanting a name like "Compiled Function", which is a pain to have to
translate into a symbol first.
2 -- The point came up here that it would be useful to have a procedure that,
given any Scheme value, returns an object in some way representing the ``type''
of that object. If two values have the same ``type'', then this hypothetical
procedure would return EQL objects on the two values. This sort of thing would
be useful for packages that want to allow ``registration'' by clients of
type-specific operations. The registration mechanism would associate an
operation with a ``type-object'' in some table. When it came time to apply the
generic operation to a value, the type-object for the value would be mapped to
the type-specific operation, which could then be applied.
Of course, for some of the built-in types there are problems with this. For
example, do 3 and #i3 return the same ``type-object''? I think that there are
reasonable choices that can be made for such questions.
In essence, we'd be interested in a facility like the TYPEP and TYPE-OF
functions of Common Lisp but without the issue of type names.
Of course, an obvious choice for the ``type-object'' would be the ``record
type'' objects in your proposal, but, as you say, mapping from objects to their
``record type'' objects is an abstraction-breaker.
Pavel
∂01-Jun-88 1943 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jun 88 19:43:42 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Jun 88 22:42:45 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 88 19:40:30 PDT
Date: Wed, 1 Jun 88 19:40:22 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <386085.880526.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880601-194031-6239@Xerox>
Of course, I forgot to mention my most important issue about this proposal:
inheritance. I don't see any worm cans surrounding a single-inheritance
facility. It's simple (all other possibilities have this as a special case, all
with the same semantics), useful (especially for the definition of an error
system) and easily extendable to some hairy multiple-inheritance setup if that's
found desirable in the future.
I strongly support the inclusion of single-inheritance in the facility.
Pavel
∂02-Jun-88 1252 @MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Jun 88 12:52:06 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Jun 88 15:51:28 EDT
Received: from RTS-10.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Jun 88 14:24-EDT
Message-Id: <2790267567-12470112@RTS-10>
Sender: JRL@RTS-10
Date: Thu, 2 Jun 88 14:19:27 EDT
From: Juan Loaiza <jrl@ZERMATT>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: A Proposal for Environments in Scheme
In-Reply-To: Msg of Fri, 20 May 88 11:49:26 PDT from Pavel.pa@Xerox.COM
This is a reply to Pavel's message of almost two weeks ago proposing the
use of first class environments to define modules. Sorry to take so long
replying, my mailbox runeth over...
Overall, I think that the idea of trying to standardize the environment
manipulation functions across the implementations that support them is a good
idea, although I am not sure that this belongs in the definition of the language.
However, after having spent a good deal of time lately thinking about modules, I
have come to the conclusion that implementing them using first class
environments directly is probably not the right thing.
First some comments on the proposal:
MAKE-ENVIRONMENT <id> <parent> ... [Procedure]
Unrestricted multiple inheritence is a TERRIBLE idea. It breaks just about
every tenet of modularity that I can think of. Inheriting from two parent
environments creates a dependence between the two parents where none previously
existed. Making a safe change to either of the parents now requires detailed
knowledge of the other parent. The presence of multiple inheritence encourages
the building of "brittle" systems, whereas a good module system should encourage
the building of robust systems.
In addition to these procedures, We propose a change to the meanings of
identifiers whose names include colons:
Using qualified names as you advocate tends to decrease the modularity of
systems by wiring in a particular organization of modules. A qualified name
such as MATH:SQRT specifies both that you want a square root function and that
you want if from the MATH module. Most of the time you would like to specify
that you want a square root function and you don't care where it comes from. The
place it comes from should be specified separately. Also, it is impossible to
abstract over, or shadow a qualified name.
THE SYNTAX AND SEMANTICS OF FILES
I share JINX's reservations about making files "absolute" rather than
"relative". As a general rule I believe that all "global" or "absolute"
constructs are unmodular (with the possible exception of symbols).
THE INITIAL ENVIRONMENT STRUCTURE
I think this is on the right track but I would like to see the procedures
related to each data type in their own separate modules. For example, there
should be a separate module that defines the vector operations. This is very
subjective though.
(EXPORT <expression> <export-spec>+)
I don't understand something here. If I export a variable X into an environment
E, does X act as if it was directly defined in E, or does it act as if it was
inherited by E? In other words, what happens if I now DEFINE X in E? Is a new
X created, or is the other one set!.
Again I beleive that the EXPORT form is basically unmodular. It specifies both
that a value is produced by this module, and where this value should be put.
As a concrete example of where this type of thing hurts you, suppose that an
environment had become trashed and I wished to re-create it from scratch. I
would like to throw away the old environment, create a new one, and load into it
the file(s) that define the contents of the environent. However, in order to
get the values that were exported into the environment, I must also load all the
files that exported into it. This is likely to cause totally unrelated values
to be reloaded, possibly causing even more trouble.
Overall, I think that first class environments have their place, but the style
of modularization they encourage has some problems. The kind of module system I
would like to see separately specifies: (1) what values a module needs, (2)
where those values come from, (3) what values a module produces, and (4) where
those values go. A construct with these properties already exists in Scheme in
the form of procedures. Consider this procedure:
(lambda (sqrt draw-line)
(define (foo) ...)
(define (bar) ...)
(list foo bar))
This "imports" two values (sqrt and draw-line) and "exports" two values (foo and
bar). What values actually get imported is determined by the combination the
function is applied in. What is done with those values is determined by what is
done with the values returned by the combination. The "module" defines a
behavior that can be instantiated many times with different values imported and
exported each time.
I am in the process of designing a module system that is based on using
procedures as modules, but that tries to avoid some of the pitfalls of doing so.
For example, it tries to avoid specifying large numbers of inputs and outputs
positionally since doing so tends to be tricky and error prone. I have run into
some difficult issues that need to be resolved, but I hope to have a detailed
description ready in a couple of months. The system I have in mind is somewhat
similar to the ML module system that Jonathan described.
The point I would like to emphasize is that a good module system should
encourage and facilitate a "clean" and "modular" style of programming.
Unfortunately, this can get pretty subjective so there may never be one system
that pleases everyone.
I hope you find these comments thought provoking and look forward to your reply.
∂03-Jun-88 0738 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET Oaklisp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 07:38:31 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 3 Jun 88 10:35:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2475; Fri, 03 Jun 88 10:32:23 EDT
Received: from FRSAC11.BITNET (NETWORK) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 2474; Fri, 03 Jun 88 10:32:21 EDT
Date: Fri, 03 Jun 88 16:29:43 GMT
To: scheme@mc.lcs.MIT.EDU
From: NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU
Comment: CROSSNET mail via MAILER@MITVMA
Subject: Oaklisp
Date: 3 June 1988, 16:26:54 GMT
From: NETWORK at FRSAC11
To: SCHEME at MC.LCS
Did anybody succeed in porting OAK to System V ?
Or to an other cpu than sun/VAX/rt ?
I tried hard with the March and May release and cant have the thing
run. (Compile quite OK. quite)
Jean-Pierre H. Dumas
network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)
∂03-Jun-88 1114 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 11:14:48 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Jun 88 14:00:55 EDT
Date: Fri, 3 Jun 88 14:00:03 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: opaque type proposal
To: Pavel.pa@XEROX.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 1 Jun 88 19:40:22 PDT from Pavel.pa@Xerox.COM
Message-ID: <391255.880603.JAR@AI.AI.MIT.EDU>
Date: Wed, 1 Jun 88 19:40:22 PDT
From: Pavel.pa@Xerox.COM
Of course, I forgot to mention my most important issue about this
proposal: inheritance. I don't see any worm cans surrounding a
single-inheritance facility. It's simple (all other possibilities
have this as a special case, all with the same semantics), useful
(especially for the definition of an error system) and easily
extendable to some hairy multiple-inheritance setup if that's found
desirable in the future.
I see that nobody takes anything I say on faith. OK, here are two problems:
- Single inheritance makes type checking and predication of inheritable-from
record types slow. It is no longer possible to simply compare a slot in
the record against a descriptor representing "the" expected type of the
record, since there is no longer a single possible expected type, but
rather a set of them.
I would favor addressing this by providing a way of optionally
specifying that a record type cannot be subtyped; this could be realized
as a boolean argument to MAKE-RECORD-TYPE. This vaguely corresponds to
the construct in the Larch specification language where one declares
that a sort (?) is "generated by" a given set of constructors. E.g. the
natural numbers are generated by zero and successor; there ain't any
others.
- It's no longer clear what constructor procedures should do. If the
constructor for the subtype takes initial values for all the fields,
including those of the supertype, then you have a serious modularity
violation -- changes to the implementation of the supertype require
changes to the implementation of every subtype. I don't know how to fix
this, although I imagine there exists some solution involving passing
control between constructors, perhaps using continuations. It would be
nice if records could be constructed without either copying an instance
of the parent type (as would happen if the new fields were adjoined --
assuming records are stored linearly in memory, and slots are mutable,
both of which seem important) or side-affecting slots (as would happen
if the larger record were created first, and the slots filled in
separately by procedures handling each layer).
We could probably argue of months about these issues, but I wanted to
avoid that for now.
∂03-Jun-88 1227 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 12:27:40 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 3 Jun 88 15:10:22 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 88 12:00:18 PDT
Date: Fri, 3 Jun 88 12:00:10 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <391255.880603.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880603-120018-2487@Xerox>
I don't consider either of Jonathan's two problems with single-inheritance to be
significant. Here's why.
The claim is that single inheritance makes type-checking and predication slow.
I dispute this. Certainly if you insist that, say, the first slot of every
opaque object should contain the special value identifying elements of its type,
then yes, indeed, you will have to check for several values. However, this is
not necessarily so. Consider this set of definitions:
(define one (make-record-type 'one '(a b)))
(define two (make-record-type 'two '(c d) one))
; two inherits from one
(define three (make-record-type 'three '(e f) two))
; three inherits from two
Then I would expect to see the predicates for these types written as
(define (one? x)
(and (record? x)
(>= (record-length x) 3)
(eq? (record-ref x 0) one-tag)))
(define (two? x)
(and (record? x)
(>= (record-length x) 6)
(eq? (record-ref x 3) two-tag)))
(define (three? x)
(and (record? x)
(>= (record-length x) 9)
(eq? (record-ref x 6) three-tag)))
Clearly, the result of
((record-constructor three) 1 2 3 4 5 6)
would be a length 9 record like this:
Slot Slot
Index Value
----- -----
0 one-tag
1 1 ; value for the A slot
2 2 ; value for the B slot
3 two-tag
4 3 ; value for the C slot
5 4 ; value for the D slot
6 three-tag
7 5 ; value for the E slot
8 6 ; value for the F slot
Using this representation, no operation takes other than constant time or,
indeed, any longer than it would without any inheritance at all.
I thus conclude that single inheritance is not inefficient.
Jonathan's other problem was that constructor procedures are no non-modular.
This is only true to the extent that modules export their record-type objects to
the outside world. The major uses for inheritance that I have in mind do not
involve cross-module use of record-type objects. I claim that this
non-modularity is exactly as much a problem as for any other exported value; if
I change the number of arguments required for some exported procedure, I have
just the same kind and degree of problem as when I change the number of slots in
an exported record-type object.
I thus conclude that the modularity problem is not specific to opaque types thus
should not be an issue in this discussion.
Pavel
∂03-Jun-88 1650 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: collect special form for streams
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 16:50:26 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Jun 88 19:44:11 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA10836@BLOOM-BEACON.MIT.EDU>; Fri, 3 Jun 88 19:39:46 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Jun 88 19:23:56 GMT
From: killer!pollux!ti-csl!mips!gateley@ames.arpa (John Gateley)
Organization: TI Computer Science Center, Dallas
Subject: Re: collect special form for streams
Message-Id: <50694@ti-csl.CSNET>
References: <294@gt-eedsp.UUCP>, <50472@ti-csl.CSNET>, <748@thalia.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <748@thalia.rice.edu> matthias@rice.edu (Matthias Felleisen) writes:
>In article <50472@ti-csl.CSNET> gateley@mips.UUCP (John Gateley) writes:
>>In article <294@gt-eedsp.UUCP> schw@gt-eedsp.UUCP (Dave Schwartz) writes:
>>>How can the "collect" special form for streams (from Chap. 3 of
>>>[...]
>>Extend-syntax's pattern matching is not powerful enough to do this.
>>[...]
>John, what do you think of this one?
>[Matthias's code deleted]
>
>P.S. Eugene Kohlbecker invented extend-syntax.
Hi Matthias,
As usual you are right and I am wrong. Let me rephrase it a bit:
Extend-syntax is not powerful enough to do it without using help
macros. I can generate the (car (cdr (... tuple))) pattern without
using 'with' or your rebinding of tuple, but I dont think that it
can be done as part of the collect macro without actually changing
the definition of collect. I dont want to rebind tuple because it
changes the pattern matching part of the problem. If you change the
definition, then I think you can do it. Can you prove me wrong this
time?
John
∂03-Jun-88 1726 @MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 17:26:06 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 3 Jun 88 20:00:49 EDT
Received: from RTS-10.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 88 20:01-EDT
Message-Id: <2790374204-2361923@RTS-10>
Sender: JRL@RTS-10
Date: Fri, 3 Jun 88 19:56:44 EDT
From: Juan Loaiza <jrl@ZERMATT>
To: Pavel.pa@Xerox.COM
Cc: Jonathan A Rees <JAR@AI.AI.MIT.EDU>,
rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: opaque type proposal
In-Reply-To: Msg of Fri, 3 Jun 88 12:00:10 PDT from Pavel.pa@Xerox.COM
I think the opaque type proposal is excellent, and is sorely needed in order for
Scheme to become a language with real abstract data types.
However, I object to the fact that the constructor for a record initializes all
the fields of the record. This is:
1) An unnecessary bundling of functionality.
2) An annoyance for large structures.
3) Inefficient if bogus values must be specified in the case where the
programmer does not care, especially for large structures.
4) Eliminates possible error checking of uninitialized fields.
An alternative is to have the RECORD-CONSTRUCTOR function take a list of fields
that the constructor it returns should initialize. For example:
(define yow-record-type (make-record-type 'yow '(a b c)))
;;; This one initializes all three fields, as before.
(define yow-constructor (record-constructor yow-record-type '(a b c)))
;;; This one only initializes A and B. B is the first argument to the function.
;;; A is the second.
(define yow-constructor-no-c (record-constructor yow-record-type '(b a)))
Also, one comment on Pavel's implementation of single inheritence. The check of
the length of the record can be eliminated by consing a new object to represent
the type of the record, and maintaining the invariant that this newly consed
object only ever appears in a record of that type. Taking Pavel's example:
((record-constructor three) 1 2 3 4 5 6)
would be a length 9 record like this:
Slot Slot
Index Value
----- -----
0 one-tag
1 1 ; value for the A slot
2 2 ; value for the B slot
3 two-tag
4 3 ; value for the C slot
5 4 ; value for the D slot
6 three-tag
7 5 ; value for the E slot
8 6 ; value for the F slot
TWO-TAG would be a newly consed object that is only ever present in the heap as
the third slot of a record of type TWO-TAG (note this implies that TWO-TAG could
not be the "record-type" since that is a first class object). Now to check
whether a record is of type TWO-TAG, one need only check to see if its third
slot is EQ to TWO-TAG. Implementing this is somewhat tricky, but definitely
possible.
∂03-Jun-88 1741 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 17:41:49 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 3 Jun 88 20:37:47 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 88 17:28:22 PDT
Date: Fri, 3 Jun 88 17:28:02 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <2790374204-2361923@RTS-10>
To: Juan Loaiza <jrl@ZERMATT.LCS.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880603-172822-3100@Xerox>
You still need the length check in order to make sure that the slot containing
the ``tag'' object actually exists before trying to fetch its value.
Pavel
∂03-Jun-88 2338 @MC.LCS.MIT.EDU:jrl@VX.LCS.MIT.EDU Re: Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jun 88 23:38:08 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 JUN 88 00:21:06 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA01142@VX.LCS.MIT.EDU>; Sat, 4 Jun 88 00:20:23 edt
Date: Sat, 4 Jun 88 00:20:23 edt
From: Juan Loaiza <jrl@VX.LCS.MIT.EDU>
To: pavel.pa@xerox.com
Subject: Re: Re: opaque type proposal
Cc: rrrs-authors@mc.lcs.mit.edu
You still need the length check in order to make sure that the slot containing
the ``tag'' object actually exists before trying to fetch its value.
Pavel
Think again about the trick I mentioned. It is a dirty, underhanded,
shameful, slimy trick; but I think it works. If a token for a type T
is only ever present in the N'th slot of an object of type T, then
looking at the N'th slot of any other object will never get you that
token. It does not matter how many slots the other object has. If it
has less than N slots you, will get a random slot out of another
object, but never the N'th slot (assuming no objects have zero
length).
For our young listeners out there, please don't try this trick at home.
∂04-Jun-88 0132 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU sleazoid programming
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jun 88 01:32:37 PDT
Received: from acf3.NYU.EDU (TCP 20036500015) by MC.LCS.MIT.EDU 4 Jun 88 04:01:59 EDT
Received: by acf3.NYU.EDU (5.54/25-eef)
id AA29747; Sat, 4 Jun 88 03:59:52 EDT
Date: Sat, 4 Jun 88 03:59:52 EDT
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Message-Id: <8806040759.AA29747@acf3.NYU.EDU>
To: jrl@VX.LCS.MIT.EDU, pavel.pa@xerox.com
Subject: sleazoid programming
Cc: rrrs-authors@mc.lcs.mit.edu
Date: Sat, 4 Jun 88 00:20:23 edt
From: Juan Loaiza <jrl@VX.LCS.MIT.EDU>
To: pavel.pa@xerox.com
Subject: Re: Re: opaque type proposal
Cc: rrrs-authors@mc.lcs.mit.edu
If it has less than N slots you, will get a random slot out of another
object, but never the N'th slot (assuming no objects have zero length).
Or you may get a slice of object code or of a string that by a one-in-a-billion
chance looks just like the tag you're looking for. Your approach depends on a
lack of local heterogeneity in the heap (e.g. BIBOP).
Eric
∂04-Jun-88 0850 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jun 88 08:50:51 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Jun 88 11:44:57 EDT
Date: Sat, 4 Jun 88 11:44:22 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: opaque type proposal
To: Pavel.pa@XEROX.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 3 Jun 88 12:00:10 PDT from Pavel.pa@Xerox.COM
Message-ID: <391856.880604.JAR@AI.AI.MIT.EDU>
OK, I think I buy your arguments for single inheritance. So how about
this: MAKE-RECORD-TYPE takes as an additional argument a descriptor for
the parent type, or #f if there is to be none.
About the identification argument to MAKE-RECORD-TYPE, the reason I
suggested it be a symbol was just to avoid overspecification: objects of
other types could mean different things. E.g. at some point that
argument could (upward-compatibly) become some kind of handler procedure
for the record type.
The identification argument should probably be optional, or perhaps not
exist at all. I don't know.
By the way, the object returned by MAKE-RECORD-TYPE ought to be called a
"record type descriptor", or anything other than "record type". Calling
any object a "type" would be a bad precedent and would frustrate the
efforts of those using Scheme for teaching and designing statically
typed languages.
I would oppose anything resembling TYPE-OF, since whenever you have
subtyping or polymorphism, there's no such thing as THE type of an
object. I don't see why it would be useful either, since you can always
put type-specific information (like generic operation handlers)
somewhere else; e.g. in the case of records, you can put it in the type
descriptor.
∂04-Jun-88 1236 ALAN@MC.LCS.MIT.EDU opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jun 88 12:36:44 PDT
Date: Sat, 4 Jun 88 15:36:24 EDT
From: Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Subject: opaque type proposal
To: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-ID: <431132.880604.ALAN@MC.LCS.MIT.EDU>
I'm still worried about letting inheritance slip into the opaque type
proposal. It's not that I see any problem with Pavel's extension (I
don't), it's that I am worried that by deciding now on a semantics for
single inheritance we reduce our options if it ever becomes clear how
multiple inheritance should work. I confess I don't have a good example of
how it might get us in trouble, but the transition from single to multiple
inheritance is such a hot topic these days that I don't think any of us can
really be certain where it might take us.
∂06-Jun-88 1151 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jun 88 11:51:02 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 Jun 88 14:47:52 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 JUN 88 11:39:18 PDT
Date: Mon, 6 Jun 88 11:39:06 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <391856.880604.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>, Alan Bawden <ALAN@MC.LCS.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880606-113918-5026@Xerox>
I suppose that the idea of using the <id> argument upward-compatibly for a
handler procedure isn't too bad, so I guess I favor restricting the argument for
now, but let's restrict it to a string rather than a symbol; symbols have a
distinct purpose, providing unique representatives of certain names, while
strings are better suited to this job. Actually, I don't care very much about
this.
I agree that ``record type descriptor'' is better than ``record type'' for the
reasons Jonathan puts forward.
Jonathan says, ``I would oppose anything resembling TYPE-OF, since whenever you
have subtyping or polymorphism, there's no such thing as THE type of an object.
I don't see why it would be useful either, since you can always put
type-specific information (like generic operation handlers) somewhere else; e.g.
in the case of records, you can put it in the type descriptor.''
I understand that ``THE type'' is not well-defined, but it is possible to define
a particular structure of type ``names'' such that every object has a
most-precise name in that space. For example, having only one type-name for all
procedures effectively dodges the problem of polymorphism.
As for the idea of putting the type-specific information in the type descriptor,
this is something that only the implementation can do, not a specific user.
I think that a reasonable choice for type names is predicate procedures.
Suppose that RECORD-PREDICATE was required to always return the same, EQV?
procedure. Then for each object, there would be a unique most-discriminating
predicate defined by the language. Some procedure, perhaps called something
like VALUE-TYPE-PREDICATE, would map all objects into their distinguished type
predicates.
I don't see anything ill-defined or modularity-breaking in any of this.
Comments?
Alan is concerned that allowing single inheritance now might be a hinderance
later if we decide to extend to multiple-inheritance. I don't claim to be a big
expert, but it seems to me that all of the multiple-inheritance facilities that
I've seen have precisely the same simple single-inheritance semantics as a
special case. Alan (or anyone else), do you know of any exceptions to this? If
not, then I would think that we were fairly safe in going this far (and no
more).
Pavel
∂06-Jun-88 1904 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU report sources
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jun 88 19:04:13 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Jun 88 22:03:45 EDT
Date: Mon, 6 Jun 88 22:03:25 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: report sources
To: hieb@IUVAX.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <392964.880606.JAR@AI.AI.MIT.EDU>
Date: Mon, 6 Jun 88 15:32:20 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: JAR@mc.lcs.mit.edu
Re: rrrs latex formats
You mentioned you would make the rrrs source available via ftp.
Have you got around to it?
We have some proposals we would like to tex up in proper format.
thanks, bob hieb
The sources are in
ZURICH.AI.MIT.EDU: /u/jar/r4rs
Tar (Unix "tape archive") format files are in
ZURICH.AI.MIT.EDU: /u/jar/r4rs.tar
PREP.AI.MIT.EDU: /u/jar/r4rs.tar
Anonymous login works with PREP's FTP server; I don't know about zurich,
but I don't think so. If you can't use tar format, let me know and put
the un-tarred files on PREP as well.
Have fun.
∂06-Jun-88 1935 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: A Proposal for Environments in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jun 88 19:35:39 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 Jun 88 22:35:11 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUN 88 17:49:41 PDT
Date: Mon, 6 Jun 88 17:49:19 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: A Proposal for Environments in Scheme
In-reply-to: <2790267567-12470112@RTS-10>
To: jrl@zermatt.lcs.mit.edu, jinx@chamartin.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880606-174941-5967@Xerox>
This is my response to comments made by Jinx and Juan. I will try to simply
respond to their comments in this message; under separate cover I hope to send
out a more general message about module facilities.
Jinx asked whether or not the confusion generated by multiple inheritance (in
particular, the loss of the illusion of lexical scoping) is worthwhile. Juan
correctly points out that this can be a modularity problem. I believe that
there are circumstances in which the ability to share some names transparently
between compilation units is useful and desirable. For example, suppose that
the implementation of a particular interface is quite large, comprising more
than one compilation unit. It is awkward and, I contend, unreasonable to insist
that code in one compilation unit must explicitly reference through the
interface those items that are provided by a different compilation unit (I am
assuming here that such code can refer to items in the same compilation unit
without going through the interface). Here is an illustration:
Interface `Foo', a list of names:
A
B
C
Implementation of `Foo' (compilation unit one):
(define A
...
reference to B
...
reference to C
...
reference to X
...)
(define B
...)
(define X ; an item private to this compilation unit
...)
Implementation of `Foo' (compilation unit two):
(define C
...)
(define Y ; an item private to this compilation unit
...)
I hope that no one would disagree that the reference to B in A should look any
different from the reference to X; that is, both are in the same scope as A and
so should be referenced transparently. I would like to argue that references to
B and C could also be similar, by virtue of their shared presence in the
interface. Naturally, A cannot refer to Y, since it is neither in the same
compilation unit nor exported to the interface.
Consider the environment in which compilation unit one should be evaluated. I
would like (in some cases) for its environment to inherit both from the normal
language environment and from the environment represented by the interface. One
way to get this would be to have the interface environment inherit from the
language environment. This has the problem that the interface now ``contains''
too many names, more than the abstraction supports. The only alternative is
multiple inheritance.
----------
Jinx has strong objections against read syntax and so does not like our ideas
for structured identifiers. As far as I can tell, his difficulty is that
expressions like
(set! a:b:c 17)
look like they should work, but they don't. A simple response to this objection
is that perhaps such expressions should be defined to work. Another response is
to remove the environment-set! primitive from the language and, perhaps, thus
remove the temptation to believe that such an expression might be correct in the
first place.
Jinx also asks ``What is wrong with (: a b1 b2 ... bk)?'' Well, I tried looking
at some code written using this and using modules to the degree that I'm used to
in Cedar (that is, module references are very common, averaging about one for
every three lines of code). I still find this too verbose.
Juan objects to structured names at all, regardless of their syntax, stating
that their use tends to decrease modularity by wiring in a particular
organization of modules. I claim that they only wire in a particular
organization of *interfaces* and that this is precisely the purpose of
interfaces. Interfaces represent the contract between a provider and a client
and as such, it is intended that the client depend upon them.
In an example, Juan objects to the name MATH:SQRT because it specifies where I
want to find the square-root function. Not only is that exactly my intention,
but it might be that I am using two different procedures named SQRT, one from
the MATH interface and one from some other interface. The two might have very
different meanings and so qualified names are the only reasonable way to keep
them straight. In general, I want to use qualified names for *everything except
the features of the language itself*.
Juan also says that it is impossible to abstract over or shadow a qualified
name. Precisely; that is not their purpose. Such abstraction and shadowing is
meaningless and thus I am relieved that it is impossible.
----------
Both Jinx and Juan object to what they call the ``absolute'' nature of the file
syntax/semantics I proposed. I think that they are partially right, in that a
file (or, more generally, expression) should not attempt to specify anything
about the implementations of the interfaces it imports. However, I do believe
that it should specify the interfaces themselves. That is, the code should make
clear of what interfaces (and of what versions of them) it is a client and,
further, for what interfaces (in what versions) it is attempting to be a
(perhaps partial) provider. It is then the responsibility of the user of this
code to supply proper implementations of the imported interfaces and to make the
code available as a provider of the exported ones.
Pavel
∂06-Jun-88 2011 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM On Modules in Scheme: Principles and Proposals
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jun 88 20:11:19 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 Jun 88 23:10:01 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUN 88 20:05:12 PDT
Date: Mon, 6 Jun 88 20:05:02 PDT
From: Pavel.pa@Xerox.COM
Subject: On Modules in Scheme: Principles and Proposals
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880606-200512-6178@Xerox>
Well, after carefully reading and considering the comments I've received on the
environment proposal, and after having many many hours of talks with a variety
of people around here on the general subject of modules (be they in Scheme on
some other language), and after having gotten to the point in the development of
our compiler where I need more help than our proposal was offering, I formally
retract our previous proposal.
In its place, I offer the following ideas for discussion. There are many
details left out (most of them intentionally), but I think that what's here is
the real core of what I believe about what a module facility can and should
provide and how it should be structured. I have freely stolen ideas and names
from others, both on and off this list, but I have not always left those ideas
and names entirely intact. Caveat lector.
Principles: There exist written and (at least partially) machine-understandable
statements of the contracts between different pieces of software. These
``interfaces'' describe all paths of contact between separate pieces of
software; at the level of normal programming (as opposed to facilities provided
by the debugger, for example), no other access is possible. In addition to
specifying the names of the values available in the interface, other properties
of the values might be given, such as type information, partial or complete
implementations (for integration by, or providing hints to, early evaluators),
formal or informal assertions of the semantics of the values, etc.
Proposals: There exist entities known as ``signatures'' containing at least a
set of names for values and possibly other information as stated above. These
are not necessarily Scheme data objects. Signatures have names representable as
Scheme values. There is a mechanism by which a given signature name can be
associated with a particular signature. This mechanism may or may not be a part
of the Scheme language.
Principles: It is recognized that interfaces will change over time as providers
and clients learn more about the desired models and paths of communication. It
is also recognized that early evaluators must, for performance reasons, be
allowed to make certain assumptions about the interfaces (and the values they
represent). We desire that there be a consistent, non-temporal model of the
semantics of programs, regardless of whether or not they have, at some point,
been partially evaluated. Thus, it must be possible for an early evaluator to
``build in'' information from the interfaces and to store in the resulting
output some identification of the information used. This stored identification
should then be used by later evaluators to guarantee that a consistent view of
the possibly-changed interfaces is being employed.
Proposals: Signatures have ``versions'', representable as Scheme values, drawn
from some partial order. There is a procedure for comparing two versions
according to the partial order. There is a ``least'' version according to the
partial order; we refer to this as the ``bottom'' version.
Principles: There must be some mechanism by which the code of a client of an
interface can refer to the values the interface represents. Symmetrically,
there must be a mechanism by which the code of an interface provider can specify
values to be associated with names in that interface. This should be possible
without either party needing to be aware of the identity or quantity of the
other. It should be possible for client code to efficiently fetch the values
and for lambda-enclosed references to exist before provider code for the values
has been evaluated. It should be possible for a provider to supply values for
only a part of an interface.
Proposals: There exist Scheme values called ``structures''. Creating a
structure requires the name of a signature and values for some, none, or all of
the names in the named signature. The given values must agree with the
information about them in the signature. Some or all of that information may be
checked during structure creation. There is an operation for fetching the
signature name and version from a structure.
There exist Scheme values called ``bindings''. A binding contains a single
``value'' which may be specified at the time of binding creation; if it is not
specified, the value is said to be ``undefined''. Structures map names into
bindings. There are operations for getting the value of a binding, for testing
whether or not the value is undefined and for setting the value; the value may
only be set if it is currently undefined.
Principles: Code that is a client of a particular interface should be clearly
marked as such, for both documentation and semantic purposes. It should be
possible for a given piece of code to be a client of many interfaces as well as
a (partial or complete) provider of many more.
Proposals: There exist Scheme values called ``modules''. A module contains,
possibly among other things, an ordered list of signature names and versions
(its ``imports'') and a procedure (its ``body''). The body takes exactly as
many arguments as there are signature name/version pairs in the imports. Those
arguments should be structures formed from signatures with matching names and
greater than or equal versions; this assertion is tested by the body and an
error is signalled if the condition is not met. The body may return any value
or values, as desired. In particular, the body might return one or more
structures, intending that the invoker will treat them as the provision of
values for some signatures.
Principles: It should be possible for code to refer to the names from some
interfaces without having to qualify them with some identification of the
interface. For example, the ``built-in'' facilties of the programming language
are a likely choice for such treatment. However, this set of interfaces should
not be a constant; different programs should be allowed to specify different
sets. In general, such ``opening'' of an interface can be confusing and
possibly dangerous; accordingly, most imported values should be referred to by
names that indicate the interface from which they are derived.
Proposals: There is a new kind of Scheme expression for the creation of a
module:
(MODULE (<sig-name> ... (<identifier> <sig-name>) ...)
<program>)
where <sig-name> is a signature name.
The first set of names specifies the set of signatures whose names are to be
available without extra qualification. These are called the ``open (or unnamed)
imports''. An error is signalled if any two of these signatures share a name;
unqualified references should be unambiguous.
The identifier/signature-name pairs specify the other, ``closed (or named)
imports''. In the resultant module body, these identifiers will be bound to the
structures passed as arguments to the body; an error will be signalled if any of
these identifiers are among the names in the open imports.
The imports of the module will be the given signature names in the given order.
The version information for the imports will be ``bottom'' unless some
early-evaluator has built in some assumptions about the signatures.
The program has the syntax given in R3RS and this semantics; it is as if all of
the names appearing in DEFINEs were bound in a single LET to unspecified values,
the body of the LET being the sequence of forms resulting from turning all of
the DEFINEs into SET!s. This expression is evaluated whenever the module body
is invoked; the value(s) of the body invocation are the value(s) of this
expression. The lexical environment of the body expression is that of the
MODULE expression as a whole, shadowed by bindings of all of the names in the
open imports.
On top of a facility like this, it would be easy to build some useful utilities.
For example, suppose that the LOAD procedure returned a list of the values of
the <command>s in a file. Then one could imagine a different procedure, call it
FRIENDLY-LOAD, that worked as follows:
-- For each value returned by LOAD, test whether or not it is a module; if not
discard it.
-- For each module, acquire structures for each of its imports and apply the
body of the module to these structures. FRIENDLY-LOAD maintains a table mapping
signature names and versions to structures. For each signature named among the
imports for which there is no entry in the table, it creates a fresh structure,
giving no values for bindings, and adds it to the table.
-- If the values returned from the module body invocation are structures, these
are taken to be the ``exports'' of the module. The signature-names of these
structures are looked up in the table as before, creating fresh structures if
necessary. Finally, for those names whose bindings in the export structure are
not undefined, the values are copied into the corresponding bindings in the
table structure.
In this way, FRIENDLY-LOAD acts as a system-wide matchmaker, hooking together
the clients and suppliers of interfaces. Of course, no one would have to use
this facility; one could put an entirely different one together out of the
primitives provided.
I've typed enough here. Comments?
Pavel
∂06-Jun-88 2049 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM R(3.5)RS Question
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jun 88 20:49:18 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 6 Jun 88 23:49:04 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUN 88 20:44:53 PDT
Date: Mon, 6 Jun 88 20:44:47 PDT
From: Pavel.pa@Xerox.COM
Subject: R(3.5)RS Question
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880606-204453-6217@Xerox>
I've just been looking over the differences between R3 and R3.5 and noticed
that, among a bunch of other number changes, the syntax of the written
representation of rectangular complex numbers has been changed to have the ``i''
before the coefficient rather than after it. I can't see any reason based upon
parsing to do this and it's certainly against common mathematical practice, so
why is it being done?
The only thing I could find in the archives on this point is a desire for
syntaxes like ``3+i'' and ``-i'' to work. It's not clear to me that satisfying
this implies a need to move the ``i'' around. Does it?
Pavel
∂07-Jun-88 1433 @MC.LCS.MIT.EDU:gls@Think.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jun 88 14:33:26 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 7 Jun 88 17:10:45 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 7 Jun 88 17:05:53 EDT
Received: by kali.think.com; Tue, 7 Jun 88 17:05:48 EDT
Date: Tue, 7 Jun 88 17:05:48 EDT
From: gls@Think.COM
Message-Id: <8806072105.AA00556@kali.think.com>
To: jrl@vx.lcs.mit.edu
Cc: pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Juan Loaiza's message of Sat, 4 Jun 88 00:20:23 edt <8806040636.AA18047@Think.COM>
Subject: Re: opaque type proposal
Date: Sat, 4 Jun 88 00:20:23 edt
From: Juan Loaiza <jrl@vx.lcs.mit.edu>
You still need the length check in order to make sure that the slot containing
the ``tag'' object actually exists before trying to fetch its value.
Pavel
Think again about the trick I mentioned. It is a dirty, underhanded,
shameful, slimy trick; but I think it works. If a token for a type T
is only ever present in the N'th slot of an object of type T, then
looking at the N'th slot of any other object will never get you that
token. It does not matter how many slots the other object has. If it
has less than N slots you, will get a random slot out of another
object, but never the N'th slot (assuming no objects have zero
length).
For our young listeners out there, please don't try this trick at home.
Some care is needed near the end of memory, to make sure that the start of
the last object is as far from the end of the legitimate address space as
the greatest distance of any tag from the origin of its object. Ugh,
bletch. Also, having any kind of "raw array" representation could screw
things up. Otherwise, it's a great, wonderful, slimy crock.
Congratulations.
--Guy
∂07-Jun-88 2046 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jun 88 20:46:25 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 7 Jun 88 22:01:58 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 117837; Tue 7-Jun-88 21:52:43 EDT
Date: Tue, 7 Jun 88 21:52 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: opaque type proposal
To: Pavel.pa@Xerox.COM
cc: JAR@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <880606-113918-5026@Xerox>
Message-ID: <19880608015223.6.ALAN@PIGPEN.AI.MIT.EDU>
Date: Mon, 6 Jun 88 11:39:06 PDT
From: Pavel.pa@Xerox.COM
...
Alan is concerned that allowing single inheritance now might be a hinderance
later if we decide to extend to multiple-inheritance. I don't claim to be a big
expert, but it seems to me that all of the multiple-inheritance facilities that
I've seen have precisely the same simple single-inheritance semantics as a
special case. Alan (or anyone else), do you know of any exceptions to this? If
not, then I would think that we were fairly safe in going this far (and no
more).
Well first off, they might all be wrong, and when the clearly right thing
emerges it might not have the single inheritance semantics that we expect.
(Actually, isn't there already division between those who thing that
children should automatically inherit all of their parents slots, and
those who think that you should have to explicitly import those slots that
the child wants to be able to directly access?)
But putting that kind of issue aside, I had a much more mundane kind of
problem in mind. For example, if we decide now that single inheritance is
accomplished by calling
(MAKE-RECORD-TYPE <name> <slot-names> <parent-type-descriptor>)
then we have to decide later how to specify multiple superiors in an
upward-compatible way. Do we let the third argument be -either- a single
record-type-descriptor or a list of record-type-descriptors? That's only a
little ugly. But perhaps it turns out that instead of an ordered sequence
of record-type-descriptors, we want to provide a procedure that you apply
to an operation, and it returns a record-type-descriptor. Then do we
specify that the third argument is either a procedure or a record-type-
descriptor (where the latter is taken to be an abbreviation for the one
argument procedure that always returns that record-type-descriptor)?
Now the ugliness starts to mount.
Now I'm sure we can guard against this -particular- screw (or convince
ourselves that it isn't a problem). But my point is that I feel that we
are unlikely to be able to start in the direction of inheritance without
inviting -some- problem like this.
∂07-Jun-88 2046 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: opaque type proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jun 88 20:46:39 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 7 Jun 88 22:18:39 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUN 88 19:11:39 PDT
Date: Tue, 7 Jun 88 19:11:34 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: opaque type proposal
In-reply-to: <19880608015223.6.ALAN@PIGPEN.AI.MIT.EDU>
To: Alan Bawden <Alan@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880607-191139-1601@Xerox>
I think that I'm not very worried about your ``more mundane'' kind of problem,
viz. upward-compatibility when or if we get around to adding
multiple-inheritance. Isn't this entirely orthogonal to inheritance? For
example, what about when we get around to specifying a mechanism for
type-specific print operations, or any of a hundred other little options that we
might later decide to add? I don't see how the addition of these to
MAKE-RECORD-TYPE's argument list is likely to be any more painless/beautiful.
I'm also not convinced any longer that the issue of ``how not to make mistakes
now that hurt us when we later add multiple-inheritance'' is terribly important.
The notion of opaque types and sub-typing are reasonably well understood
entirely independently of any casual resemblance to an object-oriented
programming facility. If we're really so concerned that the facility we're
talking about now be extendable into an object-oriented programming facility,
then I submit that we should never decide on such an extension that cannot
handle this very simple and useful semantics.
In short, I'm having a hard time seeing the importance of this
upward-compatibility argument. All I want is this simple, straightforward
semantics for a very useful facility; it's just not clear to me that the
decision has the great weightiness of future impact that you perceive. Can you
explain your concern more fully?
Pavel
∂08-Jun-88 1126 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU report sources
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Jun 88 11:26:02 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 8 Jun 88 13:09:25 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Wed, 8 Jun 88 12:32:20 edt
Date: Wed, 8 Jun 88 12:32:20 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8806081632.AA21677@chamarti>
To: JAR@AI.AI.MIT.EDU
Cc: hieb@IUVAX.CS.INDIANA.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Mon, 6 Jun 88 22:03:25 EDT <392964.880606.JAR@AI.AI.MIT.EDU>
Subject: report sources
Reply-To: jinx@zurich.ai.mit.edu
Anonymous login works with PREP's FTP server; I don't know about zurich,
but I don't think so. If you can't use tar format, let me know and put
the un-tarred files on PREP as well.
It should work on zurich too, except that the password may have to be
typed as "" on some systems.
The pathname there is pub/r4rs.tar
∂08-Jun-88 1519 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Call for publishable code!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Jun 88 15:18:58 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 8 Jun 88 18:01:12 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 88 12:59:43 PDT
Date: Wed, 8 Jun 88 11:49:09 PDT
From: Pavel.pa@Xerox.COM
Subject: Call for publishable code!
To: LispUsers↑.x@Xerox.COM, scheme@mc.lcs.mit.edu,
common-lisp@sail.stanford.edu, info-1100@sumex-aim.stanford.edu,
franz-friends@berkeley.edu, kcl@cli.com
Reply-To: Pavel.pa@Xerox.COM
Message-ID: <880608-125943-2995@Xerox>
I am the editor of the new Algorithms department of the international
newsletter/journal Lisp Pointers. The department is intended to cater to the
perceived preferences of most Lisp hackers: they'd rather write code than
articles. The articles in the department therefore fall into one or more of the
following three broad categories:
-- Annotated implementations of interesting and relevant algorithms that make
particularly good or novel use of the unique features of the Lisp family of
programming languages (e.g., closures, continuations, code as data,
polymorphism),
-- Annotated implementations of algorithms whose subject matter is the Lisp
family of languages (e.g., code analysis tools, iteration facilities, generic
arithmetic), and
-- Discussion of performance issues, benchmarking, or implementation experiences
for interesting algorithms written in or about the Lisp family of languages.
I am continually looking for ideas for appropriate articles for the department.
If you've got a nice hack you're proud of, or a particularly elegant piece of
code (you know, the kind that you call in one of your fellow hackers to see) and
you'd like to see it written up in the Algorithms department, please send it
along. What you give me doesn't have to be polished or even contain any prose;
if I agree that it's appropriate for the column, I'll work with you to put
together an article around it.
Hoping to hear from you,
Pavel Curtis
Xerox PARC/CSL
3333 Coyote Hill Rd.
Palo Alto, CA 94304
(415) 494-4455
Pavel.pa@Xerox.Com
∂09-Jun-88 0417 @MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU siod-v1.3 now in comp.sources.unix
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jun 88 04:17:03 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 9 Jun 88 07:12:12 EDT
Return-Path: <gjc>
Received: by bu-it.BU.EDU (5.58/4.7)
id AA26825; Thu, 9 Jun 88 07:09:37 EDT
Date: Thu, 9 Jun 88 07:09:37 EDT
From: gjc@bu-it.BU.EDU (George J. Carrette)
Message-Id: <8806091109.AA26825@bu-it.BU.EDU>
To: scheme@mc.lcs.mit.edu
Subject: siod-v1.3 now in comp.sources.unix
Siod went out on comp.sources.unix sometime this week.
Here are some benchmark results for a random selection of
machines I happened to have handy. Not very favorable to DEC machines
compared with most other benchmarks. Someone on this list said they had
IBM 3090 timings?
Make Model FIB(5) FIB(10) FIB(15) FIB(20) 20/FIB(20)
Sun 4 0.00 0.02 0.38 4.2 4.76
DIGITAL 8530(VMS) 0.00 0.07 0.78 8.5 2.35
Sun 3/280 0.00 0.10 0.88 8.5 2.35
Sun 3/180 0.02 0.15 1.56 17.5 1.14
Encore Multimax(NS32) 0.02 0.17 1.85 20.5 0.97
DIGITAL VS-2000 0.02 0.30 3.56 39.7 0.50
Encore Multimax(NS16) 0.03 0.33 3.63 40.4 0.49
AMIGA 500 LATTICE C 0.00 0.00 5.00 55.0(x) 0.36
DIGITAL 11-750(4.3BSD) 0.03 0.53 5.80 66.5 0.30
Unix compilations done with the -O flag. All 68020 machines
with -f68881. Heap size of 120000 used. Timing done with standard-fib
procedure in siod.scm using SIOD Version 1.3 (which is slightly slower
than earlier versions). AMIGA 500 FIB(20) time is extrapolated from
the FIB(15) time.
n FIB(n) Cons Work
5 5 66
10 55 795
15 610 8877
20 6765 98508
∂09-Jun-88 1443 @MC.LCS.MIT.EDU:Leo_Vetter.WBST207V@Xerox.COM Remove from Distribution
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jun 88 14:43:37 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 9 Jun 88 17:38:54 EDT
Received: from Burger.ms by ArpaGateway.ms ; 09 JUN 88 14:31:06 PDT
Sender: "Leo_Vetter.WBST207V"@Xerox.COM
Date: 9 Jun 88 13:25:50 PDT (Thursday)
Subject: Remove from Distribution
From: "Leo_Vetter.WBST207V"@Xerox.COM
To: LispUsers↑.X@Xerox.COM, scheme@mc.lcs.mit.EDU,
common-lisp@sail.stanford.EDU, info-1100@sumex-aim.stanford.EDU,
franz-friends@berkeley.EDU, kcl@cli.COM
cc: LV.WBST207V@Xerox.COM
Reply-to: "Leo_Vetter.WBST207V"@Xerox.COM
Message-ID: <880609-143106-5374@Xerox>
Please remove me from all LISP DLs.
Thanks,
Leo Vetter
∂11-Jun-88 1953 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Scheme modules using HERALD, MODULE, and IMPORT.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jun 88 19:52:54 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 11 Jun 88 22:51:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA22801; Sat, 11 Jun 88 22:46:38 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Sat, 11 Jun 88 22:46:07 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA15269; Sat, 11 Jun 88 22:46:07 EDT
Date: Sat, 11 Jun 88 22:46:07 EDT
Message-Id: <8806120246.AA15269@darwin.sun.uucp>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Fri, 27 May 88 01:13:52 EDT <386391.880527.JAR@AI.AI.MIT.EDU>
Subject: Scheme modules using HERALD, MODULE, and IMPORT.
Here is a crack at the kind of module system I envision. It was
motivated by worrying about the multiple definition problem. Consider
the problem of writing a random number generator. You would like to
hide the seed, but provide a means to set the seed as well as compute
the next pseudo-random number. One would like to write:
(DEFINE-MANY (set-seed! random)
(DEFINE seed 42)
(DEFINE (set-seed! value) (SET! seed value))
(DEFINE (random) ....))
Since you would like to be able to use DEFINE-MANY where ever local
DEFINE's can be used, it is not clear how to expand DEFINE-MANY, but
at top-level, it might expand into:
(DEFINE set-seed! '())
(DEFINE random '())
(LET ((seed 42))
(SET! set-seed! (LAMBDA (value) (SET! seed value)))
(SET! random (LAMBDA () ....)))
DEFINE-MANY makes its export list explicit, and augments the current
environment with the exported values. Its body is defined in the
current environment augmented by all the definitions within the body.
All good module systems separate a module's interface description from
its implementation. Hence we abandon DEFINE-MANY for HERALD, MODULE,
and IMPORT.
The HERALD form defines a module's interface, and may appear where
ever a DEFINE appears.
(HERALD module-id id*)
The environment in which the module is defined is given by the
position of the HERALD form. The form also lists the identifiers
exported by the module.
The implementation of a module is declared by using MODULE, and its
body simply follows the MODULE form.
(MODULE module-id) definition*
Another property of any good module system is the ability to separate
the definition environment from the elaboration environment. The
form
(IMPORT module-id)
simply imports the module's exports into the current lexical
environment. It cannot change the definition of a module.
The structure of a Scheme program becomes:
--------------------------------------
program ::= definition* expression module*
definition ::= (DEFINE ....) ; Usual definition.
| (IMPORT module-id) ; module import.
| (HERALD module-id id*) ; module interface.
expression ::= id
| constant
| (LAMBDA (id*)
definition*
expression+)
| (IF expression expression expression)
| (SET! id expression)
| (expression+) ; call
module ::= (MODULE module-id) definition*
--------------------------------------
While each module has exactly one HERALD and MODULE
form, there may be any number of IMPORT forms which reference that
module. The three module forms return unspecified values just like
DEFINE.
For a program contained in one file, the module-id can simply be a
symbol. For multi-file programs, a module-id could be a list of
symbols interpreted in a machine dependent way. As an example, the
module-id "(tsystem sources sys gc two-finger)" on a Unix machine
might reference the module named "two-finger" in the file
"$TSYSTEM/source/sys/gc.scm".
The MODULE form could be used to specify read tables and syntax tables
as is done in T. The HERALD form would give a compiler its early
binding environment.
I have not thought out the details of an implementation of this module
system. The implementation would have to handle circular module
references, but I see no obvious difficulties.
John
∂13-Jun-88 0756 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 07:56:04 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Jun 88 10:51:22 EDT
Date: Mon, 13 Jun 88 10:51:01 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (define x)
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <396508.880613.JAR@AI.AI.MIT.EDU>
Does anyone have an objection to the syntax "(define x)" meaning that
the variable is to be bound, but its location is to be either left
unassigned or assigned an unspecified value? This is already
implemented in MIT Scheme, I think.
Consider it proposed.
∂13-Jun-88 0945 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 09:45:08 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 13 Jun 88 12:30:53 EDT
Received: by ti.com id AA02103; Mon, 13 Jun 88 11:27:52 CDT
Received: from mips by tilde id AA02096; Mon, 13 Jun 88 11:20:08 CDT
Received: by mips id AA06701; Mon, 13 Jun 88 11:19:55 CDT
Date: Mon, 13 Jun 88 11:19:55 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8806131619.AA06701@mips>
To: JAR@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan A Rees's message of Mon, 13 Jun 88 10:51:01 EDT <396508.880613.JAR@AI.AI.MIT.EDU>
Subject: (define x)
We are using "(define x)" here at TI as you specified it. It seems
to be preferable to requiring something like "(define x 'garbage)"
because the latter is unnecessarily overspecific and might complicate
life for, say, a type inferencer.
∂13-Jun-88 1235 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 12:35:18 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 13 Jun 88 15:32:45 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUN 88 12:24:58 PDT
Date: Mon, 13 Jun 88 12:24:39 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: (define x)
In-reply-to: <396508.880613.JAR@AI.AI.MIT.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <880613-122458-9409@Xerox>
Presumably the only use for this is to avoid having to pick a value in those
cases where it will not be used?
Pavel
∂13-Jun-88 1420 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 14:19:55 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 13 Jun 88 17:18:05 EDT
Received: by iuvax.cs.indiana.edu; id AA19062; Mon, 13 Jun 88 16:16:54 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Mon, 13 Jun 88 16:16:54 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Full Specification
Date: Tue 24 May 88 13:13:21-EDT
From: Morris Katz <MKATZ at A.ISI.EDU>
Overspecification should be avoided as it artificially
prohibits reasonable implementations.
Date: Thu May 26 07:49:42 1988
From: Jonathan A Rees <JAR@mc.lcs.mit.edu>
Underspecification effectively amounts to giving an axiomatic semantics
(proof system) for the language, as opposed to a denotational one (a
model). The problem with underspecification is that one can have a
program that works fine in one implementation and fails in another, so
the only way to produce portable code is by reasoning about it, and
testing doesn't help you a bit. While I agree that some
underspecifications are important, I believe you can go too far in
underspecifying things that really don't make much difference, requiring
reasoning in situations where testing ought to be sufficient.
Underspecifications makes the language harder to learn and use, since an
implementation cannot teach them very well. One must be aware of all
underspecifications all the time. I think they should be minimized, not
maximized.
This debate should be carried further. Currently I don't see a coherent
policy on full specification (one might say it is underspecified).
Three sources of underspecification:
1. Failure to achieve consensus on what a full specification should be.
2. A desire to not unduly impede implementations.
3. Attempting to simplify the specification by ignoring accidental or
unessential details.
The first is unfortunate, and we should do better.
The second is reasonable but not compelling. Language designers
should don their user hats. From the standpoint of the user implementation
considerations are significant only if they greatly affect speed, memory
usage or reliability. Thus implementation considerations should have veto
power and perhaps be allowed to vote in case of a tie, but otherwise
stay in the background (like a good implementation).
The third is the touchy one. It is a counter argument to Rees' claim
that underspecification makes a language easier to learn. Leaving out
incidental details may actually make it easier to understand and use a feature.
For example, assignments are used mainly for effect---the value returned
is usually not important. However, once specified, it will be used.
Thus users will in the end be forced to learn and remember all specified
details (if you don't use them someone whose code you must read will).
The other side---reasons for full specification:
1. Consistency across implementations, allowing one to test and port
programs with reasonable assurance.
2. Full compliance with a semantic model.
2. Use of the specified details.
Number one is a large win. We are still at the point (and undoubtably always
will be, at least for the life of Scheme as a living programming language)
where large programs can only [reasonably] be shown to be correct by testing.
The argument that correct programs do not rely on unspecified features is
not reasonable for large programs. Programmers make mistakes, and will
write programs that happen to rely on unspecified features of a given
implementation. Some of these mistakes are so easy to make one could call
them traps. For instance, one really expects the definitions in a body to be
accomplished in order.
Number two: the history of Scheme has been intimately tied with denotational
semantics---the value of a full formal semantics for Scheme should not be
underestimated.
Number three is the least compelling. Typically one has no use for the
unspecified aspects and can provide for them when necessary, arguably in
a clearer fashion.
Conclusion: full specification is best. In most cases there are reasonable,
consistent specifications that are as easy to remember (and specify) as
``not specified.'' If it is an error to rely on something that will
in fact end up being specified in a given implementation we should make it a
signaled error.
Following are some specification proposals:
Procedures with side effects return the value of the ``source'' expression.
For instance, all of the following would return the value of e:
(set! x e)
(set-car! x e)
(write e p)
There are of course other possibilities; the above has the advantage
of naturalness and symmetry across a broad class of expressions.
The expressions in a procedure call are evaluated from left to right.
This is perhaps the trickiest underspecification in Scheme. It can be
extremely difficult to verify that order of evaluation has no effect in a large
program. A reasonable order is left to right, since that's the way bodies
are evaluated.
Definitions are also evaluated left to right.
(let () (define x e) (define y f))
means
(let ((x <undefined>) (y <undefined>)) (set! x e) (set! y f))
where referencing <undefined> signals an error.
And of course there are more, but that is enough to test the water.
∂13-Jun-88 1446 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 14:46:31 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Jun 88 17:45:17 EDT
Date: Mon, 13 Jun 88 17:44:35 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (define x)
To: Pavel.pa@XEROX.COM
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 13 Jun 88 12:24:39 PDT from Pavel.pa@Xerox.COM
Message-ID: <396821.880613.JAR@AI.AI.MIT.EDU>
Date: Mon, 13 Jun 88 12:24:39 PDT
From: Pavel.pa@Xerox.COM
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: rrrs-authors@MC.LCS.MIT.EDU
Re: (define x)
Presumably the only use for this is to avoid having to pick a value
in those cases where it will not be used?
Presumably.
Also, I forgot to mention: in order to allow implementations to signal
errors when the variable is referenced after such a DEFINE but before a
SET! of the variable, it needs to be specified that it is an error to so
refer to the variable.
We need to decide whether this is to make sense only for top-level
defines or for internal defines as well. If for internal defines, the
desugaring into LETREC has to be given; that would probably mean that
LETREC would have to be extended (e.g. (letrec ((x) (y)) ...)); and that
seems like a bad idea to me, although I don't feel strongly; so I'd
suggest making it a special case for top level. Top level defines are
already sufficiently different from internal ones (e.g. they are
evaluated sequentially, and may be interspersed with expressions) that
this doesn't seem too terrible.
∂13-Jun-88 1650 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 16:50:35 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 13 Jun 88 19:46:05 EDT
Received: by ti.com id AA04686; Mon, 13 Jun 88 18:42:55 CDT
Received: from mips by tilde id AA03639; Mon, 13 Jun 88 18:43:10 CDT
Received: by mips id AA16890; Mon, 13 Jun 88 18:43:04 CDT
Date: Mon, 13 Jun 88 18:43:04 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8806132343.AA16890@mips>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Robert Hieb's message of Mon, 13 Jun 88 16:16:54 EST <8806132217.AA02371@tilde>
Subject: Full Specification
>Three sources of underspecification:
>
> 1. Failure to achieve consensus on what a full specification should be.
> 2. A desire to not unduly impede implementations.
> 3. Attempting to simplify the specification by ignoring accidental or
> unessential details.
>
>The first is unfortunate, and we should do better.
>
>The second is reasonable but not compelling. Language designers
>should don their user hats. From the standpoint of the user implementation
>considerations are significant only if they greatly affect speed, memory
>usage or reliability. Thus implementation considerations should have veto
>power and perhaps be allowed to vote in case of a tie, but otherwise
>stay in the background (like a good implementation).
Yeah, but... For a relatively new language like Scheme, we can't
always predict which language "features" will greatly affect
performance. In my experience, the more I look at alternative
computer architectures (e.g., parallel processing) and alternative
compilation/optimization techniques, the more important under-
specification can become. Still, our use of under-specification in
the document is often ad hoc and subjective, and I agree that we could
use some discussion on the topic.
∂13-Jun-88 1946 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jun 88 19:45:53 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 13 Jun 88 22:39:28 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUN 88 19:29:45 PDT
Date: Mon, 13 Jun 88 19:29:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Full Specification
In-reply-to: "hieb@iuvax.cs.indiana.edu's message of Mon, 13 Jun 88 16:16:54
EST"
To: Robert Hieb <hieb@iuvax.cs.indiana.edu>
Cc: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880613-192945-10499@Xerox>
``Full compliance with a semantic model'' does not necessarily imply that, for
example, the SET! form must have a defined return value. It simply means that
the semantics must show a small piece of nondeterminism, in the same way that it
now uses the ``implementation-dependent'' function ``permute'' in order to dodge
the question of argument evaluation order.
You say ``one really expects the definitions in a body to be accomplished in
order''. I don't. Maybe I'm strange, but I've never considered using internal
define's for anything but local procedures, whose order of evaluation is
irrelevant.
I am opposed strongly to all three of your proposals.
I have never believed that the return value of things like ``write'' and
``set-car!'' had a reasonable justification in languages like Common Lisp and it
makes more sense for these procedures (and the set! expression) to return no
value at all. I find code that uses the return value of such constructs
considerably harder to read. Code that does not do this is, yes, frequently
more verbose, but always more readable.
A significant source of first-level optimization is the lack of a defined
argument-evaluation order in the language. It is almost always more convenient,
for example, to evaluate the function form last, after all of the arguments have
been evaluated. Also, in my experience, code that depends upon left-to-right
order (in those languages that guarantee it) is again always harder to read.
Requiring the implementation of internal defines to signal an error if
<undefined> is referenced is quite possibly too expensive for many applications.
In addition, I dislike the notion of encouraging people to write series of
internal defines that are sensitive to evaluation order. It goes against what I
consider to be the clean and readable purpose of such defines: binding local
procedures.
``And of course there are more, but that is enough to test the water.''
This reader sees sharks in the water...
Pavel
∂14-Jun-88 0108 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jun 88 01:08:45 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 14 Jun 88 04:06:12 EDT
Received: by kleph.AI.MIT.EDU; Tue, 14 Jun 88 04:07:17 edt
Date: Tue, 14 Jun 88 04:07:17 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8806140807.AA03267@kleph>
To: hieb@iuvax.cs.indiana.edu
Cc: Pavel.pa@Xerox.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 13 Jun 88 19:29:24 PDT <880613-192945-10499@Xerox>
Subject: Full Specification
Reply-To: cph@zurich.ai.mit.edu
Date: Mon, 13 Jun 88 19:29:24 PDT
From: Pavel.pa@Xerox.COM
You say ``one really expects the definitions in a body to be
accomplished in order''. I don't.
Requiring the implementation of internal defines to signal an error if
<undefined> is referenced is quite possibly too expensive for many
applications. In addition, I dislike the notion of encouraging people
to write series of internal defines that are sensitive to evaluation
order. It goes against what I consider to be the clean and readable
purpose of such defines: binding local procedures.
Hear, hear! Internal defines, just like `letrec', should be used ONLY
when the value is something that can possibly need mutual recursion.
In other words: lambda expressions and `delay' expressions. In both
those cases there is no order of evaluation dependendence.
Defining an order implies that internal definitions can and should be
used for other values as well -- a terrible idea.
A significant source of first-level optimization is the lack of a
defined argument-evaluation order in the language.
Again, I agree. MIT's compiler takes advantage of this to produce
significantly better code than it could otherwise -- and we intend to
build more optimizations in the future that depend on this
underspecification.
I think it is a good idea to understand why we need
underspecification, and where. But full specification has some
serious problems:
1. It ties the hands of the implementer. My comments on order of
argument evaluation are an example. Another: MIT Scheme foolishly
allowed the value of `set!' to become defined -- without ever saying
it in print anywhere -- thus requiring the compiler to generate code
for that value whenever it couldn't prove that the value was not used.
I'm seriously considering changing that behavior despite the fact that
some people depend on it.
2. Underspecification is useful. My comments on internal definitions
are an example. Here we are trying to encourage a style, without
requiring all implementations to enforce it. Full specification in
this case would DISCOURAGE that style, while encouraging a different
one.
3. Full specification is a never ending game. When have we finished
specifying everything? People will be forever noticing new details
that we have missed and forcing us to specify some behavior for them.
In fact, most of those details are uninteresting.
In contrast, underspecification is automatic. By overlooking some
behavior, we have "underspecified" it. This is appropriate, since the
kind of thing that is likely to be overlooked is precisely the thing
least interesting to specify.
∂14-Jun-88 1104 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jun 88 11:04:31 PDT
Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 14 Jun 88 13:50:14 EDT
Received: by ATHENA.CS.YALE.EDU; Tue, 14 Jun 88 12:23:01 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8806141623.AA03523@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Tue Jun 14 12:29:33
Date: Tue, 14 Jun 88 12:29:27 EDT
Subject: Re: Full Specification
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: cph@kleph.AI.MIT.EDU (Chris Hanson), Tue, 14 Jun 88 04:07:17 edt
I understand the desire for underspecification in certain places (for
example order-of-evaluation of arguments) but don't forget probably the
most critical advantage of full specification: portability. To take
the order-of-evaluation example, one can only say: "this program is portable
as long as none of the arguments induce any side-effects." Every place you
decide to admit underspecification, you have to make this kind of qualifying
remark. People who want a STANDARD aren't going to like it.
Another comment, concerning Chris Hanson's comment:
3. Full specification is a never ending game. When have we finished
specifying everything? People will be forever noticing new details
that we have missed and forcing us to specify some behavior for them.
In fact, most of those details are uninteresting.
In contrast, underspecification is automatic. By overlooking some
behavior, we have "underspecified" it. This is appropriate, since the
kind of thing that is likely to be overlooked is precisely the thing
least interesting to specify.
The flip side of this argument is that many of those overlooked behaviors
are VERY interesting; in fact critical. The whole purpose in giving a formal
semantics to a language is to uncover those subtle unspecified behaviors that
raise havoc with users. If you choose to underspecify something, then at least
specify that you have chosen to underspecify! In other words, make it a formal
part of the language semantics.
And by the way, if one *really* believes in underspecification, then I should
point out that in the Scheme report the order of evaluation of arguments is
not underspecified enough! In particular, the order is informally said to
be "indeterminate" and in the formal semantics it is said to be dictated
by a fixed function called PERMUTE. This is overspecified in two ways:
1) PERMUTE being fixed implies that for a given program a compiler must
use the *same* (although arbitrary) evaluation order for every call.
2) Even without that constraint, the implementation is forced to perform
the evaluations *sequentially*, thus precluding parallel evaluation
of the arguments, unless the compiler can prove non-interference or
guarantee correctness with respect to PERMUTE.
Both of these overspecifications constrain the implementor. But I should
point out that fixing them in the formal semantics requires a shift from
a deterministic semantics to a non-deterministic one, most likely requiring
powerdomains, and not something to be taken lightly.
-Paul
-------
∂14-Jun-88 1204 @MC.LCS.MIT.EDU:Stever@IVORY.S4CC.Symbolics.COM Online copy of the RR..R report?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jun 88 12:04:24 PDT
Received: from IVORY.S4CC.Symbolics.COM (TCP 20024231401) by MC.LCS.MIT.EDU 14 Jun 88 14:19:06 EDT
Received: from YELLOWSTONE.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182867; Tue 14-Jun-88 11:19:41 EDT
Date: Tue, 14 Jun 88 11:18 EDT
From: Stephen Robbins <Stever@IVORY.S4CC.Symbolics.COM>
Subject: Online copy of the RR..R report?
To: scheme@mc.lcs.mit.edu
Message-ID: <19880614151816.5.STEVER@YELLOWSTONE.S4CC.Symbolics.COM>
Hi,
Is there an online copy of the Revised↑n Report available
for internet FTP?
- Stephen
∂14-Jun-88 1250 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Scheme modules using HERALD, MODULE, and IMPORT.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jun 88 12:50:31 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 14 Jun 88 14:45:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA19448; Tue, 14 Jun 88 08:19:06 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Tue, 14 Jun 88 08:18:27 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA17963; Tue, 14 Jun 88 08:18:27 EDT
Date: Tue, 14 Jun 88 08:18:27 EDT
Message-Id: <8806141218.AA17963@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan A Rees's message of Mon, 13 Jun 88 10:44:01 EDT <396501.880613.JAR@AI.AI.MIT.EDU>
Subject: Scheme modules using HERALD, MODULE, and IMPORT.
I think the major difference between the Rees/ML proposal and mine
(call it the Ramsdell/Modula-II proposal) is Rees/ML has quasi first
class environments, and my proposal has no environment like values.
My proposal was built on a modest extension of the lexical structure
of Scheme. The Rees/ML approach is more ambitious. As I see it, the
big question is "should a module design for the language Scheme
include adding environment values or should environment values only be
part of the debugging environment?" Jonathan has obviously given his
vote.
JAR:
>One thing that always bugs me is that it is often assumed that
>interfaces and modules are in 1-1 correspondence. Doesn't Modula-II have
>that bug? I prefer the ML- or Mesa-like approach where the interface is
>specified independently and can be used by several different modules,
>and perhaps clients as well. That's what I was getting at with
>DEFINE-SIGNATURE.
Yeah, that is a good point.
John
∂14-Jun-88 2031 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu char-ready? => read-char-ready?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jun 88 20:31:01 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 14 Jun 88 23:25:36 EDT
Received: by iuvax.cs.indiana.edu; id AA29293; Tue, 14 Jun 88 22:21:30 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Tue, 14 Jun 88 22:21:30 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: char-ready? => read-char-ready?
I proposed this a while back, but my proposal met with little or no
response. I propose that the name of the optional procedure
"char-ready?" be changed to "read-char-ready?", to allow for
generalization to "read-ready?", "write-char-ready?", and maybe even
"write-ready?". Does anyone object to changing the name of
"char-ready?"? Note that I am not advocating that we add "read-ready?"
or the others, just that we change the name of "char-ready?" to
"read-char-ready?".
An additional justification for this proposal is that "char-ready?"
sounds too much like a character predicate (e.g., "char-upper-case?",
"char-numeric?") and does not sound like it has anything to do with
I/O.
Kent
∂15-Jun-88 0643 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 06:43:30 PDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 15 Jun 88 09:26:54 EDT
Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 164038; Wed 15-Jun-88 09:26:23 EDT
Date: Wed, 15 Jun 88 09:28 EDT
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Subject: (define x)
To: JAR@AI.AI.MIT.EDU
cc: Pavel.pa@XEROX.COM, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <396821.880613.JAR@AI.AI.MIT.EDU>
Message-ID: <880615092831.6.RHH@ASPEN.LCS.MIT.EDU>
Date: Mon, 13 Jun 88 17:44:35 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: (define x)
To: Pavel.pa@XEROX.COM
We need to decide whether this is to make sense only for top-level
defines or for internal defines as well. If for internal defines, the
desugaring into LETREC has to be given; that would probably mean that
LETREC would have to be extended (e.g. (letrec ((x) (y)) ...)); and that
seems like a bad idea to me ...
I don't find anything especially distasteful about it -- it strikes me
as useful for precisely the same purposes as the top-level (define x).
In fact, I would encourage (laziness prevents me from getting up and
checking the RRRS to see if it's already permitted) the form
(let ((x) (y)) ...) also, following the same argument. -Bert Halstead
∂15-Jun-88 0711 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU char-ready? => read-char-ready?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 07:11:08 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 15 Jun 88 10:08:08 EDT
Received: by kleph.AI.MIT.EDU; Wed, 15 Jun 88 10:10:14 edt
Date: Wed, 15 Jun 88 10:10:14 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8806151410.AA04278@kleph>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 14 Jun 88 22:21:30 EST
Subject: char-ready? => read-char-ready?
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 14 Jun 88 22:21:30 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
I proposed this a while back, but my proposal met with little or no
response. I propose that the name of the optional procedure
"char-ready?" be changed to "read-char-ready?", to allow for
generalization to "read-ready?", "write-char-ready?", and maybe even
"write-ready?".
I don't know about the other three, but I agree with your proposal to
rename `char-ready?'. I should have seconded this proposal the last
time -- we blew it when we originally named that procedure.
∂15-Jun-88 0755 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA seconds-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 07:55:21 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Jun 88 10:51:39 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA04071; Wed, 15 Jun 88 10:47:36 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Wed, 15 Jun 88 10:46:52 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA19221; Wed, 15 Jun 88 10:46:52 EDT
Date: Wed, 15 Jun 88 10:46:52 EDT
Message-Id: <8806151446.AA19221@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: seconds-after-J2000.0
I propose adding the function seconds-after-J2000.0.
(seconds-after-J2000.0) procedure
seconds-after-J2000.0 returns a real number giving the number of
seconds after Noon of January 1, 2000. J2000.0 is the Julian epoch of
the time origin.
∂15-Jun-88 0911 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU seconds-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 09:11:20 PDT
Received: from murren (TCP 2206400263) by MC.LCS.MIT.EDU 15 Jun 88 12:08:17 EDT
Received: by MURREN.AI.MIT.EDU; Wed, 15 Jun 88 12:11:42 edt
Date: Wed, 15 Jun 88 12:11:42 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8806151611.AA03404@murren>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: John D. Ramsdell's message of Wed, 15 Jun 88 10:46:52 EDT <8806151446.AA19221@darwin.sun.uucp>
Subject: seconds-after-J2000.0
Reply-To: hal@ai.ai.mit.edu
Posted-From: The MITRE Corp., Bedford, MA
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Wed, 15 Jun 88 10:46:52 EDT
Date: Wed, 15 Jun 88 10:46:52 EDT
I propose adding the function seconds-after-J2000.0.
(seconds-after-J2000.0) procedure
seconds-after-J2000.0 returns a real number giving the number of
seconds after Noon of January 1, 2000. J2000.0 is the Julian epoch of
the time origin.
I object to this function on the grounds that it is woefully
underspecified: do you mean UT0 (siderial time corrected to mean solar
time), UT1 (UT0 corrected for polar movement), or UT2 (UT1 corrected
for seasonal variations)? All are subject to variations from
deceleration and uneveness of the earth's rotation. Or perhaps you
mean ephemeris time? Maybe you can fix this with appropriate optional
arguments.
Even so, will be dificult to implement this in a way that admits a
complete, unambiguous specification for Scheme. Scheme programmers
who use this procedure on high-velocity spacecraft or near black holes
may encounter different timing behavior due to relativistic effects
and therefore have difficulty sharing their programs with people on
Earth. It would be difficult to prove any theorems about Scheme
programs that use this procedure.
How do the denotational semantics people handle calendar time, since
we all know that anything they do is obviously the right decision in
language design?
-- Hal
∂15-Jun-88 1044 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 10:44:50 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Jun 88 13:37:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from orbit.sun.uucp by linus.MENET (3.2/4.7)
id AA09236; Wed, 15 Jun 88 13:33:36 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Wed, 15 Jun 88 13:33:24 EDT
Received: by orbit.sun.uucp (3.2/SMI-3.0DEV3)
id AA20022; Wed, 15 Jun 88 13:33:24 EDT
Date: Wed, 15 Jun 88 13:33:24 EDT
Message-Id: <8806151733.AA20022@orbit.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Wed, 15 Jun 88 12:11:42 edt <8806151611.AA03404@murren>
Subject: days-after-J2000.0
I meant UT1. Here is a proposal for adding the function
days-after-J2000.0. Forget seconds-after-J2000.0.
(days-after-J2000.0) procedure
days-after-J2000.0 returns a real number giving the current universal
time (UT1) minus the universal time at Noon of January 1, 2000. The
unit of universal time is a mean solar day. The universal time UT1 is
the siderial time corrected to mean solar time and corrected for polar
movement. J2000.0 is the Julian epoch of the time origin.
------------------------------------------
I just want to be able to write calendar programs that would be
insensitive to the differences between UT0, UT1, and UT2.
>How do the denotational semantics people handle calendar time, since
>we all know that anything they do is obviously the right decision in
>language design?
I do not know.
John
∂15-Jun-88 1259 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 12:59:30 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 15 Jun 88 15:18:25 EDT
Received: by iuvax.cs.indiana.edu; id AA01250; Wed, 15 Jun 88 13:59:06 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Wed, 15 Jun 88 13:59:06 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: More on Full Specification
This reader sees sharks in the water...
Pavel
Me too.
There are those who like the idea of a simple, powerful, and dangerous,
language. My introduction to Scheme was via the Dan Friedman approach.
Immersed in a sea of closures, continuations, assignments and macros,
I felt very much like shark bait.
I have grown to love the simple and powerful aspects of Scheme, and realize
that danger will always lurk where there be simple, powerful beasts.
However we should do what we can to tame them without declawing them.
Paul Hudak's response made many of the points I meant to imply.
I think we should recognize forthrightly that Scheme is not a
``functional'' language. Along with first-class procedures, a feature now
shared with several languages, Scheme also has assignments and continuations.
This combination makes Scheme special. It also makes Scheme dangerous,
in the sense that they can interact in surprising ways.
Because of its power, Scheme needs a complete and understandable semantics.
Because of its simplicity, Scheme can have one.
We have approached it, but fallen shy of the mark in key areas. I should
like to see us head back in that direction ``before it is too late.''
I am not so much arguing for my specific proposals (although I did mean them
seriously), as for a move toward full specification, whatever it entails.
I think it can lead us towards simplification. As Hudak points out, the
unspecified must be specified as such.
It would perhaps be nice if procedures (and forms) done for effect did not
return values, as Pavel suggests. This however does introduce real
command procedures into Scheme, and we should then enforce their no value
status. Is it better to deal with that complication or simply let them
return reasonable values? At any rate I think it should be clear what is
returned. One possibility, if one wants to preserve the for-effect-only status
of such procedures, would be for them to all return the same useless value:
#f or #t or something new like #n (for no-value).
Would we ever really want to allow the evaluation of procedural expressions
to occur simultaneously? I am not sure there is such a thing as
``a small piece of nondeterminism,'' as Pavel also suggests.
Do we want a non-deterministic semantics?
I think the current ``arbitrary permutation'' in the semantics
is terrible, since it really doesn't reflect the intent,
which I understand to be that procedure calls may be evaluated in different
orders within the same program, and perhaps even concurrently.
As for internal definitions, one of the disturbing things about them is
that they look like top-level definitions but don't act like them.
One should remember that one of the big arguments for internal definitions
was convenience, particularly in lowering nesting levels.
Consequently such uses as
(define x (car y))
cannot really be considered invalid, and something like
(define y (z))
(define x (car y))
looks perfectly reasonable, given that all other expressions in a body
are evaluated in order.
Finally a note about implementation issues. Although, as one greatly involved
with implementing Scheme, I can understand their seduction, I think
we should fight it. First-class procedures and continuations combined with
lexical scoping, assignments and indefinite extent for variables appeared
to deliver a knockout blow to implementation efficiency. The fact that
good implementation techniques have appeared anyway is good reason not to
be too quick to worry about implementations. After all, an implementation
can do what it pleases as long as no one can tell the difference. Thus
if it can prove that order of evaluation doesn't matter, or that variables
can't be referenced before definition, it can make appropriate optimizations.
The next great step in Scheme efficiency will require extensive program
analysis anyway. I think people are still attracted to Scheme by the
structure and semantics of its powerful features, and that is what we should
concentrate on.
∂15-Jun-88 1614 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM alternate track on the char-ready? issue
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 16:14:05 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 15 Jun 88 18:54:30 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 420262; Wed 15-Jun-88 18:08:46 EDT
Date: Wed, 15 Jun 88 18:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: alternate track on the char-ready? issue
To: cph@zurich.ai.mit.edu, dyb@iuvax.cs.indiana.edu
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8806151410.AA04278@kleph>
Message-ID: <880615180828.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 15 Jun 88 10:10:14 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Date: Tue, 14 Jun 88 22:21:30 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
I proposed this a while back, but my proposal met with little or no
response. I propose that the name of the optional procedure
"char-ready?" be changed to "read-char-ready?", to allow for
generalization to "read-ready?", "write-char-ready?", and maybe even
"write-ready?".
I don't know about the other three, but I agree with your proposal to
rename `char-ready?'. I should have seconded this proposal the last
time -- we blew it when we originally named that procedure.
I strongly believe that CHAR-READY? should not be part of any Scheme standard.
It is an embarrassing timing error waiting to happen that does not do justice
to the very careful design of most other parts of this language.
It presupposes a particular model of stream use that is not always appropriate
in a shared memory multi-tasking environment. For example, on the Lisp Machine,
if you type Function Clear-Input (asynchronous clear input buffer) between the
time you do the CHAR-READY? is done and the time you try to read a character,
the attempt to read the character will hang.
I strongly think we should flush CHAR-READY? and replace it with the following
primitive:
(READ-CHAR?)
(READ-CHAR? port)
If a character is immediately available from the input PORT,
that character is returned and the PORT is updated to point
to the following character (if any). If characters are expected
to become available but none are immediately available at the
time of the call, #f is returned. If no more characters
are available, an end of file object is returned. PORT may be
omitted, in which case it defaults to the value returned by
CURRENT-INPUT-PORT.
Some other possible names are READ-CHAR-NOW, READ-CHAR-IMMEDIATELY,
MAYBE-READ-CHAR, and READ-CHAR-IF-ANY. I'm not adamant about the details
of the proposal other than that a LISTEN primitive is just plain
wrong and a TYI-NO-HANG is much more defensible...
∂15-Jun-88 1645 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU alternate track on the char-ready? issue
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 16:45:32 PDT
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 15 Jun 88 19:33:46 EDT
Received: by kleph.AI.MIT.EDU; Wed, 15 Jun 88 19:08:47 edt
Date: Wed, 15 Jun 88 19:08:47 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8806152308.AA04566@kleph>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: dyb@iuvax.cs.indiana.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Kent M Pitman's message of Wed, 15 Jun 88 18:08 EDT <880615180828.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: alternate track on the char-ready? issue
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 15 Jun 88 18:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I strongly believe that CHAR-READY? should not be part of any Scheme standard.
It is an embarrassing timing error waiting to happen that does not do justice
to the very careful design of most other parts of this language.
I agree. However, I want to point out that we already had this
argument, when we originally drafted the standard, and it was decided
that `char-ready?' was preferable to what you call `read-char?' (Jinx
fought on the side you are advocating, as I recall). I don't remember
why the decision was made as it was but I suggest that someone check
the archives so we don't fight exactly the same battle again.
∂15-Jun-88 1658 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 16:58:07 PDT
Received: from acf3.NYU.EDU (TCP 20036500015) by MC.LCS.MIT.EDU 15 Jun 88 19:40:41 EDT
Received: by acf3.NYU.EDU (5.54/25-eef)
id AA02650; Wed, 15 Jun 88 17:58:57 EDT
Date: Wed, 15 Jun 88 17:58:57 EDT
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Message-Id: <8806152158.AA02650@acf3.NYU.EDU>
To: hieb@iuvax.cs.indiana.edu, rrrs-authors@mc.lcs.mit.edu
Subject: Re: More on Full Specification
Date: Wed, 15 Jun 88 13:59:06 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: More on Full Specification
I think the current ``arbitrary permutation'' in the semantics
is terrible, since it really doesn't reflect the intent,
which I understand to be that procedure calls may be evaluated in
different orders within the same program, and perhaps even
concurrently.
No, not concurrently. E*, in the semantics, always evaluates in *some* order.
This isn't overspecification, as Paul Hudak suggests, but rather a deliberate
and desirable design decision. If we could get DAYS-AFTER-J2000.0 into the
denotational semantics our problems with PERMUTE would be gone--we could make
it truely POM-dependent.
such uses as
(define x (car y))
cannot really be considered invalid,
No one called it invalid, just bad style.
and something like
(define y (z))
(define x (car y))
looks perfectly reasonable, given that all other expressions in a body
are evaluated in order.
This can also be made to work by having LETREC's implement an applicative
order fixpoint rather than the restriction of it specified in R3RS. This
amounts to performing dependency analysis to transform the above into a LET*.
Alas, this requires static analysis which an interpreter can't afford. Some
compilers, however, already do it.
Eric
∂15-Jun-88 1850 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM A couple more details
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 18:50:43 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 15 Jun 88 21:48:20 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 420360; Wed 15-Jun-88 21:48:01 EDT
Date: Wed, 15 Jun 88 21:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A couple more details
To: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-ID: <880615214746.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
While I'm breaking my silence, I might as well note a couple of other
things that have been on my mind. (I'm pretty busy with X3J13 right now
so haven't had the time to devote to this that I might otherwise, but
maybe something here will spark some interest in someone who does have
some more time.)
* Rename "char=?" to "char=", etc.
Rationale:
a. `Symmetry' with "="
b. I think of "=" as short for "equal?", so "char=?" looks like
"char-equal??" to my eyes.
* Rename "set!" to "set".
Rationale:
It's redundant. The operation already says in English that the
operator is destructive. If you have "append" and you make a
destructive version, it makes some sense to call it either
"destructive append" or "append!". In the original T manual, I
specified that "!" was pronounced " destructively" just as I
specified that "?" was pronounced "-pee". That way people would
pronounce "zero?" as "zero-pee" and "append!" as
"append destructively" for verbal compatibility with Lisp
programmers. In the case of set, though, it feels funny to me
to say "set destructively" since there is no non-destructive
version of set.
* Rename "set-car!" to "set-car", etc.
Rationale:
As for "set!", but in these cases I would withdraw the objection
if someone proposed "set-car", etc. as a non-destructive variant
in order to motivate the destructively part:
(DEFINE (SET-CAR X Y) (CONS (CAR Y) X))
(DEFINE (SET-CDR X Y) (CONS (CAR X) Y))
...
Note: The same argument doesn't make sense for SET! above since
the non-destructive variant is not appropriately compelling
(for what I claim are deep reasons):
(DEFINE (SET X Y) Y)
* Add essential syntax:
(CALL procedure . arguments)
(STATIC identifier)
Rationale:
Among other things (I have a few more reasons I might pull out if
people took this idea seriously), these would allow the entire language
to be described in terms of a much simpler primitive syntax. eg,
(LAMBDA (X) (+ X 3))
would be shorthand for:
(LAMBDA (X) (CALL (STATIC +) (STATIC X) (QUOTE 3)))
This would be useful as we move into the time when we start doing
macro expansion, because you could provide a macroexpansion
facility that guaranteed to always give you the longhand form,
making it much easier to dispatch off of things because you would
know that every valid primitive expression in the language was
represented by a list whose car was a keyword identifying the
operation. No more of this troublesome stuff, which comes up
a lot in user code walkers:
(LET ((X (MACROEXPAND Y)))
(COND ((SYMBOL? X) ...)
((ATOM? X) ...)
((NOT (ATOM (CAR X))) ...)
((MEMBER X '(LAMBDA ...)) ...)
(ELSE ;procedure
...)))
Instead, assuming that (MACROEXPAND 'X) => (STATIC X),
(MACROEXPAND '3) => (QUOTE 3), etc., then:
(LET ((X (MACROEXPAND Y)))
(CASE (CAR X)
((QUOTE) ...)
((STATIC) ...)
((CALL) ...)
...))
∂15-Jun-88 1952 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 19:52:25 PDT
Received: from ELI.CS.YALE.EDU (TCP 30006454001) by MC.LCS.MIT.EDU 15 Jun 88 22:49:23 EDT
Received: by ELI.CS.YALE.EDU; Wed, 15 Jun 88 22:38:58 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8806160238.AA03954@ELI.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Wed Jun 15 22:36:31
Date: Wed, 15 Jun 88 22:36:24 EDT
Subject: Re: More on Full Specification
To: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>, Wed, 15 Jun 88 17:58:57 EDT
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
I think the current ``arbitrary permutation'' in the semantics
is terrible, since it really doesn't reflect the intent,
which I understand to be that procedure calls may be evaluated in
different orders within the same program, and perhaps even
concurrently.
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
No, not concurrently. E*, in the semantics, always evaluates in
*some* order. This isn't overspecification, as Paul Hudak suggests,
but rather a deliberate and desirable design decision.
I wasn't around when the decision was made, so can't say whether it
was "deliberate" or not, but in what sense is it "desireable"?
Presumably the motivation for this was to allow implementation
freedom, so why only stop half-way? My guess is that the intent was
as Robert Hieb states, except for the concurrency part (but maybe that
was in somebody's mind too). I wonder how many current
implementations permute the arguments in different ways depending on
context? Seems useful to me ... and fully within the motivation for
underspecification in the first place.
My bet is that Will, when designing the denotational semantics,
specified the underspecification in the simplest deterministic way he
could think of, and that's to use something like PERMUTE. If there
was a clean way to specify non-determinism, including the
inter-leaving of evaluations, then perhaps he would have chosen that.
(Actually, there are a couple of ways to make PERMUTE dynamic, rather
than fixed, but it gets a little bit messy...)
I guess the bottom line is that we should be VERY careful about what
things we choose to underspecify, and how. These decisions can have
radical effects on portability and correctness. I think that the
default should be full specification, and that anything left
underspecified should have a very good rationale.
-Paul
-------
∂15-Jun-88 2004 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jun 88 20:03:57 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Jun 88 22:54:40 EDT
Date: Wed, 15 Jun 88 22:54:46 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: days-after-J2000.0
To: ramsdell%linus@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 15 Jun 88 13:33:24 EDT from John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Message-ID: <398372.880615.JAR@AI.AI.MIT.EDU>
Date: Wed, 15 Jun 88 13:33:24 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
>How do the denotational semantics people handle calendar time, since
>we all know that anything they do is obviously the right decision in
>language design?
The same way you handle I/O (e.g. files and network connections), I
presume. I have seen descriptions that pass around a file system as
well as a store, but since they never seem to part company, I don't
really see the point; and anyhow, that doesn't address the nondeterminism
of external agents. Are we supposed to put quantum mechanics in our
model?
I don't think it's worth worrying about at the moment; how could any
real-life harm result from just imagining that the time and file system
are in the store, and making it an imaginary side effect to read the
time? I can't conceive of how this could be consequential, and I'd love
to know if anyone does any reasoning using a formal specification that
could get screwed up by this.
∂16-Jun-88 0216 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 02:16:05 PDT
Received: from acf3.NYU.EDU (TCP 20036500015) by MC.LCS.MIT.EDU 16 Jun 88 05:09:30 EDT
Received: by acf3.NYU.EDU (5.54/25-eef)
id AA03130; Thu, 16 Jun 88 03:45:26 EDT
Date: Thu, 16 Jun 88 03:45:26 EDT
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Message-Id: <8806160745.AA03130@acf3.NYU.EDU>
To: hudak-paul@YALE.ARPA, tiedeman@acf3.NYU.EDU
Subject: Re: More on Full Specification
Cc: rrrs-authors@mc.lcs.mit.edu
From: Paul Hudak <hudak-paul@YALE.ARPA>
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
No, not concurrently. E*, in the semantics, always evaluates in
*some* order. This isn't overspecification, as Paul Hudak suggests
,but rather a deliberate and desirable design decision.
I wasn't around when the decision was made, so can't say whether it
was "deliberate" or not, but in what sense is it "desireable"?
Presumably the motivation for this was to allow implementation
freedom, so why only stop half-way?
It would sure be nice if we could get an implicit PCALL without causing any
damage, but going the rest of the way will invalidate currently valid
code. Most of the code which would be endangered is certainly in bad style
already. Let me offer, however, a real-life example that doesn't seem too
unnatural:
(EQV? (SPLAY-TREE-ACCESS T KEY-1)
(SPLAY-TREE-ACCESS T KEY-2))
where splay trees are, of course, self-adjusting trees that may be
destructively modified when an item is retrieved. I invite you to imagine the
result of interleaving two splays on the same tree! It seems unreasonable to
insist that all Scheme programmers must follow Multilisp style standards if
their code is to be portable, and doubly so when we aren't providing any
synchronization constructs.
I wonder how many current
implementations permute the arguments in different ways depending on
context? Seems useful to me ... and fully within the motivation for
underspecification in the first place.
It is useful. My current compiler project uses it.
I think that the
default should be full specification, and that anything left
underspecified should have a very good rationale.
Yes, it seems that underspecification is never "free."
Eric
∂16-Jun-88 0653 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Dependency analysis on internal DEFINE's
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 06:53:43 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 16 Jun 88 07:40:42 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA13523; Thu, 16 Jun 88 07:35:55 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Thu, 16 Jun 88 07:35:25 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA19943; Thu, 16 Jun 88 07:35:25 EDT
Date: Thu, 16 Jun 88 07:35:25 EDT
Message-Id: <8806161135.AA19943@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Eric S. Tiedemann's message of Wed, 15 Jun 88 17:58:57 EDT <8806152158.AA02650@acf3.NYU.EDU>
Subject: Dependency analysis on internal DEFINE's
>This can also be made to work by having LETREC's implement an applicative
>order fixpoint rather than the restriction of it specified in R3RS. This
>amounts to performing dependency analysis to transform the above into a LET*.
>Alas, this requires static analysis which an interpreter can't afford. Some
>compilers, however, already do it.
I strongly agree that a dependency analysis should be done on local
defines. One simply finds the strong component of the dependency
graph and then does a topological sort on the graph in which a strong
component has been replaced by a single node. A strong component
with no cycles (a single node) maps to a LET, and other strong
components map to a LETREC. Thus both:
(define y (z))
(define x (car y))
and
(define x (car y))
(define y (z))
map to:
(let ((y (z)))
(let ((x (car y))) .....
There are linear algorithms for both topological sorting and finding
strong components.
John
PS. By the way, many pure functional programming languges do the above
analysis; see Simon L. Peyton Jones' recent book on implementing
functional programming languages.
∂16-Jun-88 1058 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP 88 Registration Forms
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 10:58:50 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 16 Jun 88 13:34:15 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA10510; Thu, 16 Jun 88 11:33:29 MDT
Received: by cons.utah.edu (5.54/utah-2.0-leaf)
id AA10812; Thu, 16 Jun 88 11:33:22 MDT
Date: Thu, 16 Jun 88 11:33:22 MDT
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8806161733.AA10812@cons.utah.edu>
To: scheme@mc.lcs.mit.edu
Subject: L&FP 88 Registration Forms
Apparently many people have not yet received the advance registration
forms from ACM. Supposedly, it was sent to all members of SIGPLAN,
SIGART, and SIGACT, along with about 250 of the people who attended
the 1986 conference (according to the Post Office, this went to 16,000
people on May 10???, the remaining that went first class and overseas
were mailed before that). Anyway, here is a pseudo electronic version
of registration form. Please provide ACM with all of this information
detailed here.
Thanks.
Bob.
====================== L&FP 88 Registration Form ====================
The registration fees for applications prior to June 24 are:
Student $75
ACM or SIG (PLAN, ART, or ACT) Member Only $250
ACM and SIG Member $225
Non-Member $290
The registration fees for applications after that date are:
Student $100
ACM or SIG (PLAN, ART, or ACT) Member Only $300
ACM and SIG Member $275
Non-Member $350
Additional banquet tickets (for students or guests) are $40
Additional luncheon tickets are $12.50
Make your own application form including
Your Name
Company/Institution
Address
Telephone
E-mail Address
Membership status in ACM and SIGPLAN/SIGART/SIGACT including
membership number
Your fee category (as described above)
Your order for any extra banquet or luncheon tickets
Total fees enclosed
Form of payment (check/credit card)
Credit card type (Mastercard, Visa, or Amer Express), number,
and signature if paying by credit card
Mailing List Restriction: (one of No Restictions, ACM and Other
Society Announcements, ACM Announcements)
If paying by check, make check payable (in US funds only!) to:
ACM LFP '88
Mail your form and payment to:
ACM LFP '88
P.O. Box 12105
Church Street Station
New York, NY 10249
∂16-Jun-88 1131 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 11:31:36 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 16 Jun 88 13:38:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA25836; Thu, 16 Jun 88 13:33:44 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Thu, 16 Jun 88 13:33:14 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA20338; Thu, 16 Jun 88 13:33:14 EDT
Date: Thu, 16 Jun 88 13:33:14 EDT
Message-Id: <8806161733.AA20338@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Wed, 15 Jun 88 12:11:42 edt <8806151611.AA03404@murren>
Subject: days-after-J2000.0
Church: Our Lady of Balanced Parentheses
Let us limit the accuracy to about one seconds worth of time.
(days-after-J2000.0) procedure
days-after-J2000.0 returns a real number giving the current universal
time (UT1) minus the universal time at Noon of January 1, 2000
accurate to within a second. The unit of universal time is a mean
solar day. The universal time UT1 is the siderial time corrected to
mean solar time and corrected for polar movement. J2000.0 is the
Julian epoch of the time origin.
∂16-Jun-88 1316 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 13:16:45 PDT
Received: from ELI.CS.YALE.EDU (TCP 30006454001) by MC.LCS.MIT.EDU 16 Jun 88 16:06:29 EDT
Received: by ELI.CS.YALE.EDU; Thu, 16 Jun 88 16:05:17 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8806162005.AA10637@ELI.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Thu Jun 16 16:02:49
Date: Thu, 16 Jun 88 16:02:45 EDT
Subject: Re: More on Full Specification
To: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>, Thu, 16 Jun 88 03:45:26 EDT
Presumably the motivation for this was to allow implementation
freedom, so why only stop half-way?
It would sure be nice if we could get an implicit PCALL without causing any
damage, but going the rest of the way will invalidate currently valid code.
I think you missed the point -- I wasn't arguing for parallel semantics.
The question was whether or not PERMUTE was overspecified, which I claim
only goes half-way even in the sequential case.
I wonder how many current implementations permute the arguments in
different ways depending on context? Seems useful to me ... and fully
within the motivation for underspecification in the first place.
It is useful. My current compiler project uses it.
Are you aware then that you are not in conformance with the report?
... It seems unreasonable to insist that all Scheme programmers must
follow Multilisp style standards if their code is to be portable, and
doubly so when we aren't providing any synchronization constructs.
I'm inclined to agree, but we're already doing that to some extent, by
requiring that portable code not depend on order-of-sequential-evaluation
of arguments. So you see it's really a matter of degree.
-Paul
-------
∂16-Jun-88 1332 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com new wording for eqv?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 13:32:38 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jun 88 16:23:55 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ap29344; 16 Jun 88 14:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa00723; 16 Jun 88 13:43 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA21507; Wed, 15 Jun 88 17:30:13 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA18571; Wed, 15 Jun 88 17:31:31 PDT
Message-Id: <8806160031.AA18571@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: new wording for eqv?
Date: 15 Jun 88 17:31:29 PDT (Wed)
From: willc@tekchips.crl
Eliminate the second and third paragraphs of section 6.2, and
eliminate the seven bullet items that follow them.
Change the description of eqv? as follows.
(eqv? obj1 obj2) essential procedure
The eqv? procedure defines a useful equivalence relation on
objects. Briefly, it returns #t if obj1 and obj2 should normally
be regarded as the same object and returns #f if they should
normally be regarded as distinct objects. This relation is left
slightly open to interpretation, but the following partial
specification of eqv? holds for all implementations of Scheme.
The eqv? procedure returns #t if:
obj1 and obj2 are both #t or both #f.
obj1 and obj2 are both symbols and both print the same
way (provided neither obj1 nor obj2 is an ``uninterned
symbol'' as alluded to in section 6.4).
obj1 and obj2 are both numbers, are numerically equal
(see =, section 6.5.4), and are either both exact or
both inexact (see section 6.5.2).
obj1 and obj2 are both characters and are the same
character according to the char=? procedure (section
6.6).
both obj1 and obj2 are the empty list.
obj1 and obj2 are pairs created at the same time by
the same call to cons, so that a set-car! operation
on obj1 will change the contents of the car field of
obj2 and vice versa, and similarly for set-cdr!.
obj1 and obj2 are vectors created at the same time by
the same call to make-vector, so that a vector-set!
operation on obj1 will change the contents of the
corresponding element of obj2 and vice versa.
obj1 and obj2 are strings created at the same time by
the same call to make-string, so that a string-set!
operation on obj1 will change the character stored at
the corresponding position of obj2 and vice versa.
obj1 and obj2 are procedures created at the same time
from the same lambda expression, so that they behave
identically.
The eqv? procedure returns #f if:
one of obj1 and obj2 is a boolean but the other is not.
one of obj1 and obj2 is a symbol but the other is not.
one of obj1 and obj2 is a number but the other is not.
one of obj1 and obj2 is a pair but the other is not.
one of obj1 and obj2 is a vector but the other is not.
one of obj1 and obj2 is a string but the other is not.
one of obj1 and obj2 is a procedure but the other is not.
one of obj1 and obj2 is #t but the other is #f.
obj1 and obj2 are symbols that do not print the same way.
one of obj1 and obj2 is an exact number and the other is an
inexact number.
obj1 and obj2 are numbers for which the = procedure returns
#f.
obj1 and obj2 are characters for which the char=? procedure
returns #f.
one of obj1 and obj2 is the empty list but the other is not.
obj1 and obj2 are pairs created at different times by
distinct calls to cons.
obj1 and obj2 are vectors created at different times by
distinct calls to make-vector, and at least one of them
has vector-length greater than zero.
obj1 and obj2 are strings created at different times by
distinct calls to make-string, and at least one of them
has string-length greater than zero.
obj1 and obj2 are procedures that would behave differently
(return a different value or have different side effects)
for some arguments.
[The first block of examples goes here, omitting the
(eq? "" "") example, which should be added to the second
block of examples.]
The following examples illustrate cases in which the above
rules do not fully specify the behavior of eqv?. In every
case, the value returned by eqv? is either #t or #f, but
which one it returns is implementation-dependent.
[The second block of examples goes here, following by the
paragraph beginning "The next set of examples shows...",
followed by the gen-counter and gen-loser examples.]
Objects of distinct types must never be regarded as the same
object, except that #f and the empty list are permitted
to be identical, and the character type need not be disjoint
from other types.
[The fourth block of examples goes here, followed by the
paragraph beginning "Since it is an error...", followed by
the fifth block of examples, followed by the note.]
∂16-Jun-88 1346 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com formal semantics of numeric constants
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 13:46:05 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jun 88 16:24:38 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aq29344; 16 Jun 88 14:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id ab00726; 16 Jun 88 13:45 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA21777; Wed, 15 Jun 88 17:38:24 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA18639; Wed, 15 Jun 88 17:39:43 PDT
Message-Id: <8806160039.AA18639@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: formal semantics of numeric constants
Date: 15 Jun 88 17:39:41 PDT (Wed)
From: willc@tekchips.crl
Someone said they'd be interested in seeing a formal semantics for numeric
constants. I'd like to see a semantics for numeric constants added to RnRS,
but I think a formal semantics is overkill. Anyway, here's my first shot
at what a formal semantics might look like. Let me know of any bugs you
find -- it hasn't been tested, or even proofread!
For those who, like me, don't really want to read this thing, the idea is
that constants are inexact if they contain any of the following:
an explicit inexactness prefix
an at-sign indicating polar representation
a decimal point
a sharp sign indicating a "don't care" digit, as in 123##
A constant may also be inexact if it contains a negative exponent;
this is implementation-dependent. Otherwise the constant is exact.
Issue: 3@0 (inexact by above rules)
Issue: 1e5 (exact by above rules)
Issue: 1e-5 (implementation-dependent by above rules)
A denotational semantics for numeric constants
There are two properties of a numeric constant in Scheme
that matter: its value (a complex number) and its exactness.
These properties correspond to the valuation functions V and
E below.
V [ <prefix R> <complex R> ] = V [ <complex R> ]
V [ <real1 R> @ <real2 R> ]
= V [ <real1 R> ] * (cos V [ <real2 R> ] + i sin V [ <real2 R> ])
V [ <real1 R> + i <real2 R> ] = V [ <real1 R> ] + i V [ <real2 R> ]
V [ <real1 R> - i <real2 R> ] = V [ <real1 R> ] - i V [ <real2 R> ]
V [ <real1 R> + i ] = V [ <real1 R> ] + i
V [ <real1 R> - i ] = V [ <real1 R> ] - i
V [ + i <real2 R> ] = i V [ <real2 R> ]
V [ - i <real2 R> ] = - i V [ <real2 R> ]
V [ + i ] = i
V [ - i ] = - i
V [ <uinteger 10> <suffix> ] = V [ <uinteger 10> ] * 10 ↑ X [ <suffix> ]
V [ . <digit>+ #* <suffix> ] = (W [ . <digit>+ ] / 10) * 10 ↑ X [ <suffix> ]
V [ <digit>+ . <digit>* #* <suffix> ] = W [ <digit>+ . <digit>* ] * 10 ↑ X [ <suffix> ]
V [ <digit>+ #* . #* <suffix> ] = W [ <digit>+ #* ] * 10 ↑ X [ <suffix> ]
V [ <uinteger1 R> / <uinteger2 R> ] = V [ <uinteger1 R> ] / V [ <uinteger2 R> ]
V [ + <ureal R> ] = V [ <ureal R> ]
V [ - <ureal R> ] = - V [ <ureal R> ]
V [ <digit R>+ #* # ] = R * V [ <digit R>+ #* ]
V [ <digit R>* <digit R> ] = R * V [ <digit R>* ] + Y [ <digit R> ]
V [ ] = 0
W [ <digit>+ #* # ] = 10 * W [ <digit>+ #* ]
W [ <digit>* <digit> ] = 10 * W [ <digit>* ] + Y [ <digit> ]
W [ ] = 0
W [ <digit(s)1>* . <digit(s)2>* ] = W [ <digit(s)1>* ] + W [ . <digit(s)2>* ]
W [ . <digit> <digit>* ] = (Y [ <digit> ] + W [ . <digit>* ]) / 10
W [ . ] = 0
X [ <exponent marker> + <digit>+ ] = W [ <digit>+ ]
X [ <exponent marker> - <digit>+ ] = - W [ <digit>+ ]
X [ <exponent marker> <digit>+ ] = W [ <digit>+ ]
Y [ 0 ] = 0
Y [ 1 ] = 1
Y [ 2 ] = 2
Y [ 3 ] = 3
Y [ 4 ] = 4
Y [ 5 ] = 5
Y [ 6 ] = 6
Y [ 7 ] = 7
Y [ 8 ] = 8
Y [ 9 ] = 9
Y [ a ] = 10
Y [ b ] = 11
Y [ c ] = 12
Y [ d ] = 13
Y [ e ] = 14
Y [ f ] = 15
E [ <radix R> #e <complex R> ] = exact
E [ <radix R> #i <complex R> ] = inexact
E [ #e <radix R> <complex R> ] = exact
E [ #i <radix R> <complex R> ] = inexact
E [ <radix R> <complex R> ] = E [ <complex R> ]
E [ <real1 R> @ <real2 R> ] = inexact (issue: exception for <real R>@0 ?)
E [ <real1 R> + i <real2 R> ] = E [ <real1 R> ] % E [ <real2 R> ]
E [ <real1 R> - i <real2 R> ] = E [ <real1 R> ] % E [ <real2 R> ]
E [ <real1 R> + i ] = E [ <real1 R> ]
E [ <real1 R> - i ] = E [ <real1 R> ]
E [ + i <real2 R> ] = E [ <real2 R> ]
E [ - i <real2 R> ] = E [ <real2 R> ]
E [ + i ] = exact
E [ - i ] = exact
E [ <uinteger 10> <exponent marker> + <digit>+ ] = exact
E [ <uinteger 10> <exponent marker> - <digit>+ ] = unspecified
E [ . <digit>+ #* <suffix> ] = inexact
E [ <digit>+ . <digit>* #* <suffix> ] = inexact
E [ <digit>+ #* . #* <suffix> ] = inexact
E [ <uinteger1 R> / <uinteger2 R> ] = exact
E [ + <ureal R> ] = E [ <ureal R> ]
E [ - <ureal R> ] = E [ <ureal R> ]
E [ <digit R>+ #* # ] = inexact
E [ <digit R>* <digit R> ] = exact
exact % exact = exact
exact % inexact = inexact
inexact % exact = inexact
inexact % inexact = inexact
Exactness is not specified for constants such as:
1000e-2
Otherwise numbers are inexact if they contain
an explicit inexactness prefix
an at-sign indicating polar representation
a decimal point
a sharp sign indicating a "don't care" digit
∂16-Jun-88 1422 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jun 88 14:22:18 PDT
Received: from acf3.NYU.EDU (TCP 20036500015) by MC.LCS.MIT.EDU 16 Jun 88 17:09:19 EDT
Received: by acf3.NYU.EDU (5.54/25-eef)
id AA06337; Thu, 16 Jun 88 17:08:20 EDT
Date: Thu, 16 Jun 88 17:08:20 EDT
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Message-Id: <8806162108.AA06337@acf3.NYU.EDU>
To: hudak-paul@YALE.ARPA
Subject: Re: More on Full Specification
Cc: rrrs-authors@mc.lcs.mit.edu
From: Paul Hudak <hudak-paul@YALE.ARPA>
I think you missed the point -- I wasn't arguing for parallel
semantics. The question was whether or not PERMUTE was overspecified,
which I claim only goes half-way even in the sequential case.
Well, someone missed the point. The record speaks for itself. Anyhow, I'm
glad to see that we don't really disagree.
[In the matter of an implementation's permuting different ways at
different times when useful...]
Are you aware then that you are not in conformance with the report?
No, I'm in conflict with the denotational semantics which the report describes
as "a closer approximation to the intended semantics than a left-to-right
evaluation would be." The discrepancy is in the report and I think everyone
would like to see it fixed.
Eric
∂17-Jun-88 0530 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 05:30:06 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 17 Jun 88 08:27:09 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from darwin.sun.uucp by linus.MENET (3.2/4.7)
id AA24517; Fri, 17 Jun 88 08:22:26 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Fri, 17 Jun 88 08:21:53 EDT
Received: by darwin.sun.uucp (3.2/SMI-3.0DEV3)
id AA20941; Fri, 17 Jun 88 08:21:53 EDT
Date: Fri, 17 Jun 88 08:21:53 EDT
Message-Id: <8806171221.AA20941@darwin.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Wed, 15 Jun 88 12:11:42 edt <8806151611.AA03404@murren>
Subject: days-after-J2000.0
Church: Our Lady of Balanced Parentheses
Another try....
(days-after-J2000.0) procedure
days-after-J2000.0 returns a real number giving the current universal
time (UT1) minus the universal time at Noon of January 1, 2000 GMT.
Small time differences are accurate to within a second. The unit of
universal time is a mean solar day. The universal time UT1 is the
siderial time corrected to mean solar time and corrected for polar
movement. J2000.0 is the Julian epoch of the time origin.
∂17-Jun-88 0811 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU parallel argument evaluation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 08:10:46 PDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 17 Jun 88 11:05:13 EDT
Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 164873; Fri 17-Jun-88 11:03:17 EDT
Date: Fri, 17 Jun 88 11:05 EDT
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Subject: parallel argument evaluation
To: hudak-paul@YALE.ARPA
cc: tiedeman@acf3.NYU.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8806162005.AA10637@ELI.CS.YALE.EDU>
Message-ID: <880617110528.3.RHH@ASPEN.LCS.MIT.EDU>
... It seems unreasonable to insist that all Scheme programmers must
follow Multilisp style standards if their code is to be portable, and
doubly so when we aren't providing any synchronization constructs.
I'm inclined to agree, but we're already doing that to some extent, by
requiring that portable code not depend on order-of-sequential-evaluation
of arguments. So you see it's really a matter of degree.
I would agree; on the other hand, the degree is quite significant.
Suppose you define a random-number-generator rand by
(define rand
(let ((seed (initial-random-seed)))
(lambda ()
(set! seed (random-update seed))
seed)))
and then you write programs like
(+ (rand) (rand))
This works fine for any sequential argument evaluation order, but the
updating of the random number seed is not safe if multiple calls to rand
are active concurrently. Lots of other cases of procedure arguments
whose evaluation involves side effects (but not in a way that breaks if
a different sequential evaluation order is used) are analogous.
If you're writing genuinely parallel code (as in Multilisp or Qlisp)
then you probably want to strongly encourage people to change their
random number generators so that it is safe for multiple random number
generations to be active concurrently. But I suspect that the Scheme
community would balk at having to do this in order to make their
programs "truly" portable. -Bert Halstead
∂17-Jun-88 0833 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: parallel argument evaluation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 08:33:34 PDT
Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 17 Jun 88 11:30:29 EDT
Received: by ATHENA.CS.YALE.EDU; Fri, 17 Jun 88 11:19:40 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8806171519.AA25761@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Fri Jun 17 11:26:09
Date: Fri, 17 Jun 88 11:26:01 EDT
Subject: Re: parallel argument evaluation
To: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Cc: tiedeman@acf3.NYU.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Robert Halstead <rhh@VX.LCS.MIT.EDU>, Fri, 17 Jun 88 11:05 EDT
I would agree; on the other hand, the degree is quite significant.
Suppose you define a random-number-generator rand by
(define rand
(let ((seed (initial-random-seed)))
(lambda ()
(set! seed (random-update seed))
seed)))
and then you write programs like
(+ (rand) (rand))
Yes, this is a good example, as was Tiedeman's. But a very small
change to your example:
(- (rand) (rand))
makes even sequential programs unportable! Sigh ... :-(
-Paul
-------
∂17-Jun-88 0908 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU parallel argument evaluation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 09:07:53 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jun 88 12:04:30 EDT
Date: Fri, 17 Jun 88 12:05:02 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: parallel argument evaluation
To: hudak-paul@YALE.ARPA
cc: tiedeman@ACF3.NYU.EDU, rrrs-authors@MC.LCS.MIT.EDU,
rhh@VX.LCS.MIT.EDU
Message-ID: <399279.880617.JAR@AI.AI.MIT.EDU>
Date: Fri, 17 Jun 88 11:26:01 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
But a very small change to your example:
(- (rand) (rand))
makes even sequential programs unportable! Sigh ... :-(
There's a big difference between "deterministic" and "portable". If
this program is only specified to return the difference of two random
numbers, then the above works fine with indeterminate order, but not
with parallel argument evaluation. Similarly, a program that
accumulates results by doing (set! foo (cons result foo)) variable may
not care in what order the results appear, so long as they do appear in
some order. So it's okay for the results to be so accumulated as side
effects of argument computations.
∂17-Jun-88 0946 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA Re: parallel argument evaluation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 09:46:18 PDT
Received: from ELI.CS.YALE.EDU (TCP 30006454001) by MC.LCS.MIT.EDU 17 Jun 88 12:44:04 EDT
Received: by ELI.CS.YALE.EDU; Fri, 17 Jun 88 12:42:44 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8806171642.AA17986@ELI.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Fri Jun 17 12:40:15
Date: Fri, 17 Jun 88 12:40:08 EDT
Subject: Re: parallel argument evaluation
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>, Fri, 17 Jun 88 12:05:02 EDT
There's a big difference between "deterministic" and "portable".
Yes, good point, which I agree with.
-Paul
-------
∂17-Jun-88 1005 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU char-ready? => read-char-ready?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 10:05:14 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jun 88 13:02:16 EDT
Date: Fri, 17 Jun 88 13:03:18 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: char-ready? => read-char-ready?
To: dyb@IUVAX.CS.INDIANA.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 14 Jun 88 22:21:30 EST from R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-ID: <399322.880617.JAR@AI.AI.MIT.EDU>
I wouldn't mind changing the name, but READ-CHAR-READY? isn't good
English; READY-TO-READ-CHAR? would be better. (Or how about ((READY-TO?
READ-CHAR) port)? Just kidding.) However, I agree with KMP that the
functionality is wrong and that a TYI-NO-HANG-like procedure is
preferable. I can't remember why we didn't do that back when it would
have been easy. Maybe a resonable name for that would be
READ-CHAR-IF-READY.
I would check the archives now, but the disk drive that carries that
pack has been having troubles. I'll get them off of backup tape, unless
either someone remembers, or someone has access to the archives and can
do a search.
∂17-Jun-88 1017 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Online copy of the RR..R report?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 10:17:47 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jun 88 13:07:07 EDT
Date: Fri, 17 Jun 88 13:08:23 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Online copy of the RR..R report?
To: "STEVER@IVORY.S4CC.SYMBOLICS.COM"@AI.AI.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 14 Jun 88 11:18 EDT from Stephen Robbins <Stever@IVORY.S4CC.Symbolics.COM>
Message-ID: <399323.880617.JAR@AI.AI.MIT.EDU>
Date: Tue, 14 Jun 88 11:18 EDT
From: Stephen Robbins <Stever@IVORY.S4CC.Symbolics.COM>
To: scheme@mc.lcs.mit.edu
Re: Online copy of the RR..R report?
Is there an online copy of the Revised↑n Report available
for internet FTP?
It appears that you can connect to ZURICH.AI.MIT.EDU, log in as
anonymous, and get the file pub/r3rs.tar. Be sure to set binary mode
first, as the file is a unix "tape archive" file. If you don't have
software to read such things, send mail to scheme-request@MC and
something can probably be worked out. (I think it may exist in a
publicly accessible location on PREP.)
∂17-Jun-88 1056 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU Re: parallel argument evaluation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 10:56:07 PDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 17 Jun 88 13:10:50 EDT
Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 164930; Fri 17-Jun-88 13:09:50 EDT
Date: Fri, 17 Jun 88 13:12 EDT
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Subject: Re: parallel argument evaluation
To: hudak-paul@YALE.ARPA
cc: rhh@VX.LCS.MIT.EDU, tiedeman@acf3.NYU.EDU,
rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8806171519.AA25761@ATHENA.CS.YALE.EDU>
Message-ID: <880617131203.5.RHH@ASPEN.LCS.MIT.EDU>
Yes, this is a good example, as was Tiedeman's. But a very small
change to your example:
(- (rand) (rand))
makes even sequential programs unportable! Sigh ... :-(
True, depending slightly, I suppose, as to whether you consider drawing
different elements out of the same statistical distribution to be a
violation of portability! Seriously, though, if you have procedures
that, as a side effect, count the number of times they are called, or
perform similar side effects that may not even affect what is returned
directly as a value, evaluating arguments genuinely in parallel requires
a much tighter coding style than just evaluating them sequentially
according to some unspecified permutation... -Bert
∂17-Jun-88 1148 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU new wording for eqv?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 11:48:23 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jun 88 13:50:39 EDT
Date: Fri, 17 Jun 88 13:51:49 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: new wording for eqv?
To: "WILLC@TEKCHIPS.CRL"@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 15 Jun 88 17:31:29 PDT (Wed) from willc@tekchips.crl
Message-ID: <399349.880617.JAR@AI.AI.MIT.EDU>
I approve of this. I'm not sure it's complete, but I suspect it's close
enough for all practical purposes.
Nothing is said about quoted structure; is this because the description
of QUOTE says enough?
I'm not happy about "print the same way", because printing is poorly
defined. I'd rather say "STRING=? of SYMBOL->STRING of obj1 and obj2 is
true".
Also, I don't think it specifies to what the following MAY evaluate:
(letrec ((f (lambda () (if (eqv? f g) 'both 'f)))
(g (lambda () (if (eqv? f g) 'both 'g))))
(eqv? f g))
Certainly, if F and G have different behavior, then the call to EQV? must
return false; but the question of whether they have different behavior
depends on what EQV? does. If I consider the report as a predicate to be
applied to <implementation, program, program's-input> tuples to
determine whether a particular implementation conforms on that program
with that input, then the report itself is underspecified. (Of course
conformance may not be a computable function, but that doesn't
bother me.)
Note that
(letrec ((f (lambda () (if (eqv? f g) 'f 'both)))
(g (lambda () (if (eqv? f g) 'g 'both))))
(eqv? f g))
isn't a problem since a proof by contradiction gives the answer:
if they are EQV?, then they do the same thing [def. of EQV?], which means
they do different things [def. of F & G], contradiction; therefore they
cannot be EQV?.
Should we add a caveat somewhere to the effect that if conformance
cannot be refuted, then it holds? Hmm, then if refutability cannot
be refuted, then, uhh...
∂17-Jun-88 1204 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: char-ready? => read-char-ready?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 12:04:06 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 Jun 88 14:39:51 EDT
Received: by iuvax.cs.indiana.edu; id AA18514; Fri, 17 Jun 88 13:16:09 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Fri, 17 Jun 88 13:16:09 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: char-ready? => read-char-ready?
>I am in favor of the change, and I like Jonathan's suggestion to use the
>name "read-char-if-ready".
>
>Kent
Oops---Carl Bruggeman just pointed out that this does not generalize
easily to "read-if-ready". At least, "read-if-ready" would require
an additional argument, namely an object to return if nothing is
ready. So, the change to "read-char-if-ready" is acceptable to me
based on Pitman's comments, though it isn't as nice as I thought at
first. Will seemed to be refuting Kent's claim that "read-char?" is
better for multiprocessing---Will, if you remember your thoughts,
maybe you can explain a little bit further.
Kent
∂17-Jun-88 1214 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: char-ready? => read-char-ready?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 12:12:54 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 17 Jun 88 14:40:28 EDT
Received: by iuvax.cs.indiana.edu; id AA18003; Fri, 17 Jun 88 13:07:39 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Fri, 17 Jun 88 13:07:39 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: char-ready? => read-char-ready?
The only references to TYI-NO-HANG I can find in my archive, which I
believe goes all the way back, is contained in the following note
from Will Clinger, who quotes from an earlier note from Kent Pitman:
>KMP:
> Also on p30, it seems to me that the notion of CHAR-READY? is not a
> useful one. It's subject to timing errors in multi-processed systems
> and/or systems which allow asynchronous interrupts. The Lisp Machine's
> TYI-NO-HANG paradigm is much better, since it has a more test-and-set
> feel to it and is more easy to use reliably. I suggest that CHAR-READY?
> should be flushed and replaced by a READ-CHAR? which returns either a
> character if one is ready, or NIL otherwise. This gets you out of the
> bind with rubbing out stuff that CHAR-READY? has noticed, which is really
> an awful crock. I believe that TYI-NO-HANG will interact satisfactorily
> with Lispm-style rubout handlers.
>
>To some extent I agree with this, but I don't think READ-CHAR? by itself
>is any better for multi-processing than CHAR-READY?.
>
>Peace, Will
I am in favor of the change, and I like Jonathan's suggestion to use the
name "read-char-if-ready".
Kent
∂17-Jun-88 1314 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM new wording for eqv?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 13:13:57 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 17 Jun 88 16:11:17 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 421293; Fri 17-Jun-88 16:09:56 EDT
Date: Fri, 17 Jun 88 16:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: new wording for eqv?
To: JAR@AI.AI.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8806160031.AA18571@tekchips.CRL.TEK.COM>,
<399349.880617.JAR@AI.AI.MIT.EDU>
Message-ID: <880617160937.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 15 Jun 88 17:31:29 PDT (Wed)
From: willc@tekchips.crl
... obj1 and obj2 are pairs created at the same time by
the same call to cons, ...
... obj1 and obj2 are vectors created at the same time by
the same call to make-vector, ...
etc.
If an object satisfied all other properties of a vector but was not
created by make-vector (eg, was pre-allocated with the system or created
by some internal routine in the process of loading or some such) would
EQV? not be required to return T? I feel funny about defining things in
terms of the operator that does the creation unless you say that no
other operator is permitted to do such creation.
I am also uncomfortable with the phrase "at the same time". Either it
is redundant with "by the same call" or else it is insufficient. If "the
same call" means the dynamic invocation of a function at runtime as
opposed to the lexical reference to the call on paper, then I assert
that "by the same call" is simply redundant. We often speak loosely of a
function returning "more than once" when people play fun games with
generalized catch but I don't think we ever talk about two calls to the
same continuation as being the same "call".
On the other hand, if you think "call" refers to a lexical reference
(which i hope you don't), then if you worry about multiprocessing (and
yes, here i'm for once being careful about my wording), there is a
concern about whether two calls can really occur at the same time (ie,
what is the granularity of time and/or does it matter that temporal
coincidence cannot be observed and you have to just always worry that it
might have happened), so you need to speak about control threads or "the
same place" (ie, same processor) or something more.
Also, even with Jonathan's fixes to the symbol clause to remove the
reference to printing, you still need to address gensyms. I suggest
that once you figure out how to correct the wordings I'm grumbling about
above, you do the same thing for symbols as you did with lists, etc.
That is:
If the symbols are interned, then <<stuff with jonathan's fixes>>
If the symbols are not interned, then <<something about how they
were created by the same call to the function which makes an
uninterned symbol>>.
I observe as an aside also that your description is somewhat
meta-circular, though perhaps not enough to worry about here. You
effectively begin by saying that EQV? computes whether two things
are distinct (for which i read "not the same"), and yet the
terminology uses the word "the same" all over the place. That is,
you talk about "the same time" and "the same call". In my mind,
flags go up as I try to decide what these phrases mean since I'm
in the middle of defining what that means. Fortunately, I have other
knowledge to appeal to, but it does leave me wondering whether if
people can be relied on to use such other knowledge, perhaps they
could also be relied upon to just understand just the first
paragraph in the absence of all the elaboration. I'm not proposing
any change here -- I'm just being amused. This is the sort of things
that must have driven Webster and his successors nuts...
∂17-Jun-88 1350 @MC.LCS.MIT.EDU:gls@Think.COM days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 13:49:59 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 17 Jun 88 16:38:49 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 17 Jun 88 16:45:37 EDT
Received: by kali.think.com; Fri, 17 Jun 88 16:45:34 EDT
Date: Fri, 17 Jun 88 16:45:34 EDT
From: gls@Think.COM
Message-Id: <8806172045.AA14888@kali.think.com>
To: ramsdell%linus@mitre-bedford.arpa
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: John D. Ramsdell's message of Wed, 15 Jun 88 13:33:24 EDT <8806151733.AA20022@orbit.sun.uucp>
Subject: days-after-J2000.0
Posted-From: The MITRE Corp., Bedford, MA
From: John D. Ramsdell <ramsdell%linus@MITRE-BEDFORD.ARPA>
Posted-Date: Wed, 15 Jun 88 13:33:24 EDT
Date: Wed, 15 Jun 88 13:33:24 EDT
I meant UT1. Here is a proposal for adding the function
days-after-J2000.0. Forget seconds-after-J2000.0.
Here is a proposal for seconds-after-J2000.0 (inspired by Hal):
(seconds-after-J2000.0) procedure
seconds-after-J2000.0 returns a real number equal to -946684800 plus
whatever time(0) feels like returning on your Unix system that day.
--Quux
∂17-Jun-88 1537 @MC.LCS.MIT.EDU:gls@Think.COM new wording for eqv?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 15:37:13 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 17 Jun 88 18:15:06 EDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 17 Jun 88 18:21:03 EDT
Received: by kali.think.com; Fri, 17 Jun 88 18:20:58 EDT
Date: Fri, 17 Jun 88 18:20:58 EDT
From: gls@Think.COM
Message-Id: <8806172220.AA14999@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: JAR@ai.ai.mit.edu, willc%tekchips.tek.com@relay.cs.net,
KMP@stony-brook.scrc.symbolics.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Kent M Pitman's message of Fri, 17 Jun 88 16:09 EDT <880617160937.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: new wording for eqv?
Date: Fri, 17 Jun 88 16:09 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I observe as an aside also that your description is somewhat
meta-circular, though perhaps not enough to worry about here. You
effectively begin by saying that EQV? computes whether two things
are distinct (for which i read "not the same"), and yet the
terminology uses the word "the same" all over the place.
Plus ca change, plus c'est la meme chose.
∂17-Jun-88 1718 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Re: Dependency analysis on internal DEFINE's
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 17:18:48 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Jun 88 20:15:55 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab18564; 17 Jun 88 19:35 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa01518; 17 Jun 88 19:30 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA14094; Fri, 17 Jun 88 14:39:52 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA21656; Fri, 17 Jun 88 14:41:03 PDT
Message-Id: <8806172141.AA21656@tekchips.CRL.TEK.COM>
To: ramsdell%linus@MITRE-BEDFORD.ARPA, tiedeman@ACF3.NYU.EDU
Cc: rrrs-authors@mc.lcs.mit.edu, willc@tekchips.crl
Subject: Re: Dependency analysis on internal DEFINE's
In-Reply-To: Your message of Thu, 16 Jun 88 07:35:25 EDT.
<8806161135.AA19943@darwin.sun.uucp>
Date: 17 Jun 88 14:41:01 PDT (Fri)
From: willc@tekchips.crl
I guess I don't understand what is being proposed, because it doesn't look
computable to me. Here are the proposals, followed by a couple of examples
that illustrate my lack of understanding.
[Tiedeman:]
This can also be made to work by having LETREC's implement an applicative
order fixpoint rather than the restriction of it specified in R3RS. This
amounts to performing dependency analysis to transform the above into a LET*.
Alas, this requires static analysis which an interpreter can't afford. Some
compilers, however, already do it.
[Ramsdell:]
I strongly agree that a dependency analysis should be done on local
defines. One simply finds the strong component of the dependency
graph and then does a topological sort on the graph in which a strong
component has been replaced by a single node.
Example 1:
(let ((x '(a b c)))
(define y
(list (lambda (a) (cons a z)) x))
(define z
(list (lambda (a) (cons y a)) x))
(append y z))
This is allowed by the wording in the R3RS, and returns
(#<PROCEDURE> (a b c) #<PROCEDURE> (a b c)). Presumably it would
also be allowed by the new proposal and would return the same thing.
If not, the new proposal would not be a generalization of the current
state of affairs since it would be less general in this case.
Example 2:
(let ((x '(a b c)))
(define y
(map (lambda (a) (cons a z)) x))
(define z
(map (lambda (a) (cons y a)) x))
(append y z))
This is not allowed by the wording in the R3RS. It signals an error
in MacScheme, and probably does something similar in most other
implementations. I do not know whether it would be allowed by the
proposal. If it would be allowed, what would it return? If it is
not allowed, then how can the proposal possibly be implemented while
still allowing separate compilation for procedures like list and map?
[Ramsdell:]
PS. By the way, many pure functional programming languges do the above
analysis; see Simon L. Peyton Jones' recent book on implementing
functional programming languages.
I understand how to implement general fixed points for non-strict
languages, which are the kind that Peyton Jones is concerned with. The
thing I don't understand is how an "applicative order" fixed point can
be a generalization of the current state of affairs while remaining
computable through static analysis.
Peace, Will
∂17-Jun-88 1729 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Re: More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 17:29:39 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Jun 88 20:26:49 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab18657; 17 Jun 88 19:42 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa01566; 17 Jun 88 19:38 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA06635; Fri, 17 Jun 88 13:12:27 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA20610; Fri, 17 Jun 88 13:13:42 PDT
Message-Id: <8806172013.AA20610@tekchips.CRL.TEK.COM>
To: tiedeman@ACF3.NYU.EDU, hudak-paul@YALE.ARPA, hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: More on Full Specification
In-Reply-To: Your message of Thu, 16 Jun 88 03:45:26 EDT.
<8806160745.AA03130@acf3.NYU.EDU>
Date: 17 Jun 88 13:13:40 PDT (Fri)
From: willc@tekchips.crl
No, not concurrently. E*, in the semantics, always evaluates in
*some* order. This isn't overspecification, as Paul Hudak suggests
,but rather a deliberate and desirable design decision.
I wasn't around when the decision was made, so can't say whether it
was "deliberate" or not, but in what sense is it "desireable"?
The decision was made deliberately, and the argument that carried the day
for requiring that the evaluation happen in some unspecified but sequential
order is the fact that code such as Eric's splay-tree example would break in
the presence of concurrent evaluation unless it was protected by critical
sections, which nobody wanted to deal with. I was the pretty much the only
person at Brandeis who really wanted to allow concurrent evaluation.
My reading of the report is that the requirement for sequential execution
makes it illegal to evaluate the common subexpression (car x) only once in
the following expression unless it can be proved that at least one of the
procedures goo and moo do not change the car field of x:
(foo (goo (car x)) (moo (car x)))
My bet is that Will, when designing the denotational semantics,
specified the underspecification in the simplest deterministic way he
could think of, and that's to use something like PERMUTE. If there
was a clean way to specify non-determinism, including the
inter-leaving of evaluations, then perhaps he would have chosen that.
This is correct. I felt that Scheme is so close to a deterministic
language that the greater accuracy of a non-deterministic semantics
was less important that the greater clarity of a deterministic semantics.
I guess the bottom line is that we should be VERY careful about what
things we choose to underspecify, and how. These decisions can have
radical effects on portability and correctness. I think that the
default should be full specification, and that anything left
underspecified should have a very good rationale.
I agree with this and I generally agree with Robert Hieb's analysis.
I happen to think, however, that the three concrete underspecifications
that Hieb proposed to fix (value returned by side-effecting procedures,
order of evaluation of arguments, order of evaluation of definitions)
are among the most justified underspecifications in all of Scheme. Each
of these underspecifications concerns something that programmers ordinarily
do not care about because it doesn't matter; they have the effect of
requiring programmers to write some explicit code in the exceptional case
when they do want to use a specific value or order of evaluation. If
these underspecifications were "fixed", programs would be harder to read
because you would have to assume that the order matters whenever you see
a procedure call or internal definitions. As things stand now, you know
the order doesn't matter and this fact makes it easier to understand the
program.
In my opinion, the language would be improved if side-effecting procedures
had to return #!unspecified. This issue is a little different from the
order of evaluation of arguments and the order of definitions because it
is often (i.e. except for tail-recursive positions) obvious that the value
returned by a side-effecting procedure is just thrown away. Furthermore we
probably could standardize on some useless value like #!unspecified or 34
if only we could agree, but the perceived need for compatibility with
previous implementations or with Common Lisp makes it difficult for us to
agree.
Peace, Will
∂17-Jun-88 1740 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl Re: days-after-J2000.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jun 88 17:40:25 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Jun 88 20:36:33 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa18716; 17 Jun 88 19:49 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa01620; 17 Jun 88 19:44 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA02104; Fri, 17 Jun 88 12:22:39 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA20045; Fri, 17 Jun 88 12:23:56 PDT
Message-Id: <8806171923.AA20045@tekchips.CRL.TEK.COM>
To: ramsdell%linus@MITRE-BEDFORD.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: days-after-J2000.0
In-Reply-To: Your message of Fri, 17 Jun 88 08:21:53 EDT.
<8806171221.AA20941@darwin.sun.uucp>
Date: 17 Jun 88 12:23:54 PDT (Fri)
From: willc@tekchips.crl
Tongue-in-cheek implementation note to be added to the days-after-J2000.0
proposal:
On systems that lack time-keeping hardware, this procedure may query
an operator interactively. Authors of portable code should be aware
that this is likely to be an slow operation.
∂18-Jun-88 0057 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Lisps for Parallel Machines
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jun 88 00:57:29 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 18 Jun 88 03:51:58 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA02927@BLOOM-BEACON.MIT.EDU>; Sat, 18 Jun 88 03:39:28 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Jun 88 05:53:56 GMT
From: nyser!cmx!billo@itsgw.rpi.edu (Bill O)
Organization: Northeast Parallel Architectures Center, Syracuse NY
Subject: Parallel Lisps for Parallel Machines
Message-Id: <533@cmx.npac.syr.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
There has been quite a bit of interest expressed in this group (and
others) regarding parallel Lisps for parallel machines. I have been
one of the people expressing interest, and am very thankful for all of
you in Netland who helped me find the information I needed. I
promised to post a summary of my findings, but once I started writing,
the summary turned into a small technical report. This report has now
been published in our (Northeast Parallel Architectures Center)
newsletter so, rather than chew-up net bandwidth more than I already
have, I would like to offer to send the report to anyone who is
interested. Just email your Snail Mail address (you know, the one
with street names, zip codes, and the like) to our newsletter editor
(it's ok, I asked her if I could do this) at:
editor@cmx.npac.syr.edu
Please don't send your request to me, I'll just have to forward it to
the editor.
If you have trouble getting your email through, you could always try a
postcard or letter addressed to:
Newsletter Editor
NPAC
250 Machinery Hall
Syracuse University
Syracuse NY 13244
Also, please feel free to request a subscription even if your interest
in parallel computation is less specific than Lisp. Each issue (10
per year) has a technical report on some aspect of parallel
computation.
Here is what's covered in my report:
1) a brief introduction to Lisp. Sorry to all you Lispers (hi Bjorn) --
you'll just have to skip this section of the report.
2) an inordinately brief treatment of automatically parallelizing Lisps,
like Parcel (for the Alliant), and Lisps with explicit synchronization
mechanisms, like ZLISP (for the Ultracomputer).
3) fuller treatments of QLisp (Alliant), Multilisp (Encore Multimax), and
*Lisp (Connection Machine).
4) mere mention of Multischeme, Schemes and Lisps for the BBN Butterfly,
Linda Lisp (which is commercially available for transputers),
CM Lisp (Connection Machine) and Paralation Lisp (Connection Machine,
and possibly other architectures).
5) a relatively complete bibliography covering all of the above.
(Aside: I have heard that at this summer's ACM Parallel Processing
conference there will be a paper by Carriero and Gelernter (et al?)
mentioning Linda-based Lisp. I couldn't get the details in time to
include the reference in my bibliography.)
Please note that the amount of space devoted in my tech. report to any
given version of Lisp is not correlated with the importance of that
version of Lisp. The only correlation is with my ignorance, combined
with time and space restrictions. Also note that the mapping from
Lisps to machines isn't really a partial function as seems to be
implied by the above list -- those are just the high spots.
The tech. report does not list the email addresses of whom you need to
contact in order to get these Lisps, but if you send me a message (at
billo@cmx.npac.syr.edu) saying which one(s) you're interested in, I'll
send you any addresses that seem appropriate. I think posting them
might be a bit presumptuous of me.
If you know of any parallel Lisps not mentioned above, I would
appreciate your letting me know. And thanks again to all those who
responded to my parallel Lisp posting several weeks ago. Sorry for
being so slow with my summary -- been a tad busy.
Bill O'Farrell, Northeast Parallel Architectures Center at Syracuse University
∂18-Jun-88 0417 @MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU Re: Dependency analysis on internal DEFINE's
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jun 88 04:17:48 PDT
Received: from acf3.NYU.EDU (TCP 20036500015) by MC.LCS.MIT.EDU 18 Jun 88 07:15:21 EDT
Received: by acf3.NYU.EDU (5.54/25-eef)
id AA20656; Sat, 18 Jun 88 07:13:58 EDT
Date: Sat, 18 Jun 88 07:13:58 EDT
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
Message-Id: <8806181113.AA20656@acf3.NYU.EDU>
To: ramsdell%linus@MITRE-BEDFORD.ARPA, tiedeman@ACF3.NYU.EDU,
willc@tekchips.crl
Subject: Re: Dependency analysis on internal DEFINE's
Cc: rrrs-authors@mc.lcs.mit.edu
From: willc@tekchips.crl
I guess I don't understand what is being proposed, because it doesn't
look computable to me. Here are the proposals, followed by a couple
of examples that illustrate my lack of understanding.
[Tiedeman:]
This can also be made to work by having LETREC's implement an
applicative order fixpoint rather than the restriction of it
specified in R3RS. This amounts to performing dependency analysis
to transform the above into a LET*. Alas, this requires static
analysis which an interpreter can't afford. Some compilers, however,
already do it.
I wasn't actually making a proposal, just using the idea for purposes of
conceptual ellucidation. However, I'd like to try to answer your questions.
I used the term "the applicative order fixpoint" because I think what I have
in mind is the most general fixpoint allowed by applicative order evaluation
(I could well be wrong.) and I'll continue to use it in describing what I
meant. I'll refer to the behavior specified in the report as a "R3RS
fixpoint."
The only place I fault R3RS fixpoints is where they are used for LETREC's that
don't involve mutual recursion among all the bindings. Such LETREC's can be
broken up into subsets of mutually recursive bindings (i.e. the condensation
of the LETREC's dependency graph.) These subsets can further be ordered by
their interdependencies (by topologically sorting the condensation) and then
implemented as nested LETREC's (or LET's when they have but one binding which
is non-recursive.) Since all the LETREC's now represent true recursions we
can safely treat them as R3RS fixpoints. This treatment of LETREC's is a
generalization of R3RS fixpoints.
Here's an example of a applicative order fixpoint which R3RS wouldn't handle:
(letrec ((x 2)
(y (+ x 2)))
....)
which, by the above method, is the same as:
(let ((x 2))
(let ((y (+ x 2)))
....)
In both of your examples the DEFINE's are mutually recursive and so R3RS
semantics would be followed.
Note, however...
Example 2:
(let ((x '(a b c)))
(define y
(map (lambda (a) (cons a z)) x))
(define z
(map (lambda (a) (cons y a)) x))
(append y z))
This is not allowed by the wording in the R3RS.
According to R3RS this is "undefined, and an error may be signalled." Is
"undefined" defined in the report? Presumably the wording was designed to
leave room for the plethora of "compatible extensions" out there--sometimes
more than one in the same implementation. Ceteris paribus I would prefer that
it were "an error."
...The
thing I don't understand is how an "applicative order" fixed point can
be a generalization of the current state of affairs while remaining
computable through static analysis.
I hope I've made this clear. Whether the applicative order fixpoint is
actually defined for any given LETREC is, of course, not computable. You can,
however, always set it up in linear time.
Eric
∂20-Jun-88 0810 @MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU Meetings
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Jun 88 08:10:21 PDT
Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 20 Jun 88 11:07:36 EDT
Message-ID: <77793@SAIL.Stanford.EDU>
Date: 20 Jun 88 0807 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Meetings
To: rrrs-authors@MC.LCS.MIT.EDU
I will attend the Sunday Scheme meeting but not the IEEE meeting.
-rpg-
∂21-Jun-88 0943 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Optionals, version 1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88 09:43:25 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Jun 88 12:37:20 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ae06129; 21 Jun 88 10:44 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa00203; 21 Jun 88 10:27 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA11349; Mon, 20 Jun 88 14:30:34 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA08006; Mon, 20 Jun 88 14:31:51 PDT
Message-Id: <8806202131.AA08006@tekchips.CRL.TEK.COM>
To: JAR@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Optionals, version 1
Date: 20 Jun 88 14:31:48 PDT (Mon)
From: willc@tekchips.crl
This should be added to section 4.1.4, "Lambda expressions".
[At the end of the list of forms that the <Formals> may take:]
Some implementations support three more alternatives for the <Formals>:
\item{$\bullet$}{
(<variable_1> ... <variable_k> #!optional <variable_{k+1}> ...):
The variables that precede the special #!optional flag are {\it required}
formal arguments, and the variables that follow the #!optional flag are
{\it optional} formal arguments. There must be at least as many actual
arguments as there are required arguments, and there must be no more actual
arguments than there are required and optional arguments together. The actual
arguments are matched against the formal arguments from left to right, and are
stored in the bindings of the corresponding variables. If optional formal
arguments are left over after the actual arguments have been matched up against
the other formal arguments, then a special default object is stored in the
bindings of those left-over variables. See the default-object? procedure.
}
\item{$\bullet$}{
(<variable_1> ... <variable_k> #!optional <variable_{k+1}> ...
<variable_{n-1}> . <variable_n>):
The #!optional flag may be used in combination with a space-delimited period
before the last variable. In this case there must be at least as many actual
arguments as there are required arguments, but there is no upper limit on the
number of actual arguments. If the number of actual arguments is less than n,
then an empty list will be stored in the binding of <variable_n>. Otherwise
a newly allocated list of the actual arguments left over after all the other
actual arguments have been matched up against the other formal arguments will
be stored in the binding of <variable_n>.
}
\item{$\bullet$}{
A #!rest flag may be used in place of a space-delimited period before the
last variable. The #!rest flag is equivalent to a space-delimited period
in such a context.
}
(let ((f (lambda (x #!optional base)
(expt (if (default-object? base) 2 base) x))))
(list (f 10) (f 4 3))) ==> (1024 81)
[The following probably goes in section 6.9, "Control features".]
(default-object? obj) procedure
Returns #t if obj is a default object such as is supplied for optional
arguments that have no corresponding actual argument. (See lambda, section
4.1.4.) Otherwise returns #f.
((lambda (#!optional x y z) (default-object? z)) 1 4) ==> #t
((lambda (#!optional x y z) (default-object? z)) 1 4 9) ==> #f
∂21-Jun-88 0953 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com Multiple values, version 1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88 09:53:38 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Jun 88 12:37:28 EDT
Received: from relay2.cs.net by RELAY.CS.NET id af06129; 21 Jun 88 10:44 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa00209; 21 Jun 88 10:28 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA11303; Mon, 20 Jun 88 14:28:48 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA07985; Mon, 20 Jun 88 14:30:05 PDT
Message-Id: <8806202130.AA07985@tekchips.CRL.TEK.COM>
To: JAR@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Multiple values, version 1
Date: 20 Jun 88 14:30:02 PDT (Mon)
From: willc@tekchips.crl
This probably goes in section 6.9, "Control features".
(values obj1 ...) procedure
Returns its arguments as "multiple return values". Most continuations ignore
all but the first return value, but the with-values procedure can create a
continuation that will use all the values being returned. It is an error to
return zero values to an continuation that expects one. See with-values.
(let ((x (values 'a 'b 'c 'd))) x) ==> a
(let ((x (values))) x) ==> error
(with-values thunk proc) procedure
Thunk must be a procedure of no arguments and proc must be a procedure. The
thunk is called with no arguments, and all of its return values, not just the
first, are passed as arguments to proc. See values.
(with-values (lambda () (values 3 4 5)) +) ==> 12
(with-values (lambda () (values 'a 'b 'c)) list) ==> (a b c)
(with-values (lambda () (values 'a)) list) ==> (a)
(with-values (lambda () (values)) list) ==> ()
(with-values (lambda () (values))
(lambda (x) (list x))) ==> error
(letrec ((stats (lambda (name)
(case name
((henry) (values 480 100 14 0 4))
((george) (values 400 90 20 2 5))
(else (values 0 0 0 0 0))))))
(with-values (lambda () (stats 'henry))
(lambda (atbats singles doubles triples homeruns)
(/ (+ singles (* 2 doubles) (* 3 triples) (* 4 homeruns))
(max 1 atbats)))))
==> 3/10
∂21-Jun-88 1004 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com eqv? version 2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88 10:03:52 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Jun 88 12:37:39 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ag06129; 21 Jun 88 10:44 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa00211; 21 Jun 88 10:28 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA11287; Mon, 20 Jun 88 14:26:45 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA07941; Mon, 20 Jun 88 14:28:01 PDT
Message-Id: <8806202128.AA07941@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: eqv? version 2
Date: 20 Jun 88 14:27:59 PDT (Mon)
From: willc@tekchips.crl
The following is my second version of the eqv? proposal, with the following
changes to address issues raised by Kent Pitman:
eqv? on symbols is now defined in terms of string=? and symbol->string?
instead of how the symbols print.
eqv? on pairs, vectors, and strings is now defined in terms of the
locations referred to by these objects instead of their creation. This
makes the description more precise but requires people to understand the
domain equations and semantic equations.
(Incidentally, the formal semantics is incomplete in that it lacks axioms,
for example, that say that for any two pairs pair1 = <car1, cdr1> and
pair2 = <car2, cdr2>, one of the following must be true:
1. car1 = car2 & cdr1 = cdr2 & car1 != cdr1
2. car1 != car2 & cdr1 != cdr2 & car1 != cdr1 & car2 != cdr2
The formal semantics also lacks axioms to guarantee that, for example,
pairs never overlap with vectors. I realized all this when I was writing
down the formal semantics, but didn't try to put it in because I felt
that people wanted the formal semantics to serve as an aid to
understanding the English descriptions rather than as a specification
in its own right. Jonathan simplified the semantics further while preparing
it for SIGPLAN Notices.)
-------------------------------------------------------------------------------
Eliminate the second and third paragraphs of section 6.2, and
eliminate the seven bullet items that follow them.
Change the description of eqv? as follows.
(eqv? obj1 obj2) essential procedure
The eqv? procedure defines a useful equivalence relation on
objects. Briefly, it returns #t if obj1 and obj2 should normally
be regarded as the same object and returns #f if they should
normally be regarded as distinct objects. This relation is left
slightly open to interpretation, but the following partial
specification of eqv? holds for all implementations of Scheme.
The eqv? procedure returns #t if:
obj1 and obj2 are both #t or both #f.
obj1 and obj2 are both symbols and
(string=? (symbol->string obj1) (symbol->string obj2))
is true. (Note: This assumes that neither obj1 nor obj2 is an ``uninterned
symbol'' as alluded to in section 6.4. This report does not presume to
specify the behavior of eqv? on implementation-dependent extensions.)
obj1 and obj2 are both numbers, are numerically equal
(see =, section 6.5.4), and are either both exact or
both inexact (see section 6.5.2).
obj1 and obj2 are both characters and are the same
character according to the char=? procedure (section
6.6).
both obj1 and obj2 are the empty list.
obj1 and obj2 are pairs that refer to the same locations in the store
(see section 7.2.2).
obj1 and obj2 are vectors that refer to the same locations in the store
(see section 7.2.2).
obj1 and obj2 are strings that refer to the same locations in the store
(see section 7.2.2).
obj1 and obj2 are procedures whose location tags are equal
(see section 7.2.2).
The eqv? procedure returns #f if:
one of obj1 and obj2 is a boolean but the other is not.
one of obj1 and obj2 is a symbol but the other is not.
one of obj1 and obj2 is a number but the other is not.
one of obj1 and obj2 is a pair but the other is not.
one of obj1 and obj2 is a vector but the other is not.
one of obj1 and obj2 is a string but the other is not.
one of obj1 and obj2 is a procedure but the other is not.
one of obj1 and obj2 is #t but the other is #f.
obj1 and obj2 are symbols but
(string=? (symbol->string obj1) (symbol->string obj2)) is false.
one of obj1 and obj2 is an exact number and the other is an
inexact number.
obj1 and obj2 are numbers for which the = procedure returns
#f.
obj1 and obj2 are characters for which the char=? procedure
returns #f.
one of obj1 and obj2 is the empty list but the other is not.
obj1 and obj2 are pairs that refer to distinct locations
(see section 7.2.2).
obj1 and obj2 are vectors that refer to distinct locations
(see section 7.2.2).
obj1 and obj2 are strings that refer to distinct locations
(see section 7.2.2).
obj1 and obj2 are procedures that would behave differently
(return a different value or have different side effects)
for some arguments.
[The first block of examples goes here, omitting the
(eq? "" "") example, which should be added to the second
block of examples.]
The following examples illustrate cases in which the above
rules do not fully specify the behavior of eqv?. In every
case, the value returned by eqv? is either #t or #f, but
which one it returns is implementation-dependent.
[The second block of examples goes here, following by the
paragraph beginning "The next set of examples shows...",
followed by the gen-counter and gen-loser examples.]
Objects of distinct types must never be regarded as the same
object, except that #f and the empty list are permitted
to be identical, and the character type need not be disjoint
from other types.
[The fourth block of examples goes here, followed by the
paragraph beginning "Since it is an error...", followed by
the fifth block of examples, followed by the note.]
∂21-Jun-88 1713 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Oaklisp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jun 88 17:13:06 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Jun 88 20:08:10 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA02880@BLOOM-BEACON.MIT.EDU>; Tue, 21 Jun 88 20:05:59 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Jun 88 12:22:11 GMT
From: mcvax!unido!gmdzi!thomas@uunet.uu.net (Thomas Gordon)
Organization: GMD, Sankt Augustin, F. R. Germany
Subject: Re: Oaklisp
Message-Id: <578@gmdzi.UUCP>
References: <8806031654.AA00871@BLOOM-BEACON.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
From article <8806031654.AA00871@BLOOM-BEACON.MIT.EDU>, by NETWORK@FRSAC11.BITNET:
>
> Did anybody succeed in porting OAK to System V ?
> Or to an other cpu than sun/VAX/rt ?
If I recall correctly, Oaklisp is an interesting object-oriented dialect
of Scheme that was originally implemented on the Macintosh. I do not
know if it has been ported anywhere, but this is the first I hear that
it is available at all. I would love to play with the Macintosh version.
Does anyone know if it is available?
Thomas F. Gordon email: thomas@gmdxps.uucp
GMD / F3 phone: (+49 2241) 14-2665
Schloss Birlinghoven
D-5205 Sankt Augustin 1, FRG
--
Thomas F. Gordon email: thomas@gmdxps.uucp
GMD / F3 phone: (+49 2241) 14-2665
Schloss Birlinghoven
D-5205 Sankt Augustin 1, FRG
∂22-Jun-88 0030 @MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu Re: Oaklisp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jun 88 00:29:54 PDT
Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 22 Jun 88 00:42:16 EDT
Date: 22 Jun 1988 00:16-EDT
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
To: mcvax!unido!gmdzi!thomas@uunet.uu.net (Thomas Gordon)
Cc: scheme@mc.lcs.mit.edu
Subject: Re: Oaklisp
Message-Id: <Wed.Jun.22.00:16:47.1988/bap@F.GP.CS.CMU.EDU>
>>From article <8806031654.AA00871@BLOOM-BEACON.MIT.EDU>, by NETWORK@FRSAC11.BITNET:
>>
>> Did anybody succeed in porting OAK to System V ?
>> Or to an other cpu than sun/VAX/rt ?
>
>If I recall correctly, Oaklisp is an interesting object-oriented dialect
>of Scheme that was originally implemented on the Macintosh. I do not
>know if it has been ported anywhere, but this is the first I hear that
>it is available at all. I would love to play with the Macintosh version.
>Does anyone know if it is available?
>
>Thomas F. Gordon email: thomas@gmdxps.uucp
Actually, our implementation of Oaklisp was developed on a Sun, although
I will also run on most any Unix box, and probably on a Macintosh.
We aren't doing any support at all, but AT YOUR OWN RISK you can ftp a
compressed tar file of the latest release from DOGHEN.BOLTZ.CS.CMU.EDU,
user "ftpguest", password "oaklisp", file "oak/release.tar.Z". Be sure
to use binary mode. This isn't a real release. No support. You're on
your own.
--Barak.
∂22-Jun-88 1348 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jun 88 13:48:44 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 22 Jun 88 16:47:06 EDT
Received: by ti.com id AA08491; Wed, 22 Jun 88 15:44:33 CDT
Received: from mips by tilde id AA26292; Tue, 21 Jun 88 10:55:43 CDT
Received: by mips id AA16088; Tue, 21 Jun 88 10:55:32 CDT
Date: Tue, 21 Jun 88 10:55:32 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8806211555.AA16088@mips>
To: rrrs-authors@mc.lcs.mit.edu
Subject: More on Full Specification
From: Paul Hudak <hudak-paul@YALE.ARPA>
>[Concerning indeterminate argument evaluation order:]
>I wasn't around when the decision was made, so can't say whether it
>was "deliberate" or not, but in what sense is it "desireable"?
>Presumably the motivation for this was to allow implementation
>freedom, so why only stop half-way? My guess is that the intent was
>as Robert Hieb states, except for the concurrency part (but maybe that
>was in somebody's mind too). I wonder how many current
>implementations permute the arguments in different ways depending on
>context? Seems useful to me ... and fully within the motivation for
>underspecification in the first place.
We certainly do, and it is indeed useful.
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
>Finally a note about implementation issues. Although, as one greatly involved
>with implementing Scheme, I can understand their seduction, I think
>we should fight it. First-class procedures and continuations combined with
>lexical scoping, assignments and indefinite extent for variables appeared
>to deliver a knockout blow to implementation efficiency. The fact that
>good implementation techniques have appeared anyway is good reason not to
>be too quick to worry about implementations. After all, an implementation
>can do what it pleases as long as no one can tell the difference. Thus
>if it can prove that order of evaluation doesn't matter, or that variables
>can't be referenced before definition, it can make appropriate optimizations.
>The next great step in Scheme efficiency will require extensive program
>analysis anyway. I think people are still attracted to Scheme by the
>structure and semantics of its powerful features, and that is what we should
>concentrate on.
I don't think those features "appeared to deliver a knockout blow to
implementation efficiency." What they did do (in combination) was
force us to look at compiling in new ways. I was pleased, but not
terribly surprised, when we found efficient ways to cope with them.
It's a different story with your suggestions. Fixing the order of
evaluation of arguments, for instance, has problems for optimising
compilers that are well known. I could win with global analysis in
Pascal because I could see the entire program at a time and didn't
have real first-class procedures to deal with, but I'm stymied in
Scheme most of the time.
I agree with the spirit of your argument, though. We shouldn't cast
in concrete only those language features that we already know how to
do well.
From: willc@tekchips.crl
> [...] I generally agree with Robert Hieb's analysis.
>I happen to think, however, that the three concrete underspecifications
>that Hieb proposed to fix (value returned by side-effecting procedures,
>order of evaluation of arguments, order of evaluation of definitions)
>are among the most justified underspecifications in all of Scheme. Each
>of these underspecifications concerns something that programmers ordinarily
>do not care about because it doesn't matter; they have the effect of
>requiring programmers to write some explicit code in the exceptional case
>when they do want to use a specific value or order of evaluation. If
>these underspecifications were "fixed", programs would be harder to read
>because you would have to assume that the order matters whenever you see
>a procedure call or internal definitions. As things stand now, you know
>the order doesn't matter and this fact makes it easier to understand the
>program.
I think Will has summarized my thinking beautifully, so I'll leave it
at this: I agree that we should tighten up inadvertant or lazy
underspecification, but there are places, such as these, where it is
appropriate.
--db--
∂22-Jun-88 1400 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jun 88 14:00:47 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 22 Jun 88 16:47:07 EDT
Received: by ti.com id AA08480; Wed, 22 Jun 88 15:44:14 CDT
Received: from mips by tilde id AA25692; Tue, 21 Jun 88 10:28:54 CDT
Received: by mips id AA15531; Tue, 21 Jun 88 10:28:47 CDT
Date: Tue, 21 Jun 88 10:28:47 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8806211528.AA15531@mips>
To: JAR@mc.lcs.mit.edu
Cc: Pavel.pa@XEROX.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan A Rees's message of Mon, 13 Jun 88 17:44:35 EDT <396821.880613.JAR@AI.AI.MIT.EDU>
Subject: (define x)
>We need to decide whether this is to make sense only for top-level
>defines or for internal defines as well. If for internal defines, the
>desugaring into LETREC has to be given; that would probably mean that
>LETREC would have to be extended (e.g. (letrec ((x) (y)) ...)); and that
>seems like a bad idea to me, although I don't feel strongly; so I'd
>suggest making it a special case for top level. Top level defines are
>already sufficiently different from internal ones (e.g. they are
>evaluated sequentially, and may be interspersed with expressions) that
>this doesn't seem too terrible.
I think internal (DEFINE X) has much less justification than top-level
ones, so I'd rather avoid the mess of allowing (LETREC ((X) (Y)) ...).
--db--
∂22-Jun-88 1629 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com List of attendees (tentative)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jun 88 16:29:25 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jun 88 19:22:43 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab26915; 22 Jun 88 18:52 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa12333; 22 Jun 88 18:39 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA09378; Wed, 22 Jun 88 10:12:45 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA07114; Wed, 22 Jun 88 10:13:54 PDT
Message-Id: <8806221713.AA07114@tekchips.CRL.TEK.COM>
To: bartley%mips.csc.ti.com@RELAY.CS.NET, Alan@mc.lcs.mit.edu,
jeff%aiva.edinburgh.ac.uk@NSS.CS.UCL.AC.UK,
uunet.uu.net!mcvax!diku.dk!danvy@tekcrl.crl, kend@tekchips.crl,
dfried@iuvax.cs.indiana.edu, RPG@SAIL.STANFORD.EDU,
cph%kleph.ai.mit.edu@RELAY.CS.NET, mkatz@A.ISI.EDU,
kranz@WHEATIES.AI.MIT.EDU, emo@iuvax.cs.indiana.edu,
philbin-jim@YALE.ARPA, uwe@tekchips.crl,
jinx%chamartin.ai.mit.edu@RELAY.CS.NET,
wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: List of attendees (tentative)
Date: 22 Jun 88 10:13:52 PDT (Wed)
From: willc@tekchips.crl
The following people have told me that they are coming to the RRRS meeting
on Sunday before LFP:
David H Bartley
Alan Bawden
Will Clinger
Jeff Dalton
Olivier DANVY
Ken Dickey
Dan Friedman
Dick Gabriel
Chris Hanson
Morry Katz
David Kranz
Eric Ost
Jim Philbin
Uwe Pleban
Guillermo J Rozas
Mitchell Wand
I assume that Hal Abelson (chair) and Jonathan Rees (editor) are coming
also, for a total of eighteen people so far. If you intend to attend but
your name is not on this list, please let me know.
Please let me know also if your name is on this list but I've gotten your
electronic mailing address wrong. (If you're on the rrrs-authors mailing
list, you should receive two copies of this message.)
Peace, Will
∂22-Jun-88 1934 @MC.LCS.MIT.EDU,@HELIOS.NORTHEASTERN.EDU:wand@corwin.ccs.northeastern.edu new wording for eqv?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jun 88 19:34:28 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 22 Jun 88 22:31:43 EDT
Received: from helios.northeastern.edu by RELAY.CS.NET id aa27150;
22 Jun 88 19:08 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa23454; 22 Jun 88 18:53 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.4)
id AA15343; Mon, 20 Jun 88 13:49:22 EDT
Date: Mon, 20 Jun 88 13:49:22 EDT
From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@RELAY.CS.NET>
Message-Id: <8806201749.AA15343@corwin.CCS.Northeastern.EDU>
To: gls@THINK.COM
Cc: KMP@SCRC-STONY-BROOK.ARPA, JAR@mc.lcs.mit.edu,
willc%tekchips.tek.com@RELAY.CS.NET, KMP@SCRC-STONY-BROOK.ARPA,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@think.com's message of Fri, 17 Jun 88 18:20:58 EDT <8806172220.AA14999@kali.think.com>
Subject: new wording for eqv?
Date: Fri, 17 Jun 88 18:20:58 EDT
From: gls@think.com
Subject: new wording for eqv?
To: KMP@scrc-stony-brook.arpa
Cc: JAR@mc.lcs.mit.edu, willc%tekchips.tek.com@relay.cs.net,
KMP@scrc-stony-brook.arpa, rrrs-authors@mc.lcs.mit.edu
Date: Fri, 17 Jun 88 16:09 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I observe as an aside also that your description is somewhat
meta-circular, though perhaps not enough to worry about here. You
effectively begin by saying that EQV? computes whether two things
are distinct (for which i read "not the same"), and yet the
terminology uses the word "the same" all over the place.
Plus ca change, plus c'est la meme chose.
In making this observation, have you adequately considered the granularity of
time, multiprocessing, and the effects of quantum gravitation?
Note also that the preceding question, along with this observation,
presupposes temporal concepts as well :-) --Mitch
∂23-Jun-88 0006 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Oaklisp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 88 00:06:07 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Jun 88 01:53:26 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA03940@BLOOM-BEACON.MIT.EDU>; Thu, 23 Jun 88 01:48:00 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Jun 88 01:00:59 GMT
From: voder!cullsj!jeff@bloom-beacon.mit.edu (Jeffrey C. Fried)
Organization: Cullinet Software, San Jose, CA
Subject: Re: Oaklisp
Message-Id: <332@cullsj.UUCP>
References: <Wed.Jun.22.00:16:47.1988.bap@F.GP.CS.CMU.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am unable to FTP or anonymous UUCP, can you e-mail a copy to me?
-------------------------------------------------------------------
Jeff Fried UUCP: ...!ames!cullsj!jeff
Reality, what a concept!
San Jose, CA, 95134 (clearly work) San Mateo, CA (home)
(408) 434-6636 (415) 349-3744
Disclaimer: Opinions expressed are solely those of the author.
∂23-Jun-88 0853 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 88 08:53:51 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 23 Jun 88 11:51:41 EDT
Received: by iuvax.cs.indiana.edu; id AA11128; Thu, 23 Jun 88 10:25:23 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Thu, 23 Jun 88 10:25:23 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: (define x)
From: David Bartley <bartley@mips.csc.ti.com>
Subject: (define x)
I think internal (DEFINE X) has much less justification than top-level
ones, so I'd rather avoid the mess of allowing (LETREC ((X) (Y)) ...).
--db--
I disagree. If it is going to be allowed at top-level, and it probably
should be, then it should be allowed internally. We can show the
expansion as "(letrec ((x <undefined>)) ...)", if we want, as with the
derived expansion for letrec in the formal semantics section. It makes
no sense to have a different syntax for internal defines from that of
external defines. I would use "(define x)" internally just as much as
I would use it externally, and for the same reasons.
∂23-Jun-88 0934 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 88 09:33:52 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Jun 88 12:31:41 EDT
Date: Thu, 23 Jun 88 12:31:36 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Sender: JAR0@AI.AI.MIT.EDU
Subject: (define x)
To: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 23 Jun 88 10:25:23 EST from R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
Message-ID: <402290.880623.JAR0@AI.AI.MIT.EDU>
I think I agree with Kent Dybvig that if (define x) is allowed at top
level, then it should be allowed internally.
I would hate to see some functionality become available through define
that was not available through letrec, so I would advise adopting
(define x) ONLY if letrec is also extended so that
(letrec ((x) ...) ...)
means
(letrec ((x <unassigned>) ...) ...).
For orthogonality's sake, this should also, I believe, require
(let ((x) ...) ...)
to mean
(let ((x <unassigned>) ...) ...),
and similarly for let*, named let (?), and do (??). Consider this proposed,
and please talk me out of this madness.
∂24-Jun-88 0733 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu formal proposal: A Modified Procedural Interface
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Jun 88 07:32:50 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Jun 88 10:27:45 EDT
Received: by iuvax.cs.indiana.edu; id AA07930; Fri, 24 Jun 88 09:25:37 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Fri, 24 Jun 88 09:25:37 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: formal proposal: A Modified Procedural Interface
% formal proposal: A Modified Procedural Interface
% [to provide for variable-arity procedures and multiple return values]
% See the accompanying note entitled
% ``informal proposal: A Modified Procedural Interface''
% for a more coherent discussion of the intent of this proposal.
% The following tex commands are derived from r4rs.tex.
% They allow this section to be latexed separately
% (although section numbers are lost or mutilated in the process).
% (You will still need commands.tex)
\documentstyle[twoside]{algol60}
\pagestyle{headings}
\showboxdepth=0
\input{commands}
\def\theevenhead{Revised$↑{3.5}$ Scheme}
\begin{document}
\hfil {\bf *** DRAFT --- \today{} ***}
% This is a patch to commands.tex to kill indexing for separate latexing:
\global\def\reallyindex#1#2#3{}
% The following should be added to commands.tex:
\newcommand{\lambdastarexp}{lambda* expression}
\newcommand{\Lambdastarexp}{Lambda* expression}
\newcommand{\ampersand}{{\bf \&}}
% The modifications begin at the start of chapter 3. Unmodified sections have
% been omitted, so it must be correlated with the full report.
\chapter{Basic concepts}
\section{Variables and regions}
\label{specialformsection}
\label{variablesection}
Any identifier that is not a syntactic keyword \index{keyword} (see
section~\ref{keywordsection}) may be used as a variable. \index{syntactic
keyword}\index{identifier}\mainindex{variable} A variable may name a location
where zero or more values can be stored. A variable that does so is said to be
{\em bound} to the location. The set of all such bindings \mainindex{binding}
in effect at some point in a program is known as the {\em environment} in effect
at that point. The values stored in the location to which a variable is bound
are called the variable's values. By abuse of terminology, the variable is
sometimes said to name the values or to be bound to the values. This is not
quite accurate, but confusion rarely results from this practice.
\vest Certain expression types are used to create new locations and to bind
variables to those locations. The most fundamental of these {\em binding
constructs} \mainindex{binding construct} is the \lambdastarexp{}
\index{\lambdastarexp{}}, because all other binding constructs can be explained
in terms of \lambdastarexp{}s. The other binding constructs are \ide{lambda},
\ide{let}, \ide{let*}, \ide{letrec}, and \ide{do} expressions (see
sections~\ref{lambdastar}, \ref{letrec}, and \ref{do}).
\vest Like Algol and Pascal, and unlike most other dialects of Lisp except for
Common Lisp, Scheme is a statically scoped language with block structure. To
each place where a variable is bound in a program there corresponds a
\defining{region} of the program text within which the binding is effective.
The region is determined by the particular binding construct that establishes
the binding. Every reference to or assignment of a variable refers to the
binding of the variable that established the innermost of the regions containing
the use. If there is no binding of the variable whose region contains the use,
then the use refers to the binding for the variable in the top level
environment, if any (section~\ref{initialenv}); if there is no binding for the
identifier, it is said to be \defining{unbound}.
\mainindex{bound}\index{top level environment}
\chapter{Expressions}
\label{expressionchapter}
\newcommand{\syntax}{{\em Syntax: }}
\newcommand{\semantics}{{\em Semantics: }}
A Scheme expression is a construct that returns zero or more values, such as a
variable reference, literal, procedure call, or conditional.
Expression types are categorized as {\em primitive} or {\em derived}. Primitive
expression types include variables and procedure calls. Derived expression
types are not semantically primitive, but can instead be explained in terms of
the primitive constructs as in section ~\ref{derivedsection}. They are
redundant in the strict sense of the word, but they capture common patterns of
usage, and are therefore provided as convenient abbreviations.
\section{Primitive expression types}
\label{primitivexps}
\subsection{Variable references}\unsection
\begin{entry}{%
\pproto{\hyper{variable}}{essential \exprtype}}
An expression consisting of a variable \index{variable}
(section~\ref{variablesection}) is a variable reference. The values of the
variable reference are the values stored in the location to which the variable
is bound. It is an error to reference an unbound \index{unbound} variable.
\begin{scheme}
(define x 28)
x \ev 28%
\end{scheme}
\end{entry}
\subsection{Procedure calls}\unsection
\begin{entry}{%
\pproto{(\hyper{operator} \hyperi{operand} \dotsfoo)}{essential \exprtype}
\pproto{(\hyper{operator} \hyperi{operand} \dotsfoo \hyper{operand$_{n-1}$} \ampersand\ \hypern{operand})}{essential \exprtype}}
A procedure call is written by simply enclosing in parentheses expressions for
the procedure to be called and the arguments to be passed to it. The operator
and operand expressions are evaluated (in an indeterminate order) and the
resulting procedure is passed the resulting arguments.
\mainindex{call}\mainindex{procedure call}
\begin{scheme}%
(+ 3 4) \ev 7
((if \schfalse + *) 3 4) \ev 12%
\end{scheme}
Only an expression following an \ampersand{} may evaluate to an indefinite
number of values; an error is signalled if exactly one value is not returned for
any other expressions in a procedure call. All of the values returned by an
expression following an \ampersand{} are passed to the called procedure.
\begin{note} In contrast to other dialects of Lisp, the order of
evaluation is unspecified, and the operator expression and the operand
expressions are always evaluated with the same evaluation rules.
\end{note}
\end{entry}
\subsection{Multiple return values}\unsection
\begin{entry}{%
\proto{values}{ \hyperi{operand} \dotsfoo}{essential procedure}}
The special procedure \ide{values} is used to return indefinite numbers of
values. It follows the ordinary evaluation rules for procedures, and is a
first-class object like other procedures, but returns all of the values it
receives as arguments. It can be thought of as the multiple value identity
operator.
\begin{scheme}%
(list 1 2 \& (values)) \ev (1 2)
(list 1 2 \& (values 3 4)) \ev (1 2 3 4)
(list 1 2 (values 3)) \ev (1 2 3)
(list 1 2 (values 3 4)) \ev \scherror%
\end{scheme}
\begin{note}%
A description of \ide{values} is probably more properly placed in the section on
special control features.
\end{note}
\end{entry}
\subsection{\Lambdastarexp{}s}\unsection
\label{lambastar}
\begin{entry}{%
\proto{lambda*}{ \hyperi{clause} \hyper{clause$_2$} \dotsfoo}{essential \exprtype}}
\syntax
Each \hyper{clause} should be of the form
\begin{scheme}
(\hyper{formals} \hyper{body}).%
\end{scheme}
\hyper{Formals} should be a formal arguments list as described below, and
\hyper{body} should be a sequence of one or more expressions.
\semantics
\vest A \lambdastarexp{} evaluates to a procedure. The environment in effect
when the \lambdastarexp{} was evaluated is remembered as part of the procedure.
When the procedure is later called with some actual arguments, the appropriate
\hyper{clause} will be selected, and the environment in which the
\lambdastarexp{} was evaluated will be extended by binding the variables in its
formal argument list to fresh locations, the corresponding actual argument
values will be stored in those locations, and the expressions in the
\hyper{body} of the \hyper{clause} will be evaluated sequentially in the
extended environment. The values returned by last expression in the
\hyper{body} will be returned as the result of the procedure call. The first
\hyper{clause} whose \hyper{formals} accepts the actual arguments received by
the procedure is selected. An error is signaled if no \hyper{formals} accepts
the arguments received by a procedure.
\hyper{Formals} should have one of the following forms:
\begin{itemize}
\item {\tt(\hyperi{variable} \dotsfoo\ \hypern{variable})}:
The \hyper{clause} accepts exactly $n$ arguments. The arguments will be stored
in the bindings of the corresponding variables, and the \hyper{body} of the
\hyper{clause} will be evaluated.
\item {\tt(\hyperi{variable} \dotsfoo\ \hypern{variable} \ampersand\ \hyper{variable$_{n+1}$})}:
The \hyper{clause} accepts $n$ or more arguments. The first $n$ arguments will
be stored in the bindings of the first $n$ corresponding variables; all
arguments left over will be stored in the binding of the variable following the
\ampersand{}. These values may be referenced by using the variable following an
\ampersand{} in a procedure call.
\end{itemize}
\begin{scheme}%
(lambda* ((x) x)) \ev {\em{}a procedure}
((lambda* ((x) x)) 0) \ev 0
((lambda* ((\& r) (list \& r)))
1 2 3) \ev (1 2 3)
(define list
(lambda*
(() '())
((x \& r) (cons x (list \& r)))))%
\end{scheme}
\end{entry}
\subsection{Conditionals}\unsection
\begin{entry}{%
\proto{if}{ \hyper{test} \hyper{consequent} \hyper{alternate}}{essential \exprtype}
\proto{if}{ \hyper{test} \hyper{consequent}}{\exprtype}} %\/ if hyper = italic
\syntax
\hyper{Test}, \hyper{consequent}, and \hyper{alternate} may be arbitrary
expressions.
\semantics
An \ide{if} expression is evaluated as follows: first, \hyper{test} is
evaluated. If it yields a true value\index{true} (see
section~\ref{booleansection}),then \hyper{consequent} is evaluated and its
values are returned. Otherwise\hyper{alternate} is evaluated and its values are
returned. If \hyper{test}yields a false value and no \hyper{alternate} is
specified, then the result of the expression is unspecified. An error will be
signaled if \hyper{test} does not evaluate to exactly one value.
\begin{scheme}
(if (> 3 2) 'yes 'no) \ev yes
(if (> 2 3) 'yes 'no) \ev no
(if (> 3 2)
(- 3 2)
(+ 3 2)) \ev 1
(list \& (if \#t (values) 0)) \ev ()
(if (values) 0 1) \ev \scherror%
\end{scheme}
\end{entry}
\subsection{Assignments}\unsection
\begin{entry}{%
\proto{set!}{ \hyper{variable} \hyper{expression}}{essential \exprtype}}
\hyper{Expression} is evaluated, and the resulting values are stored in the
location to which \hyper{variable} is bound. \hyper{Variable} must be bound
either in some region \index{region} enclosing the \ide{set!} expressionor at
top level. The result of the \ide{set!} expression is unspecified.
\begin{scheme}
(define x 2)
(+ x 1) \ev 3
(set! x 4) \ev \unspecified
(+ x 1) \ev 5
(set! x (values 1 2)) \ev \unspecified
(+ \& x) \ev 3%
\end{scheme}
\end{entry}
\end{document}
% Other modifications remain to be made, particularly in the syntax and
% semantics.
∂24-Jun-88 0745 @MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu informal proposal: A Modified Procedural Interface
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Jun 88 07:45:29 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Jun 88 10:28:12 EDT
Received: by iuvax.cs.indiana.edu; id AA07968; Fri, 24 Jun 88 09:26:39 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Fri, 24 Jun 88 09:26:39 EST
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: informal proposal: A Modified Procedural Interface
This is a response to Will Clinger's optional argument and multiple return value
proposals:
Date: Tue Jun 21 12:23:01 1988
Subject: Optionals, version 1
From: willc@tekchips.crl
Date: Tue Jun 21 12:23:15 1988
Subject: Multiple values, version 1
From: willc@tekchips.crl
I particularly dislike the optional argument mechanism, which I find clumsy. In
response to its original appearance (following the R*S meeting last summer), I
posted a critical note. If someone does not have a copy, I would be glad to
send it on request. In summary, the proposed mechanism:
complicates an already complicated lambda list,
is aesthetically unappealing,
is clumsy to use,
introduces a special default value,
does not provide error checking on (mis)use of the optional value, and
is not simple to optimally implement.
I am just not pleased with the code that results from its use.
However, I do agree that some sort of improved optional argument mechanism is
desirable, since Scheme is committed to procedures that accept variable numbers
of arguments. I also agree that the |.| in the argument list is a mistake, and
would like to move away from it (but don't much care for |#!rest|, or
#!anything, in fact).
Kent Dybvig and I will present a paper at the Lisp Conference this summer that
addresses both optional arguments and multiple return values (``A Variable-Arity
Procedural Interface''---also available as Indiana University Computer Science
Department Technical Report No. 247). We had meant to let it speak first, but
perhaps it should be summarized here, now that Will has made specific proposals.
The paper is mainly concerned with variable-arity procedures, but also shows how
the mechanism can be adapted to allow multiple return values. I have worked our
proposal into a revision of key sections of the R*S, but it spreads across so
many sections that the intent and scope of the proposal is hard to follow (not
to mention the difficulty of reading raw TEXed material). Consequently I have
decided to post two notes: this informal (and hopefully more coherent)
discussion and the R*S revision.
It is based on two notions:
(1) a procedure should automatically select an action based on the
number of arguments it receives, and
(2) procedures that accept an indefinite number of arguments and expressions
that return multiple values can be related by allowing variables to refer
to multiple values (more precisely, using the language of the R*S,
allowing zero or more values to be stored in the location to which a
variable is bound).
Our proposal depends upon the conception that there are problems with the
existing R* Scheme parameter mechanism, which sticks ``extra'' arguments in a
list. There seems to be a widely perceived need for a better way to handle
optional arguments, so I won't argue that here. However, there are also
problems inherent in bundling up extra arguments in a list in those cases where
a procedure may receive an indefinite number of arguments. Our paper spends a
good deal of time on this topic, so I don't want to flog it here. It is worth
noting, however, that arguments against using lists to return multiple values
can be turned against using lists to receive multiple arguments. Consequently,
it is pleasing to discover that the two notions can also be related in a simple
manner.
The key idea is that variable locations may be allowed to contain multiple
values. Referencing a multiple-valued variable simply results in the return of
its values, as with the evaluation of any other multiple-valued expression.
Extracting multiple values from a variable location or any other multiple-valued
expression is most naturally accomplished by using the procedure call mechanism,
which can extract and name the desired values.
Here is a R*S version of the syntax we proposed. It introduces two key words,
|lambda*| and |&|, and modifies part of the R*S syntax.
<lambda* expression> --> (lambda* <clause> <clause> ...)
<clause> --> (<formals> <body>)
<formals> --> (<variable> ...) |
(<variable> ... & <variable>)
<procedure call> --> (<expression> <expression> ...) |
(<expression> <expression> ... & <expression>)
<body>, <variable> and <expression> are as in the R*S, with the addition of
<lambda* expression> to the <expression> category. A <lambda* expression> is an
extended <lambda expression> that selects a <clause> based on the number of
arguments it receives. Thus a <lambda expression> (without the list-interface)
may be expressed as a <lambda* expression>:
(lambda (<variable> ...) <body>) ==> (lambda* ((<variable> ...) <body>))
|&| may be thought of as a multiple value context marker. In a <formals>, |&|
precedes a <variable> whose location can contain zero or more values. It will
receive whatever arguments are left over after each preceding <variable>
receives its argument (much like |.| in a <lambda expression>, except that the
values are not put into a list). In a <procedure call>, |&| precedes an
<expression> that may return zero or more values (this may be compared to the
action of |apply|, except, once again, the values are not in a list).
The first <clause> whose formal parameters accept the actual parameters is
selected, and thereafter the binding of its <formals> and evaluation of its
<body> proceeds as for a <lambda expression>. Each ordinary <variable> accepts
exactly one actual parameter; a <variable> following |&| accepts zero or more
actual parameters. It is an error if no <clause> accepts the actual parameters.
Simple examples:
(define -
(lambda*
((x) (binary- 0 x))
((x y) (binary- x y)))))
(define list
(lambda*
(() '())
((x & r) (cons x (list & r)))))
(define maximum
(lambda*
((x y) (if (> x y) x y))
((x y & r) (maximum (maximum x y) & r))))
Generalized multiple return values can be introduced by adding a |values|
primitive, as Will suggests. We avoided introducing |values| in the paper by
letting the values of all expressions in a <body> be returned. However that may
not be a viable solution for R* Scheme, since a <body> is considered to contain
an implicit |begin| in other contexts. The expanded procedure call mechanism
does remove the need for introducing |with-values| as a special primitive:
(define with-values (lambda (thunk proc) (proc & (thunk))))
We suggest that the return of other than a single value to a singular context be
an error. It is simple enough to strip off one value if desired, and enforcing
it can only aid the clarity and correctness of programs:
(define first (lambda* ((x & r) x)))
Of course one must decide what to do about other expressions that might receive
multiple values. In R* Scheme, that means conditionals (|if|) and assignments
(|set!|). It is reasonable to enforce single values for the test expression of
a conditional and allow the branches to be transparent to multiple values.
Since variable locations can contain multiple values, multiple-valued
assignments can be allowed. Derived forms should derive their behavior with
respect to multiple values from the behavior of their base forms.
This proposal is in the spirit of Scheme in that it adds a lot of power for a
little bit of syntax. It is possible to stop with variable-arity procedures and
not proceed to multiple return values, but integration of the notions of
returning variable numbers of values and receiving variable numbers of arguments
is pleasing, particularly since we seem to be moving toward adopting some form
of multiple return value mechanism anyway.
Bob Hieb
∂25-Jun-88 1451 @MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Jun 88 14:51:46 PDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 25 Jun 88 17:47:32 EDT
Received: from ASPEN.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 167575; Sat 25-Jun-88 17:46:25 EDT
Date: Sat, 25 Jun 88 17:46 EDT
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
Subject: (define x)
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <402290.880623.JAR0@AI.AI.MIT.EDU>
Message-ID: <880625174633.1.RHH@ASPEN.LCS.MIT.EDU>
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
I would hate to see some functionality become available through define
that was not available through letrec, so I would advise adopting
(define x) ONLY if letrec is also extended so that
(letrec ((x) ...) ...)
means
(letrec ((x <unassigned>) ...) ...).
For orthogonality's sake, this should also, I believe, require
(let ((x) ...) ...)
to mean
(let ((x <unassigned>) ...) ...),
and similarly for let*, named let (?), and do (??). Consider this proposed,
and please talk me out of this madness.
I would like to support the proposal as a perspicuous way to introduce a
variable whose purpose in life is to be side-effected. -Bert Halstead
∂25-Jun-88 1519 @MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu FTPing Oaklisp
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Jun 88 15:18:50 PDT
Received: from F.GP.CS.CMU.EDU (TCP 20000575244) by MC.LCS.MIT.EDU 25 Jun 88 18:14:09 EDT
Date: 25 Jun 1988 17:46-EDT
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
To: scheme@mc.lcs.mit.edu
Cc: kjl@g, unido!gmdxps!thomas@uunet.UU.NET, twleung@ATHENA.MIT.EDU,
death@ZERMATT.LCS.MIT.EDU, jch@citi.umich.edu,
voder!cullsj!jeff@bloom-beacon.mit.edu,
john@nsr.bioeng.washington.edu, FAUSETT@RADC-TOPS20.ARPA
Subject: FTPing Oaklisp
Message-Id: <Sat.Jun.25.17:46:54.1988/bap@F.GP.CS.CMU.EDU>
A number of people have asked if I could mail them copies of Oaklisp, or
even send tapes. I'm very sorry, but the answer is catagorically no; I
don't even have the time to answer such mail individually. Perhaps some
kind person will post Oaklisp to comp.sources, solving this problem for
uucp people. (I am willing to hand carry a tape to a warm clime, like
California, if you provide the transportation.)
I have also been deluged with mail concerning problems FTPing Oaklisp,
so I am posting more extensive instructions. The correct way to FTP
Oaklisp is as follows:
cd where/you/want/the/stuff
ftp doghen.boltz.cs.cmu.edu [or 128.2.222.37 if necessary]
user ftpguest [whatever your client likes here]
password oaklisp [password is in lowercase]
get oak/release.tar.Z release.tar.Z [not a typo]
quit
uncompress release.tar.Z
tar xf release.tar
...
NOTE: The ftp server on DOGHEN has a bug and fails if you try to switch
directories, so don't use ftp's CD command.
--Barak.
∂26-Jun-88 0233 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@cs.brandeis.edu More on Full Specification
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Jun 88 02:33:17 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Jun 88 05:31:41 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ac14159; 26 Jun 88 5:24 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id ac10120;
26 Jun 88 5:18 EDT
Received: from mephi.earth1.com by cs.brandeis.edu (13.1/6.0.GT)
id AA04760; Sat, 25 Jun 88 15:59:32 edt
Posted-Date: Sat, 25 Jun 88 15:59:06 EDT
Received: by mephi.earth1.com (3.2/SMI-3.2)
id AA01231; Sat, 25 Jun 88 15:59:06 EDT
Date: Sat, 25 Jun 88 15:59:06 EDT
From: James Miller <jmiller%mephi%cs.brandeis.edu@RELAY.CS.NET>
Message-Id: <8806251959.AA01231@mephi.earth1.com>
To: willc%tekchips.crl@RELAY.CS.NET
Cc: tiedeman.2@cs.brandeis.edu, hudak-paul.2@cs.brandeis.edu,
hieb.2@cs.brandeis.edu, rrrs-authors.2@cs.brandeis.edu
In-Reply-To: willc@tekchips.crl's message of 17 Jun 88 13:13:40 PDT (Fri) <8806172013.AA20610@tekchips.CRL.TEK.COM>
Subject: More on Full Specification
While I agree with most of Will's comments on underspecification, I
would like to defend underspecifying the returned value of
side-effecting constructs. I have tried to make MultiScheme a direct
extension to the RnRS standard where possible while adding as few new
special forms as possible. By having the standard deliberately
understate the value returned by SET! (and SET-CAR!, etc.), I have
avoided the need to introduce separate atomic swap operations for
these cases (although I do provide Halstead's more powerful
conditional side-effect operations).
I think this case again indicates the importance of
underspecification: in doing research into a new application area
(parallel programming) the deliberate underspecification allows a
legitimate alternative implementation. Users are NOT encouraged to
use the returned value of SET! et al, but can do so when necessary for
concurrency control.
--Jim
∂27-Jun-88 0847 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM (define x)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jun 88 08:47:37 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 27 Jun 88 10:34:54 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425028; Mon 27-Jun-88 10:24:47 EDT
Date: Mon, 27 Jun 88 10:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (define x)
To: rhh@VX.LCS.MIT.EDU, JAR@AI.AI.MIT.EDU
cc: RRRS-Authors@MC.LCS.MIT.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880625174633.1.RHH@ASPEN.LCS.MIT.EDU>
Message-ID: <880627102432.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sat, 25 Jun 88 17:46 EDT
From: Robert Halstead <rhh@VX.LCS.MIT.EDU>
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
I would hate to see some functionality become available through define
that was not available through letrec, so I would advise adopting
(define x) ONLY if letrec is also extended so that
(letrec ((x) ...) ...)
means
(letrec ((x <unassigned>) ...) ...).
For orthogonality's sake, this should also, I believe, require
(let ((x) ...) ...)
to mean
(let ((x <unassigned>) ...) ...),
and similarly for let*, named let (?), and do (??). Consider this proposed,
and please talk me out of this madness.
I would like to support the proposal as a perspicuous way to introduce a
variable whose purpose in life is to be side-effected. -Bert Halstead
That's one possible use, but another (unforunately incompatible) use also
presents itself:
This morning I heard a news announcement the Louisiana had passed a law
banning a set of "obscene" words (about five in all, I think) from appearing
on bumper stickers (except in typefaces 1/8 inch high or smaller!).
I suggest that (define <name>) introduce a variable whose purpose in life
should be to -never- be assigned or referenced in any way. That way, when
Louisiana lawmakers figure out what words are inappropriate for use in
programs, they can just DEFINE them away...
:-}
∂29-Jun-88 0121 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:UHRZB001@DBIUNI11.BITNET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Jun 88 01:21:48 PDT
Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 29 Jun 88 04:16:13 EDT
Received: from DBIUNI11.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4301; Wed, 29 Jun 88 03:02:41 EDT
Date: Wed, 29 Jun 88 09:02:12 EDT
To: scheme@mit-mc.ARPA
From: UHRZB001%DBIUNI11.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT
from: Bernd Nienaber
Universitaet Bielefeld
Computer center
Postfach 8640
D4800 Bielefeld
W.-Germany
Bitnet(Earn):UHRZB001@DBIUNI11
to: INFO-CSCHEME@MIT-MC
Dear Sirs,
some users of our computer centre want to run Scheme on the HP9000/850
minicomputer. Under which conditions can we get a Scheme licence for
the HP9000/850 ?
Regards
Bernd Nienaber
∂29-Jun-88 1135 @MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM Production quality Scheme compilers
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Jun 88 11:35:36 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 29 Jun 88 13:51:59 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUN 88 10:46:38 PDT
Date: 29 Jun 88 10:31 PDT
From: Fischer.pa@Xerox.COM
Subject: Production quality Scheme compilers
To: scheme@MC.LCS.MIT.EDU
Message-ID: <880629-104638-2611@Xerox>
Can anyone offer a list of manufacturers who sell (or distribute) production
quality Scheme compilers? Comments on the technology used and how that affects
benchmarks are much appreciated.
(ron)
∂02-Jul-88 1304 @MC.LCS.MIT.EDU:windley@iris.ucdavis.edu ML info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Jul 88 13:00:20 PDT
Received: from clover.ucdavis.edu (TCP 20036034401) by MC.LCS.MIT.EDU 2 Jul 88 03:22:42 EDT
Received: from iris.ucdavis.edu by clover.ucdavis.edu (5.59/4.7)
id AA18360; Sat, 2 Jul 88 00:12:37 PDT
Received: by iris.ucdavis.edu (5.51/3.14)
id AA25763; Sat, 2 Jul 88 00:20:44 PDT
Message-Id: <8807020720.AA25763@iris.ucdavis.edu>
Qotw: Never attribute to malice what
can be adequately explained by stupidity.
Pointers: (916) 752-7324/3168
To: scheme@mc.lcs.mit.edu
Subject: ML info
Date: Sat, 02 Jul 88 00:20:42 PDT
From: Phil Windley <windley@iris.ucdavis.edu>
I seem to remember some discussions about ML in this group several months
ago. Does anyone know of work on concurrent/multiprocessing versions of ML
or object-oriented extensions to ML? ML seems close enough in spirit to
Scheme that something like SCOOPS could be used as a model.
Phil Windley | windley@iris.ucdavis.edu
Robotics Research Lab | ucbvax!ucdavis!iris!windley
University of California, Davis |
∂03-Jul-88 1328 @MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu Scheme for SUN 386i
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jul 88 13:27:59 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 3 Jul 88 16:18:54 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04911; 3 Jul 88 16:14 EDT
Received: from carleton.edu by RELAY.CS.NET id aj18391; 3 Jul 88 16:03 EDT
Date: Fri, 1 Jul 88 16:04 CST
From: RKIRCHNE%carleton.edu@RELAY.CS.NET
Subject: Scheme for SUN 386i
To: scheme@mc.lcs.mit.edu
X-VMS-To: IN%"scheme@mc.lcs.mit.edu"
I've been using PC Scheme on a PC and Chez Scheme on our VAX. We've
just ordered a SUN 386i. What are our options for Scheme on this
machine? I expect to be able to continue to use PC Scheme, but wondered
about others. Is there any way to use SUN graphics from a Scheme?
∂04-Jul-88 1653 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: ML info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jul 88 16:53:21 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Jul 88 19:48:57 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA23716@BLOOM-BEACON.MIT.EDU>; Mon, 4 Jul 88 19:44:10 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Jul 88 09:13:53 GMT
From: mcvax!inria!dupont@uunet.uu.net (Francis Dupont)
Organization: INRIA, Rocquencourt. France
Subject: Re: ML info
Message-Id: <725@inria.UUCP>
References: <8807020720.AA25763@iris.ucdavis.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
> I seem to remember some discussions about ML in this group several months
> ago. Does anyone know of work on concurrent/multiprocessing versions of ML
> or object-oriented extensions to ML?
I am working on a parallel version of CAML (the local dialect of ML).
It is an extension of a strict+lazy system (like MultiLisp), it runs
on a shared memory multiprocessor (a Sequent Balance).
I don't know any object-oriented extension of ML. The static (compile-time)
polymorphic type-checking of ML and objects don't work well together. But
see Luca Cardelli's languages Amber and Quest.
Francis Dupont (INRIA Rocquencourt, France)
Internet : dupont@inria.inria.fr
Uucp : mcvax!inria!dupont
X400 : /C=Fr/ADMD=PTT/PRMD=aristote/ORG=inria/OU=pommard/S=Dupont/G=Francis
∂04-Jul-88 2357 @MC.LCS.MIT.EDU:goldberg@goldberg.cs.nyu.edu Re: ML info
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jul 88 23:57:36 PDT
Received: from goldberg.cs.nyu.edu (TCP 20036506026) by MC.LCS.MIT.EDU 5 Jul 88 01:42:45 EDT
Received: by goldberg.cs.nyu.edu (3.2/25-eef)
id AA04285; Tue, 5 Jul 88 01:36:51 EDT
Date: Tue, 5 Jul 88 01:36:51 EDT
From: Ben Goldberg <goldberg@goldberg.cs.nyu.edu>
Message-Id: <8807050536.AA04285@goldberg.cs.nyu.edu>
To: scheme@mc.lcs.mit.edu, windley@iris.ucdavis.edu
Subject: Re: ML info
I seem to remember some discussions about ML in this group several months
ago. Does anyone know of work on concurrent/multiprocessing versions of ML
or object-oriented extensions to ML? ML seems close enough in spirit to
Scheme that something like SCOOPS could be used as a model.
In the upcoming Lisp & FP conference, there is a paper by John Mitchell
and Lelita Jategoankar (spelling?) on ML+, an object oriented extension
to ML.
-Ben Goldberg
NYU
∂06-Jul-88 0938 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Miranda (correction)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jul 88 09:38:15 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 Jul 88 12:33:27 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA05535@BLOOM-BEACON.MIT.EDU>; Wed, 6 Jul 88 12:32:01 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 5 Jul 88 18:39:29 GMT
From: eagle!dat@bloom-beacon.mit.edu (D.A.Turner)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Subject: Miranda (correction)
Message-Id: <5333@eagle.ukc.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Miranda (correction)
-------
The arpanet address for obtaining further information about the new
release of the Miranda functional programming system is
mira-request%ukc@nss.cs.ucl.ac.uk
this address was garbled in an earlier message. In fact from many sites
mira-request@ukc.ac.uk (uucp: mcvax!ukc!mira-request)
will work too. Apologies to people whose requests for information
didn't get through.
∂06-Jul-88 1439 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl sanity check: <=, >=
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jul 88 14:39:23 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Jul 88 17:31:44 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22662; 6 Jul 88 15:52 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa12538; 6 Jul 88 15:34 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA14086; Wed, 6 Jul 88 11:27:51 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA07253; Wed, 6 Jul 88 11:29:04 PDT
Message-Id: <8807061829.AA07253@tekchips.CRL.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: willc@tekchips.crl
Subject: sanity check: <=, >=
Date: 06 Jul 88 11:29:02 PDT (Wed)
From: willc@tekchips.crl
R3RS says that (<= x y) is #t if x and y are "monotonically nondecreasing"
and that (>= x y) is #t if x and y are "monotonically nonincreasing". I
interpret this to mean that (<= x y) is equivalent to (not (> x y)), and
that the following transcript shows correct behavior with respect to the
unordered case in IEEE standard floating point arithmetic. Comments?
>>> (define x (expt 10.0 500.0))
x
>>> x
#<INFINITY>
>>> (define y (- x x))
y
>>> y
#<NOT A NUMBER>
>>> (< 3 y)
#f
>>> (= 3 y)
#f
>>> (> 3 y)
#f
>>> (<= 3 y)
#t
>>> (>= 3 y)
#t
∂06-Jul-88 1543 @MC.LCS.MIT.EDU:gls@Think.COM sanity check: <=, >=
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jul 88 15:43:19 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 6 Jul 88 18:41:15 EDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Wed, 6 Jul 88 17:45:03 EDT
Received: by brigit.think.com; Wed, 6 Jul 88 18:39:51 EDT
Date: Wed, 6 Jul 88 18:39:51 EDT
From: gls@Think.COM
Message-Id: <8807062239.AA25126@brigit.think.com>
To: willc@tekchips.crl
Cc: rrrs-authors@mc.lcs.mit.edu, willc@tekchips.crl
In-Reply-To: willc@tekchips.crl's message of 06 Jul 88 11:29:02 PDT (Wed) <8807061829.AA07253@tekchips.CRL.TEK.COM>
Subject: sanity check: <=, >=
Date: 06 Jul 88 11:29:02 PDT (Wed)
From: willc@tekchips.crl
R3RS says that (<= x y) is #t if x and y are "monotonically nondecreasing"
and that (>= x y) is #t if x and y are "monotonically nonincreasing". I
interpret this to mean that (<= x y) is equivalent to (not (> x y)), and
that the following transcript shows correct behavior with respect to the
unordered case in IEEE standard floating point arithmetic. Comments?
>>> (define x (expt 10.0 500.0))
x
>>> x
#<INFINITY>
>>> (define y (- x x))
y
>>> y
#<NOT A NUMBER>
>>> (< 3 y)
#f
>>> (= 3 y)
#f
>>> (> 3 y)
#f
>>> (<= 3 y)
#t
>>> (>= 3 y)
#t
I think (<= y 3) and (>= y 3) being #f is more appealing.
(1) This is consistent with the recommended treatment of .GE. and .LE.
by IEEE standard 754.
(2) "monotonically nondecreasing" does not mean the same thing as
"not monotonically decreasing". At least, I didn't think they meant
the same thing when I put the former in CLtL.
--Guy
∂07-Jul-88 1929 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: Multiple values, Version 1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jul 88 19:29:19 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 7 Jul 88 22:26:53 EDT
Received: by iuvax.cs.indiana.edu; id AA01837; Thu, 7 Jul 88 19:27:55 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Thu, 7 Jul 88 19:27:55 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Multiple values, Version 1
Subject: Re: Multiple values, Version 1
It would be clearer if
Most continuations ignore all but the first return value, ...
read instead
Most continuations expect one value and ignore all but the first of
multiple values, ...
Also, it would help if there were an example that makes clear the relation
between tail-recursion and multiple values, such as:
(define return123 (lambda () (values 1 2 3)))
(with-values (lambda () (return123)) list) ==> (1 2 3)
I also second the proposal to make <init>s optional in
LET, LET*, named LET, and LETREC (but not DO).
∂08-Jul-88 0047 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU informal proposal: A Modified Procedural Interface (LONG)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Jul 88 00:47:14 PDT
Received: from chamarti (TCP 2206400253) by MC.LCS.MIT.EDU 8 Jul 88 01:41:21 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Fri, 8 Jul 88 01:39:53 edt
Date: Fri, 8 Jul 88 01:39:53 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8807080539.AA07652@chamarti>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu, jinx@CHAMARTIN.AI.MIT.EDU
In-Reply-To: Robert Hieb's message of Fri, 24 Jun 88 09:26:39 EST
Subject: informal proposal: A Modified Procedural Interface (LONG)
Reply-To: jinx@zurich.ai.mit.edu
I think your proposal for variable arity procedures is quite neat, but
it suffers from some problems that we have observed at MIT with our
current optional argument extension. The most noticeable, which
motivated the "default objects" in Will's proposal, arises from cases
like
(define (make-bracket-unparser core)
(lambda (object #!optional port radix)
(write-char #\[ port)
(core object port radix)
(write-char #\] port)))
which in the context of your proposal would be written as
(define (make-bracket-unparser core)
(lambda*
((object)
(write-char #\[)
(core object)
(write-char #\]))
((object port)
(write-char #\[ port)
(core object port)
(write-char #\] port))
((object port radix)
(write-char #\[ port)
(core object port radix)
(write-char #\] port))))
There is a lot of replicated code, and it only gets worse when there
are more "optional" parameters whose values the programmer wants to
default in the procedures invoked.
A related problem is that it is hard to default "intermediate"
parameters. For example, it is cleaner (I think) to write
((make-bracket-unparser write-number-heuristically)
23
(make-default-object) ; = ((lambda (#!optional x) x))
#x10)
than to write
((make-bracket-unparser write-number-heuristically)
23
(current-output-port)
#x10)
since the latter has only the desired effect if in fact the default
port is the value of (current-output-port).
In other words, the proposal with default objects allows specification
of only those parameters for which we do not want to use the default,
while your proposal forces the user to specify all parameters to the
LEFT of those which s/he REALLY wants to provide. This is a serious
breach of abstraction, since s/he must know which way these parameters
are defaulted in order to obtain the same effect as if they had not
been provided.
Some other comments with respect to your proposal and your message:
1) You mention that the same objections that hold for returning
multiple values in a list should hold for passing "multiple arguments"
in a list, but you are really confusing two issues here.
One issue is whether the argument passing mechanism and the value
return mechanism (which is merely passing arguments to the
continuation) inherently involves lists, and the answer to this should
clearly be no. Returning a fixed number of values to a continuation
expecting that number of values should not be very different from
passing a fixed number of arguments to a procedure expecting that
number of arguments. Implementations are free to use lists of values
(and lists of arguments), but this fact should not be apparent to the
user.
The other issue is how to RECEIVE (by a procedure or a continuation)
arbitrary numbers of values while providing a fixed finite list of
formal parameter names. Lists happen to be convenient and natural
data structures to "bundle up" many objects into a single object from
which the individual objects can be extracted, yet allowing simple
manipulation of the aggregate. Many other data structures would do
nicely, but lists are (arguably) the most appropriate for Lisp.
2) Introducing multiple-value locations, and in particular, making
assignment work "correctly" with them makes the implementation of
variables in the language considerably less efficient. Consider
carefully the implications of the following ugly fragment of code:
(let* ((x 'unspecified)
(test
(lambda ()
(if x
'yes
'no)))
(first
(begin (set! x 4)
(test)))
(second
(begin (set! x (mumble))
(test))))
(list first second))
under the following possible definitions of mumble not available at
compile time
;; version 1
(define (mumble)
3)
;; version 2
(define (mumble)
(values 3 4))
3) I agree with you that programmers can incur a substantial
algorithmic cost by carelessly using lists in procedures expecting an
arbitrary number of arguments. For example,
(define plus
(lambda all
(if (null? all)
0
(binary-plus (car all)
(apply plus (cdr all))))))
is quadratic in space (and therefore time), but any clever programmer
will realize that this is a bad program and rewrite it to be linear.
However, the equivalent program
(define plus
(lambda*
(() 0)
((x & rest)
(binary-plus x (plus & rest)))))
will probably also be quadratic in space (and time), but it is much less
obvious how to rewrite it to avoid this cost. To obtain linear
behavior the programmer must rely on a clever implementation (which I
haven't discovered) and is helpless if the implementation is not
clever enough.
∂10-Jul-88 1405 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: Multiple values, Version 1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Jul 88 14:05:49 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 10 Jul 88 17:03:36 EDT
Received: by iuvax.cs.indiana.edu; id AA19175; Sun, 10 Jul 88 15:36:50 EST
Received: by iuvax.cs.indiana.edu (5.54/1.5)
Date: Sun, 10 Jul 88 15:36:50 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Multiple values, Version 1
Subject: Re: Multiple values, Version 1
It would be clearer if
Most continuations ignore all but the first return value, ...
read instead
Most continuations expect one value and ignore all but the first of
multiple values, ...
Also, it would help if there were an example that makes clear the relation
between tail-recursion and multiple values, such as:
(define return123 (lambda () (values 1 2 3)))
(with-values (lambda () (return123)) list) ==> (1 2 3)
I also second the proposal to make <init>s optional in
LET, LET*, named LET, and LETREC (but not DO).
∂11-Jul-88 1011 @MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU duplicated formals
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:11:34 PDT
Received: from void (TCP 2206400236) by MC.LCS.MIT.EDU 11 Jul 88 12:28:05 EDT
Received: by VOID.AI.MIT.EDU; Mon, 11 Jul 88 12:27:28 edt
Date: Mon, 11 Jul 88 12:27:28 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8807111627.AA09064@void>
To: willc%tekchips.crl.tek.com@relay.cs.net
Cc: hal@VOID.AI.MIT.EDU, rrrs-authors@mc.lcs.mit.edu
Subject: duplicated formals
Reply-To: JAR@ZURICH.AI.MIT.EDU
Proposed:
The list of formal variables in LAMBDA, LET, LETREC, and DO (but not
LET*) should not contain duplications. E.g. (LAMBDA (X Y X) ...) is
illegal.
In the case of named LET, the formals in the initial bindings list
should be distinct, but it's OK (useless, however) if the "name"
is also a formal. E.g., (LET FOO ((X 1) (FOO 2)) ...) is legal.
Rationale: the constraints on the derived expression types should all
derive from the primitive expression type (namely LAMBDA) from which
they derive.
∂11-Jul-88 1416 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Documentation for T
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88 14:16:32 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Jul 88 17:11:27 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA12106@BLOOM-BEACON.MIT.EDU>; Mon, 11 Jul 88 17:01:06 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Jul 88 20:43:30 GMT
From: dartvax!kinsman.dartmouth.edu!hugo@bu-cs.bu.edu
Organization: Dartmouth College
Subject: Documentation for T
Message-Id: <9203@dartvax.Dartmouth.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi,
I just gleefully managed to FTP T from wheaties.ai.mit.edu only to
find out that the documentation was done in SCRIBE, and besides that,
it seemed to describe an earlier version of the system. I was
wondering if anyone out there has a newer version of the documents
that is in either TeX, Interpress, or postscript format?
Thanks a bunch,
Pete
∂12-Jul-88 0947 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP Registration -- FINAL CALL
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 09:47:49 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 12 Jul 88 12:43:17 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA10136; Tue, 12 Jul 88 10:42:01 MDT
Received: by cons.utah.edu (5.54/utah-2.0-leaf)
id AA26236; Tue, 12 Jul 88 10:41:49 MDT
Date: Tue, 12 Jul 88 10:41:49 MDT
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8807121641.AA26236@cons.utah.edu>
To: common-lisp@sail.stanford.edu, fp@cs.yale.edu, scheme@mc.lcs.mit.edu
Subject: L&FP Registration -- FINAL CALL
This is the final call for registration for the conference. ACM is
accepting registration by EMAIL, so please send your information to
them (meetings@acmvm.bitnet). Note, if you plan on using a credit
card, please include the name on the card, the type of card, the
number, and the expiration date. Also, please include the following
information. NOTE -- the final deadline for advance registration is
this FRIDAY, JULY 15. Also, you will have to make your own
reservations at Snowbird by calling Snowbird Central Reservations at
(800)453-3000 or (801)532-1700.
It looks like it will be a great conference. We are looking forward to
seeing you there.
Bob.
====================================================================
====================== L&FP 88 Registration Form ====================
The registration fees for applications prior to June 24 are:
Student $75
ACM or SIG (PLAN, ART, or ACT) Member Only $250
ACM and SIG Member $225
Non-Member $290
The registration fees for applications after that date are:
Student $100
ACM or SIG (PLAN, ART, or ACT) Member Only $300
ACM and SIG Member $275
Non-Member $350
Additional banquet tickets (for students or guests) are $40
Additional luncheon tickets are $12.50
Make your own application form including
Your Name
Company/Institution
Address
Telephone
E-mail Address
Membership status in ACM and SIGPLAN/SIGART/SIGACT including
membership number
Your fee category (as described above)
Your order for any extra banquet or luncheon tickets
Total fees enclosed
Form of payment (check/credit card)
Credit card type (Mastercard, Visa, or Amer Express), number,
expiration date, and signature if paying by credit card
Mailing List Restriction: (one of No Restictions, ACM and Other
Society Announcements, ACM Announcements)
If paying by check, make check payable (in US funds only!) to:
ACM LFP '88
Mail your form and payment to:
ACM LFP '88
P.O. Box 12105
Church Street Station
New York, NY 10249
∂14-Jul-88 1526 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com agenda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jul 88 15:25:57 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Jul 88 18:24:04 EDT
Received: from relay2.cs.net by RELAY.CS.NET id an22846; 14 Jul 88 17:45 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa07444; 14 Jul 88 17:33 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA29468; Wed, 13 Jul 88 17:32:54 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA10164; Wed, 13 Jul 88 17:34:08 PDT
Message-Id: <8807140034.AA10164@tekchips.CRL.TEK.COM>
To: RRRS-AUTHORS@mc.lcs.mit.edu
Cc: willc@tekchips.crl
Subject: agenda
Date: 13 Jul 88 17:34:06 PDT (Wed)
From: willc@tekchips.crl
Agenda for the RRRS meeting on Sunday, 24 July.
The agenda is divided into four parts. The first part consists of relatively
noncontroversial proposals whose adoption in some form is recommended by the
agenda committee. The agenda committee makes no recommendations concerning
the rest of the agenda.
The second part of the agenda considers general questions of policy. The
third part consists of major proposals. Some of these may not be ready for
adoption but would benefit from discussion. The fourth part consists of all
remaining proposals.
**PART 1: CLEANUPS**
RESERVED WORDS AND PORTABLE CODE. Require that implementations
provide some way for programmers to work in a syntactic environment
containing no reserved words other than those found in the report,
without requiring that this be the default syntactic environment.
DISJOINTNESS OF TYPES. Require that the following sets of objects
be disjoint: booleans, pairs, symbols, numbers, characters, strings,
vectors, procedures. Issue: add the singleton set containing the
empty list to the list. Issue: remove characters from the list.
Issue: add promises to the list, or flush force and delay altogether
(see **OTHER PROPOSALS**).
ELIMINATE NIL, T. Remove nil and t from the report.
EQV?. Clean up the specification of eqv?, removing the requirement
that it be true of two empty strings or empty vectors.
DUPLICATE FORMALS ARE IN ERROR. The list of formal variables in
lambda, let, letrec, and do (but not let*) should not contain
duplications. E.g. (lambda (x y x) ...) is an error. In the case
of named let, the formals in the initial bindings list should be
distinct, but it is ok (albeit useless) for the "name" to duplicate
a formal. E.g. (let foo ((x 1) (foo 2)) ...) is legal.
CHANGE WORDING OF LETREC RESTRICTION. From "...without referring
to the value of any <variable>" to "...without referring to the
value or location of any variable". Example:
(letrec ((wanna-be-a-doctor 'doctor)
(imagine-my-surprise! (begin
(set! wanna-be-a-doctor 'nurse)
'zowie)))
wanna-be-a-doctor)
CLARIFY WORDING OF LETREC. Add the word "ALL" as follows:
"...in a letrec expression, ALL the bindings are in effect while
their initial values are being computed..."
CLARIFY MEANING OF QUASIQUOTE. As in Pavel Curtis's proposal.
CLARIFY STATUS OF CI. Though CI is described as a suffix,
it is generally just embedded.
CLARIFY THE SPECIFICATION OF TRUNCATE. Specify the sign of
the result, and specify the absolute value of the result.
IMPROVE THE DISCUSSION OF EXACTNESS AND INEXACTNESS. As in
R↑3.5RS.
CHANGE THE SYNTAX OF NUMBERS. As in R↑3.5RS: use the exponent
marker to indicate the precision of inexact numbers, and use
3+i4, 3-i4, 3+i, 3-i, +i4, -i4, +i, -i, and 3@3.14159265 for
complex numbers. Issue: 3+4i would be more in keeping with
common mathmatical practice.
CLARIFY THE STATUS OF EXPONENTS. As in R↑3.5RS: numbers that
contain decimal points or exponents must be in decimal radix.
EXPONENTS ILLEGAL IN FRACTIONS. As in R↑3.5RS: 3/4e5 is not
legal.
EXACTNESS AND INEXACTNESS OF CONSTANTS. Constants that contain
no explicit exactness prefix are inexact if they contain any of
the following:
an explicit inexactness prefix
an at-sign indicating polar representation
a decimal point
a sharp sign indicating a "don't care" digit, as in 123##
A constant may also be inexact if it contains a negative exponent;
this is implementation-dependent. Otherwise the constant is exact.
Issue: 3@0 (inexact by above rules)
Issue: 1e5 (exact by above rules)
Issue: 1e-5 (implementation-dependent by above rules)
**PART 2: POLICY ISSUES**
FLUSH OPTIONAL FEATURES. Do away with the distinction between
essential and optional features. In effect, make everything
essential. Issue: some optional features should be dropped rather
than made essential; which?
MAKE PROCEDURES MORE REGULAR. Add vector-copy, list-copy,
list-fill!, list-set!, (make-list k); or remove procedures
to make them more regular across the different kinds of
sequences. Issue: what's the policy? Issue: generic
copiers, fillers, etc. Issue: optional or essential?
UNDERSPECIFICATION. What kinds of underspecification are
desirable? What kinds are undesirable?
**PART 3: MAJOR PROPOSALS**
MACROS. No complete proposal is ready for consideration. The
macro and extend-syntax syntaxes have been proposed as least
common denominator(s) to tide us over until we have a real macro
proposal.
MODULES. Pavel Curtis, Jonathan Rees, and John Ramsdell have
sketched proposals, but no complete proposals are ready for
consideration. The next four proposals are related to this.
REPLACE LOAD WITH INCLUDE. The load procedure is convenient for
interactive program development, but its dependence on an object
with state (the external file system) makes it less satisfactory
than include would be for describing complete programs.
Presumably implementations would retain load as part of their
programming environment even if it were replaced by include in
the report. Issue: An alternative is to change the meaning of
load in the report. Issue: Include also depends on an external
file system; the only difference is that the dependency is removed
at compile time rather than run time.
FIRST CLASS ENVIRONMENTS. In my opinion, no proposal for
environments remains on the table. A proposal could be built
around make-environment, the-environment, build-environment,
Guzowski's with, or Pavel's recently withdrawn proposal.
ADD EVAL. Add eval to section 6.10.4. Issue: one or two arguments?
If two, how do you get an appropriate second argument?
ADD SECOND ARGUMENT TO LOAD. If eval is added and takes a second
argument, then shouldn't a second argument should be added to load
also?
ADD LAMBDA*. Adopt the Hieb/Dybvig proposal for procedures that
dispatch on the number of arguments they are given, for allowing
multiple values to be stored in variables, and for the & syntax.
This proposal is an alternative to the next two proposals.
MULTIPLE RETURN VALUES. Add optional procedures values and
with-values such that (values x1 ...) returns values x1 ... and
(with-values thunk proc) calls proc on the values returned by
thunk. Issue: what do continuations that currently expect one
return value do when given zero values or more than one value?
The most popular answers are:
a. It is an error.
b. Ignore extra values; it is an error if there are no return
values.
c. Ignore extra values; the continuation gets an unspecified
value if there are no return values.
d. Ignore extra values; the continuation gets #f if there are
no return values.
OPTIONAL ARGUMENTS. Add an optional #!optional syntax to lambda
expressions to support optional arguments:
(lambda (x #!optional y z . w) ...)
If not supplied, y and z are bound to new locations holding a
special default object. Add the procedure default-object? so that
(default-object? y) is true if y is not supplied. It would be
possible to pass the default object as an actual argument, thereby
making it possible to obtain the default for y while specifying z
explicitly.
RECORD OBJECTS. Jonathan's proposal:
make-record-type
record-constructor
record-predicate
record-accessor
record-updater
Issue: If the object returned by make-record-type isn't a type
but a "descriptor", then maybe the name is wrong.
Issue: what about record-copier?
Issue: inheritance.
Issue: something resembling type-of.
Issue: Initialization of all fields, positionally, rather than
initialization of selected fields by name.
Issue: Optional?
**PART 4: OTHER PROPOSALS**
CHANGE WORDING OF SET! RESTRICTION. From "<Variable> must be
bound in some region enclosing the set! expression or at top
level" to "<Variable> must be bound in an enclosing lexical
environment". Issue: need examples of code that illustrate
the intended differences between the two wordings.
FORMAL SEMANTICS FOR NUMERIC CONSTANTS. As proposed by Clinger,
who doesn't think it is necessary.
ELIMINATE DO. Remove do from the language.
ELIMINATE NAMED LET. Remove named let from the language.
ELIMINATE =>. Remove the => notation from the language.
ELIMINATE CASE. Remove case from the language.
ELIMINATE FORCE AND DELAY. Or make promises disjoint from other
types.
ELIMINATE LAST-PAIR. Remove last-pair from the language.
ELIMINATE NUMERIC FORMATS. Eliminate (or redesign or simplify)
the format arguments to number->string.
ELIMINATE CALL-WITH-CURRENT-CONTINUATION. Remove
call-with-current-continuation because it makes programs hard to
understand.
DEFINE WITH NO EXPRESSION. Optionally allow (define x) for top level
definitions only. Issue: why not for internal definitions? Issue:
If it becomes available for internal definitions, then it should also
be available for letrec, let, let*, named let (?), and do (??).
ADD CALL. Add essential syntax: (call proc arg1 ...).
ADD STATIC. Add essential syntax: (static id).
PEEK-CHAR. Add a peek-char procedure. Issue: essential?
ADD EQ-HASH, EQV-HASH. (eq? x y) implies (= (eq-hash x) (eq-hash y)),
and (eqv? x y) implies (= (eqv-hash x) (eqv-hash y)). Implementations
are encouraged to make the converse as probable as possible.
ADD DAYS-AFTER-J2000.0.
VALUE RETURNED BY ONE-ARMED IF, COND. Specify that (if E0 E1) returns
#f if E0 is false, and that (cond ...) returns #f if no clauses apply.
VALUES RETURNED BY SIDE EFFECTS. Change the semantics of
(set! x e), (set-car! x e), (write e p), et cetera, so that
they return the value of e. Issue: why not return #!unspecified?
LEFT TO RIGHT EVALUATION OF ARGUMENTS. Change the semantics of
procedure calls so that expressions are evaluated from left to
right.
LEFT TO RIGHT EVALUATION OF DEFINITIONS. Change the semantics
of internal definitions so that they are evaluated from left to
right. Issue: do the same for letrec?
CHANGE THE SPECIFICATION OF AND. Change and so it always returns
#t or #f. Issue: the last position of an and becomes non-tail-
recursive. Issue: If this proposal is not adopted, must and
return the first false value it sees, or can it simply return #f?
RENAME CHARACTER COMPARISON PREDICATES. Change char=? etc to
char= etc.
RENAME SET! TO SET.
RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR. Issue:
non-destructive versions make sense even though they're not in the
report.
RENAME CHAR-READY? TO READ-CHAR-READY?. Issue: name:
READY-TO-READ-CHAR? Issue: replace instead
with read-char? (TYI-NO-HANG)?
RELAX THE LETREC RESTRICTION. Require implementations to find
an order that works, if any does. Issue: not computable?
DON'T SPECIFY WHETHER THE EMPTY LIST COUNTS AS TRUE OR FALSE.
∂14-Jul-88 2021 @MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU Proposals compendium
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jul 88 20:21:22 PDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Jul 88 23:13:44 EDT
Date: Thu, 14 Jul 88 23:16:17 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Proposals compendium
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <412510.880714.JAR@AI.AI.MIT.EDU>
I have mailed hardcopy of a document called "Proposals for a Revised↑4
Scheme Report" to everyone who sent their address to Will. The document
is organized around Will's agenda, and consists almost entirely of
extracts from messages that have appeared on this list.
I also included in the mailing two other documents: (1) edits made to
the numbers and syntax sections of the R↑3 report by an ad hoc numbers
committee following last summer's meeting, and (2) the "syntactic
closures" paper by Alan Bawden and myself. The latter is for
informational purposes only and does not constitute a proposal for
extending the language.
∂14-Jul-88 2043 @MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com time & place of R*RS authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Jul 88 20:42:54 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 14 Jul 88 23:34:06 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab26383; 14 Jul 88 23:17 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa09069; 14 Jul 88 23:06 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA02215; Thu, 14 Jul 88 18:50:19 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA04054; Thu, 14 Jul 88 18:52:34 PDT
Message-Id: <8807150152.AA04054@tekchips.CRL.TEK.COM>
To: RRRS-AUTHORS@mc.lcs.mit.edu
Cc: willc@tekchips.crl
Subject: time & place of R*RS authors' meeting
Date: 14 Jul 88 18:52:32 PDT (Thu)
From: willc@tekchips.crl
The R*RS authors' meeting will begin at 8:45 am on Sunday, 24 July,
in the Maybird room of Cliff Lodge (the LFP hotel). We have the room
until 6 o'clock that evening. An overhead projector and screen will
be available. Thirty two people have indicated they will come.
Please note that this meeting is distinct from the IEEE standards
meeting, which will take place Wednesday afternoon.
See you at Snowbird,
Will
∂15-Jul-88 0457 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Replace LETREC with "relaxed" internal DEFINES.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 04:57:32 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 15 Jul 88 07:48:30 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA07927; Fri, 15 Jul 88 07:47:31 EDT
Posted-Date: Fri, 15 Jul 88 07:47:43 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA15914; Fri, 15 Jul 88 07:47:43 EDT
Date: Fri, 15 Jul 88 07:47:43 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807151147.AA15914@huxley.sun.uucp>
To: RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 13 Jul 88 17:34:06 PDT (Wed) <8807140034.AA10164@tekchips.CRL.TEK.COM>
Subject: Replace LETREC with "relaxed" internal DEFINES.
From the agenda:
>RELAX THE LETREC RESTRICTION. Require implementations to find
>an order that works, if any does. Issue: not computable?
I think the whole point of relaxing the LETREC restrictions was to
allow the replacement of LETREC's and many LET's with local DEFINE's.
If the strong components of some local DEFINE's dependency graph is
topologically sorted, an interpreter or compiler can generate the best
combination of LETREC's and LET's. Programmers would then be freed of
having to think about current large distinction between local
definitions and top level definitions. The issue is:
RELAX LOCAL DEFINES RESTRICTIONS AND FLUSH LETREC. Require
implementations to treat local DEFINE's as the best combination of
LET's and LETREC's.
John
PS. I would like to see file compilers treat top level defines just as
I suggest local defines be treated. Why should the order be so
important within files?
∂15-Jul-88 1855 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu OBJ3 Release
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 18:55:11 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Jul 88 21:43:08 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA12616@BLOOM-BEACON.MIT.EDU>; Fri, 15 Jul 88 21:38:40 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Jul 88 23:56:31 GMT
From: joyce!csl!winkler@ames.arpa (Timothy Winkler)
Organization: Computer Science Lab, SRI International
Subject: OBJ3 Release
Message-Id: <5901@csl.CSL.SRI.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Dear Colleagues:
Release 1.0 of OBJ3 is now available!
OBJ embodies basic design choices that are quite different from those of other
programming languages, even other functional programming languages. OBJ3 is
the latest in a series of systems consisting of an interpreter and an
environment, and it has the following properties:
1. OBJ3 is logical, in the sense that there is a logical system L such that
* statements in OBJ3 programs are sentences in L,
* the denotational semantics of an OBJ3 program P is an initial model
of P, and
* operational semantics is given by (efficient) deduction in L.
This allows OBJ3 to be used as a theorem prover for L. (In fact, the
logical system L for OBJ3 is order sorted equational logic; see below.)
2. OBJ3 has parameterized programming, which allows very flexible program
structuring and reuse, giving the expressive power of higher order
programming while retaining a first order logic, and supporting the
following features:
* objects to contain executable code, and theories to define properties;
* parameterized modules, with theories to define interfaces;
* views to define instantiation (binding) of parameterized modules, and
to assert properties of modules, and
* module expressions, which describe complex (sub)system as
interconnections of given modules (possibly parameterized), and then
actually constructs them when evaluated.
4. OBJ3 is based on order sorted equational logic, which provides a
rigorous basis for
* user-definable subtypes
* exception handling
* multiple inheritance
* operation overloading and
* retracts a form of run time type checking that supports a
strong typing which is as flexible as weak typing.
5. OBJ3 has user-definable evaluation strategies, which
* can be eager, lazy, or more exotic combinations,
* are user definable for each operation separately (rather than
globally), and are computed by default (using strictness analysis)
if not given explicitly.
6. OBJ3 has pattern matching modulo associativity and/or commutativity,
plus identity by completion.
OBJ3 also has some features that are unusual but not unique, including
1. user definable mixfix syntax, with precedence,
2. user-optional memoisation on an operation-by-operation basis,
3. user-definable built-in modules for efficient implementation of
basic abstract data types, such as numbers and characters, and
4. module import hierarchies.
OBJ3 has been successfully used for a variety of applications, including
research and teaching in
1. software design
2. software specification
3. rapid prototyping
4. theorem proving
5. hardware verification
6. functional programming.
Here is a cute little proof in OBJ3:
############################################################################
---> /dir/goguen/obj/proofs/mmm.obj
---> Fermat's "little theorem": m**p=m(mod p), for p=3
obj NAT is sort Nat .
op 0 : -> Nat .
op s_ : Nat -> Nat [prec 1] .
ops (_+_)(_*_) : Nat Nat -> Nat [assoc comm] .
vars L M N : Nat .
eq M + 0 = M .
eq M + s N = s(M + N) .
eq M * 0 = 0 .
eq M * s N = (M * N)+ M .
eq L * (M + N) = (L * M)+(L * N) .
eq M + M + M = 0 .
endo
---> base case, m = 0
reduce 0 * 0 * 0 == 0 .
---> induction variable and hypothesis
obj VARS is extending NAT .
op m : -> Nat .
eq m * m * m = m .
endo
---> induction step
reduce (s m)*(s m)*(s m) == s m .
---> QED
############################################################################
OBJ3 is written in Kyoto Common Lisp (KCL) and has been compiled on Sun3's;
presumably, it can be compiled on any machine with a Common Lisp compiler. We
can send you an executable form of OBJ3 for Sun3's, which occupies about 4
Mbytes of disk space, or you can build OBJ3 yourself from sources, which will
require about 1 Mbyte disk space for the sources and up to 3 Mbyte for the
construction. You will also need a license for KCL, or some other Common
Lisp. KCL needs 4 Mbytes for its sources, up to 10 Mbytes for construction,
and its executable occupies about 2 Mbytes. Our distribution media are Sun
cartridges, and 1/2in. tape at 1600 bpi in Unix tar format. Our shipment will
include a file of OBJ3 examples and some documentation.
If you wish to receive the OBJ3 distribution tape, please send a request to:
Judith Burgess, Librarian
Computer Science Laboratory
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025, USA
Telephone: (415) 859-5924
ARPAnet: burgess@csl.sri.com
Judith will then send you the OBJ3 Information Form, and License Agreement,
with instructions on how to fill them out. When you return them to us,
appropriately filled out and signed, with a check or money order for $150 in
US dollars payable to SRI International, we can then send you the tape and
documentation.
Sincerely yours,
Joseph Goguen, Jose Meseguer, and Timothy Winkler
Computer Science Laboratory
SRI International
333 Ravenswood Ave.
Menlo Park, California 94025, USA
∂16-Jul-88 1003 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme shellscripts
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jul 88 10:03:25 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 Jul 88 12:58:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA28866@BLOOM-BEACON.MIT.EDU>; Sat, 16 Jul 88 12:50:02 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Jul 88 08:01:32 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Subject: Scheme shellscripts
Message-Id: <1666@kalliope.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Hi! Thought this might be of interest.
If you've tried using shellscripts to build your own Un*x commands, felt the
shell language a bit too hairy, and would rather use Scheme instead, here's a
short fix. This assumes that the available Scheme interpiler can be called
at the Un*x prompt with a file-name which is automatically loaded before
producing the interactive loop. E.g., Chez Scheme (copyright R. Kent Dybvig).
A shellscript written in Scheme is like any other Scheme file, except that its
first line has to be:
runschemescript "$*" '
and its last line:
'
The quotes are used to delimit the Scheme code which forms the body of the
script. The script consists of a call of the Un*x command `runschemescript'
with two arguments, the first being the list of arguments to the Scheme
script, and the second the text of the Scheme code in the script. Thus, a
Scheme shellscript is a *true* schellscript, i.e., it is callable at the Un*x
command-line, though the main part of it is a piece of text which is Scheme.
The command `runschemescript' used above is a shellscript written in the usual
shell language. It is the following relatively simple piece of cshell:
**************************************************************************
echo > .tmpfile '(set! $* (quote (' $1 ')))'
echo >>.tmpfile $2
echo >>.tmpfile '(exit)'
scheme .tmpfile
**************************************************************************
In effect, `runschemescript' creates a temp Scheme file which sets a global
variable $* to the list of arguments supplied to the Scheme script, runs the
script which uses $* to refer to its arguments and exits. This file is then
run with the Scheme interpiler.
An example Scheme shellscript is the Scheme compiler `sc' which can be invoked
at the Un*x command-line, in makefiles, etc [like `cc']. My `sc' looks like
*******************************************************************************
runschemescript "$*" '
(case (length $*)
[1 (compile-file (symbol->string (car $*)))]
[2 (compile-file (symbol->string (car $*)) (symbol->string (cadr $*)))]
[3 (let ([$1 (car $*)] [$2 (cadr $*)] [$3 (caddr $*)])
(cond [(eq? $1 `-o)
(compile-file (symbol->string $3) (symbol->string $2))]
[(eq? $2 `-o)
(compile-file (symbol->string $1) (symbol->string $3))]
[else (printf "Bad args to sc: ~a~n" $*)]))]
[else (printf "Bad args to sc: ~a~n" $*)])
'
******************************************************************************
$* being a simple Scheme list of symbols, any processing of arguments or
options is straightforward. Some nits are: These Scheme shellscripts
always have to be enclosed in runschemescript "$*" ' <body> '. The quote-
character ' {a common enough character in Scheme!} cannot be used in the
script's body as it interferes with the shell's delimiter characters--instead
one should use the backquote ` or "quote". Typical shellscripts use other
Un*x commands in their bodies: in Ch*z Scheme, there is a function "system"
which enables us to call Un*x commands; but this may not be available
in other Schemes. Even in this case, calling a Scheme shellscript from
within a Scheme shellscript will have multiple invocations of the Scheme
interpreter running simultaneously, which doesn't help a whole lot in
maintaining efficiency. Strangely, one doesn't have to bother about the
same file .tmpfile being used for such nesting--once the file is loaded,
it doesn't matter if it is used for something else.
On the whole, I've found that in a Un*x environment which supports Ch*z
Scheme, the above technique beats writing shellscripts in cshell for sheer
ease and maneuvrability. One can then, if one chooses, convert a fully
debugged Scheme script to a cshell script (or a C program) to recover
efficiency.
If anyone can suggest further improvement I'll be glad to hear of it.
--dorai
∂16-Jul-88 2044 @MC.LCS.MIT.EDU:aab@CADDR.AI.MIT.EDU RE: agenda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jul 88 20:44:22 PDT
Received: from caddr (TCP 2206400243) by MC.LCS.MIT.EDU 16 Jul 88 23:42:45 EDT
Received: by CADDR.AI.MIT.EDU; Sat, 16 Jul 88 23:43:20 edt
Date: Sat, 16 Jul 88 23:43:20 edt
From: aab@CADDR.AI.MIT.EDU (Andrew A. Berlin)
Message-Id: <8807170343.AA04677@caddr>
To: willc@tekchips.crl
Cc: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl
In-Reply-To: willc@tekchips.crl's message of 13 Jul 88 17:34:06 PDT (Wed) <8807140034.AA10164@tekchips.CRL.TEK.COM>
Subject: RE: agenda
Reply-To: aab@zurich.ai.mit.edu
RENAME SET! TO SET.
RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR. Issue:
non-destructive versions make sense even though they're not in the
report.
Could you please elaborate on the reasons for this suggested change?
How do people feel about this?
- Andy
∂17-Jul-88 1252 @MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU agenda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Jul 88 12:51:56 PDT
Received: from void (TCP 2206400236) by MC.LCS.MIT.EDU 17 Jul 88 15:50:21 EDT
Received: by VOID.AI.MIT.EDU; Sun, 17 Jul 88 15:50:13 edt
Date: Sun, 17 Jul 88 15:50:13 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8807171950.AA11762@void>
To: aab@zurich.ai.mit.edu
Cc: willc@tekchips.crl.tek.com, RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: Andrew A. Berlin's message of Sat, 16 Jul 88 23:43:20 edt <8807170343.AA04677@caddr>
Subject: agenda
Reply-To: jar@zurich.ai.mit.edu
Date: Sat, 16 Jul 88 23:43:20 edt
From: aab@CADDR.AI.MIT.EDU (Andrew A. Berlin)
... Could you please elaborate on the reasons for this suggested change?
Details about almost all of the proposals can be found in the packet
that I sent out. Copies are in my office, and sources are in
zurich:/zu/jar/r4-agenda/packet.tex. Or check the archives for the
mailing list to find the original message.
∂18-Jul-88 0712 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Extended local defines.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 07:12:27 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jul 88 10:10:45 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA04657; Mon, 18 Jul 88 10:07:14 EDT
Posted-Date: Mon, 18 Jul 88 10:07:40 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA18434; Mon, 18 Jul 88 10:07:40 EDT
Date: Mon, 18 Jul 88 10:07:40 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807181407.AA18434@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Extended local defines.
This is about the issue of relaxing the local DEFINE's restrictions
and flushing LETREC. Using proof by algorithm, I show that the
proposed relaxation is computable. Enclosed is an R3RS program that
translates a simple Scheme program with extended local defines into
R3R Scheme.
Before this issue should be brought up in a Scheme meeting, the
subject of efficiency must be addressed. I strongly suspect a fast
implementation is easy in compilers that do alpha conversion. In
addition, since the number of local defines is usually less then 30,
graphs could be represented by an adjacency matrix, instead of a
vector of adjacency lists. Set operations could then be fast bit
operations.
John
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# eld.scm
# make.scm
# sc.scm
# sets.scm
# ts.scm
# This archive created: Mon Jul 18 10:06:17 1988
export PATH; PATH=/bin:$PATH
if test -f 'eld.scm'
then
echo shar: will not over-write existing file "'eld.scm'"
else
cat << \SHAR_EOF > 'eld.scm'
;;; Converts extended local define Scheme to
;;; R3R Scheme with LETREC's, LET's, and BEGIN's.
;;; John D. Ramsdell -- The MITRE Corporation -- July 1988
;;; ELD Scheme
;;; form ::= def | exp
;;; body ::= def* exp+
;;; def ::= (DEFINE id body)
;;; | (DEFINE (id+) body)
;;; exp ::= id
;;; | const
;;; | (QUOTE list)
;;; | (LAMBDA (id*) body)
;;; | (IF exp exp exp)
;;; | (SET! id exp)
;;; | (exp+)
;;; Converts ELD Scheme to R3R Scheme by analyzing the interdependency
;;; of local defines. Finds the strong components and a topological
;;; sort of a graph giving the interdependency. This information is
;;; used to construct R3R Scheme replacing the extended local defines
;;; with LETREC's, LET's, and BEGIN's.
;;; To use:
;;; (eld ELD-Scheme-form) => R3R-Scheme-form
;;; Keywords.
(define define-kw 'define)
(define quote-kw 'quote)
(define lambda-kw 'lambda)
(define if-kw 'if)
(define set-kw 'set!)
(define id? symbol?)
;;; Equality predicate for set elements.
(define same? eqv?)
;;; Entry procedure. All the excitement is in eld-body.
;;; No checks are made for syntactic correctness of ELD Scheme forms.
;;; The analysis should be done after alpha conversion.
(define (eld form) ; => form
(cond ((not (pair? form)) form)
((eq? (car form) define-kw)
(eld-def (lambda (form free)
(let ((name (cadr form)))
(if (element? name free)
(list*3 define-kw name
(make-binder
'letrec
(list form)
(list name)))
form)))
form))
((eld-exp (lambda (form free) form) form))))
;;; (define (name id*) body) =>
;;; (define name
;;; (lambda (id*)
;;; body))
(define (simplify-def def)
(let ((pattern (cadr def)))
(if (not (pair? pattern))
def
(let ((name (car pattern))
(args (cdr pattern))
(body (cddr def)))
(simplify-def ;; <- ignore this hack.
(list define-kw
name
(list*3 lambda-kw args body)))))))
;;; All eld-* procedures below return (c form free) except
;;; eld-body and eld-seq which return (c form-seq free).
;;; free is the set of free identifiers in the form.
(define (eld-def c def)
(let* ((def (simplify-def def))
(name (cadr def))
(body (cddr def)))
(eld-body (lambda (form-seq free)
(c (list*3 define-kw name form-seq)
free)) ; Note: name may be in free.
body)))
(define (eld-exp c exp)
(cond ((pair? exp) (eld-exp-is-pair c exp))
((id? exp) (c exp (singleton exp)))
(else (c exp (empty-set)))))
(define (eld-exp-is-pair c exp)
(let ((kw (car exp)))
(cond ((eq? kw quote-kw) (c exp (empty-set)))
((eq? kw lambda-kw) (eld-exp-lambda c exp))
((eq? kw if-kw) (eld-exp-if c exp))
((eq? kw set-kw) (eld-exp-set c exp))
(else (eld-exp-apply c exp)))))
(define (eld-exp-lambda c exp)
(let ((args (cadr exp))
(body (cddr exp)))
(eld-body
(lambda (form-seq free)
(c (list*3 lambda-kw args form-seq)
(set-difference free args)))
body)))
;;; See--there is no check for three expressions.
(define (eld-exp-if c exp)
(eld-exp-apply
(lambda (form free)
(c (cons (car exp) form) free))
(cdr exp)))
(define eld-exp-set eld-exp-if)
(define (eld-exp-apply c exp)
(if (null? exp)
(c '() (empty-set))
(eld-exp
(lambda (exp-first free-first)
(eld-exp-apply
(lambda (exp-rest free-rest)
(c (cons exp-first exp-rest)
(union free-first free-rest)))
(cdr exp)))
(car exp))))
(define eld-seq eld-exp-apply) ; => (c form-seq free)
(define (eld-body c exp) ; => (c form-seq free)
(let loop ((defs '()) (exps exp))
(let ((def (car exps))) ; Separate def* from exp+
(if (or (not (pair? def))
(not (eq? (car def) define-kw)))
(if (null? defs)
(eld-seq c exps) ; Speed hack.
(eld-def&seq c defs exps))
(loop (cons def defs) (cdr exps))))))
(define (eld-def&seq c defs seq)
(let* ((defs (list->vector defs))
(n (vector-length defs))
(f (make-vector n))) ; Vector of free sets.
(do ((v 0 (1+ v)))
((>= v n))
(eld-def
(lambda (form free)
(vector-set! defs v form) ; Update defs.
(vector-set! f v free))
(vector-ref defs v)))
(eld-seq ; Process exp+
(lambda (form free)
(eld-def-make-graph c defs f n form free))
seq)))
(define (eld-def-make-graph c defs f n seq free)
(let* ((g (make-vector n (empty-set)))
(env (do ((v 0 (1+ v))
(env '() (cons
(cons (cadr (vector-ref defs v)) v)
env)))
((>= v n) env)))
(names (map car env)) ; Assumes no duplicate names.
(free (set-difference ; Free to be return.
(do ((v 0 (1+ v))
(free free
(union free (vector-ref f v))))
((>= v n) free))
names)))
(do ((v 0 (1+ v))) ; Construct graph
((>= v n)) ; g has an edge from v to w (v->w),
(do ((l (vector-ref f v) (cdr l)))
((null? l)) ; iff the body defining w uses v.
(let ((a (assv (car l) env)))
(if (pair? a)
(vector-set! g v (adjoin (cdr a) (vector-ref g v)))))))
(eld-analyze-graph c defs g seq free)))
(define (eld-analyze-graph c defs g seq free)
(let loop ((ts (analyze-dependency g)) (form seq))
(if (null? ts) ; For each compressed component,
(c form free) ; construct a binder, a LET form
(let ((cp (car ts)) ; or a LETREC form.
(ts (cdr ts)))
(loop ts (construct-binder
(if (car cp)
'letrec
'let)
(cdr cp) g defs form))))))
(define (construct-binder binder cp g defs form)
(let loop ((cp cp) (binder-defs '()))
(if (null? cp)
(make-binder binder binder-defs form)
(let ((v (car cp))
(cp (cdr cp)))
(loop cp (cons (vector-ref defs v) binder-defs))))))
(define (make-binder binder defs form)
`((,binder ,(map (lambda (def)
(let ((var (cadr def))
(val (cddr def)))
`(,var ,(seq->exp val))))
defs)
,@form)))
(define (seq->exp seq)
(if (null? (cdr seq))
(car seq)
`(begin ,@seq)))
;;; list* is not part of R3RS.
(define (list*3 a b c)
(cons a (cons b c)))
SHAR_EOF
fi # end of overwriting check
if test -f 'make.scm'
then
echo shar: will not over-write existing file "'make.scm'"
else
cat << \SHAR_EOF > 'make.scm'
(define (make)
(load "eld.scm")
(load "sets.scm")
(load "sc.scm")
(load "ts.scm"))
(define eld-testers
'((define (a b) b)
(define (a b)
(define (c w) (a w))
(define (d x) (c w))
(c w))
(define (a b)
(define (c w) (d w))
(define (d x) (c w))
(c w))
(define (a b)
(define c 3)
(define d 2)
(+ b c d))))
(define (eld-test)
(for-each
(lambda (form)
(pp (eld form))
(newline))
eld-testers))
SHAR_EOF
fi # end of overwriting check
if test -f 'sc.scm'
then
echo shar: will not over-write existing file "'sc.scm'"
else
cat << \SHAR_EOF > 'sc.scm'
;;; Algorithm to find strongly connected components of a graph.
;;; A fairly direct translation of the program given in
;;; "The Design and Analysis of Computer Algorithms", Aho, Hopcroft,
;;; and Ullman, Adison-Wesley, 1974.
;;; g is an vector containing adjacency lists.
;;; Returns a vector in which all nodes of a strong component
;;; are given in the adjacency list of one of the nodes.
(define (sc g)
(let* ((n (vector-length g))
(dfn (make-vector n))
(old (make-vector n '#f))
(lowlink (make-vector n))
(sc (make-vector n (empty-set)))
(count 0)
(stack '()))
(letrec
((search
(lambda (v)
(vector-set! old v '#t)
(vector-set! dfn v count)
(vector-set! lowlink v count)
(set! count (+ count 1))
(set! stack (cons v stack))
(do ((l (vector-ref g v) (cdr l)))
((null? l))
(let ((w (car l)))
(if (not (vector-ref old w))
(begin
(search w)
(vector-set! lowlink v
(min (vector-ref lowlink v)
(vector-ref lowlink w))))
(if (and (< (vector-ref dfn w) (vector-ref dfn v))
(memv w stack))
(vector-set! lowlink v
(min (vector-ref lowlink v)
(vector-ref dfn w)))))))
(if (= (vector-ref lowlink v)
(vector-ref dfn v))
(let loop ()
(let ((x (car stack)))
(vector-set! sc v
(adjoin x (vector-ref sc v)))
(set! stack (cdr stack))
(if (not (= x v)) (loop))))))))
(do ((v 0 (1+ v)))
((>= v n) sc)
(if (not (vector-ref old v))
(search v))))))
SHAR_EOF
fi # end of overwriting check
if test -f 'sets.scm'
then
echo shar: will not over-write existing file "'sets.scm'"
else
cat << \SHAR_EOF > 'sets.scm'
;;; Sets much like those used by Guy Lewis Steele Jr.
;;; in his Rabbit compiler.
(define (element? e s)
(and (not (null? s))
(or (same? e (car s))
(element? e (cdr s)))))
(define (adjoin e s)
(if (element? e s)
s
(cons e s)))
(define (union s0 s1)
(do ((s s1 (cdr s))
(u s0 (adjoin (car s) u)))
((null? s) u)))
(define (intersect s0 s1)
(cond ((null? s0) '())
((element? (car s0) s1)
(cons (car s0) (intersect (cdr s0) s1)))
(else (intersect (cdr s0) s1))))
(define (remove e s)
(cond ((null? s) s)
((same? e (car s)) (cdr s))
(else
(let ((s0 (remove e (cdr s))))
(if (eq? s0 (cdr s))
s
(cons (car s) s0))))))
(define (set-difference s0 s1)
(do ((s s0 (cdr s))
(d '() (if (element? (car s) s1)
d
(cons (car s) d))))
((null? s) d)))
(define (empty-set)
'())
(define empty? null?)
(define (singleton e)
(list e))
(define (singleton? s)
(and (not (null? s))
(null? (cdr s))))
SHAR_EOF
fi # end of overwriting check
if test -f 'ts.scm'
then
echo shar: will not over-write existing file "'ts.scm'"
else
cat << \SHAR_EOF > 'ts.scm'
;;; Topological sort
;;; Takes a graph represented as a vector of adjacency lists.
;;; Returns a topological sort. The sort is a list of components.
;;; Each component is marked with a boolean telling if the component
;;; is cyclic. Non-cyclic components have been merged when no
;;; order is implied.
(define (analyze-dependency g)
(ts g (sc g)))
;;; Constructs the condensed graph given the strong components.
;;; The condensed graph is the acyclic graph gotten by condensing
;;; each strong component into a single node.
(define (ts g sc)
(let* ((n (vector-length g))
(out (make-vector n (empty-set))) ; The condensed graph.
(in (make-vector n (empty-set)))) ; Condensed graph's dual.
(do ((v 0 (1+ v)))
((>= v n)) ; Construct condensed graph.
(do ((l (vector-ref sc v) (cdr l)))
((null? l))
(let ((w (car l)))
(vector-set! out v
(union (vector-ref out v)
(vector-ref g w)))))
(vector-set! out v
(set-difference (vector-ref out v)
(vector-ref sc v))))
(do ((v 0 (1+ v)))
((>= v n)) ; Construct dual.
(do ((l (vector-ref out v) (cdr l)))
((null? l))
(let ((w (car l)))
(vector-set! in w
(union (vector-ref in w)
(singleton v))))))
(ts-bfs g sc out in n)))
;;; A breadth first search topological sort.
(define (ts-bfs g sc out in n)
(let ((search ; List of strong components.
(do ((v 0 (1+ v))
(s '() (if (empty? (vector-ref sc v))
s
(cons v s))))
((>= v n) s))))
(letrec
((main-loop ; Finds nodes to process on this pass.
(lambda (search next-search is-cyclic new-ts ts)
(if (null? search)
(restart-bfs next-search is-cyclic new-ts ts)
(let ((v (car search))
(search (cdr search)))
(if (and (empty? (vector-ref out v))
(eq? is-cyclic (cyclic? (vector-ref sc v) g)))
(main-loop search next-search
is-cyclic (cons v new-ts) ts)
(main-loop search (cons v next-search)
is-cyclic new-ts ts))))))
(restart-bfs ; Processes nodes with zero out degree.
(lambda (search is-cyclic new-ts ts)
(let ((ts (if is-cyclic ; Compute new ts for this pass.
(let loop ((ts ts) (new-ts new-ts))
(if (null? new-ts)
ts
(let ((v (car new-ts))
(new-ts (cdr new-ts)))
(loop (cons
(cons is-cyclic
(vector-ref sc v))
ts)
new-ts))))
(if (null? new-ts)
ts
(cons (cons is-cyclic new-ts) ts)))))
(do ((new-ts new-ts (cdr new-ts))) ; Update condensed graph.
((null? new-ts) (start-bfs search (not is-cyclic) ts))
(let ((v (car new-ts))) ; ↑ Switch search mode.
(vector-set! sc v (empty-set))
(do ((l (vector-ref in v) (cdr l)))
((null? l))
(let ((w (car l)))
(vector-set! out w
(remove v (vector-ref out w))))))))))
(start-bfs
(lambda (search is-cyclic ts)
(if (null? search)
ts
(main-loop search '() is-cyclic '() ts)))))
(start-bfs search #f '()))))
(define (cyclic? cp g) ; A component is cyclic iff
(or (not (singleton? cp)) ; it does not have one element,
(let ((e (car cp))) ; or that element does not have
(element? e (vector-ref g e))))) ; a self-loop.
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
∂18-Jul-88 1111 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Extended local defines.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 11:11:33 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jul 88 13:23:05 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA11729; Mon, 18 Jul 88 13:21:22 EDT
Posted-Date: Mon, 18 Jul 88 13:21:48 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA18693; Mon, 18 Jul 88 13:21:48 EDT
Date: Mon, 18 Jul 88 13:21:48 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807181721.AA18693@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell@linus's message of Mon, 18 Jul 88 10:07:40 EDT <8807181407.AA18434@huxley.sun.uucp>
Subject: Extended local defines.
I sent the wrong version of eld.scm. This patch makes a def one of
(DEFINE id exp) or (DEFINE (id+) body) as I originally intended.
John
*** eld__00.scm Mon Jul 18 11:54:47 1988
--- eld.scm Mon Jul 18 13:11:59 1988
***************
*** 6,12 ****
;;; ELD Scheme
;;; form ::= def | exp
;;; body ::= def* exp+
! ;;; def ::= (DEFINE id body)
;;; | (DEFINE (id+) body)
;;; exp ::= id
;;; | const
--- 6,12 ----
;;; ELD Scheme
;;; form ::= def | exp
;;; body ::= def* exp+
! ;;; def ::= (DEFINE id exp)
;;; | (DEFINE (id+) body)
;;; exp ::= id
;;; | const
***************
*** 76,86 ****
(define (eld-def c def)
(let* ((def (simplify-def def))
(name (cadr def))
! (body (cddr def)))
! (eld-body (lambda (form-seq free)
! (c (list*3 define-kw name form-seq)
free)) ; Note: name may be in free.
! body)))
(define (eld-exp c exp)
(cond ((pair? exp) (eld-exp-is-pair c exp))
--- 76,86 ----
(define (eld-def c def)
(let* ((def (simplify-def def))
(name (cadr def))
! (exp (caddr def)))
! (eld-exp (lambda (form free)
! (c (list define-kw name form)
free)) ; Note: name may be in free.
! exp)))
(define (eld-exp c exp)
(cond ((pair? exp) (eld-exp-is-pair c exp))
***************
*** 198,206 ****
(define (make-binder binder defs form)
`((,binder ,(map (lambda (def)
! (let ((var (cadr def))
! (val (cddr def)))
! `(,var ,(seq->exp val))))
defs)
,@form)))
--- 198,204 ----
(define (make-binder binder defs form)
`((,binder ,(map (lambda (def)
! (list (cadr def) (caddr def)))
defs)
,@form)))
∂18-Jul-88 1231 @MC.LCS.MIT.EDU:james@ZERMATT.LCS.MIT.EDU Re: Scheme shellscripts
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 12:31:06 PDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 18 Jul 88 15:24:57 EDT
Received: from GREEN-GRASS.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 174026; Sat 16-Jul-88 14:45:21 EDT
Date: Sat, 16 Jul 88 14:44 EDT
From: James William O'Toole Jr. <james@ZERMATT.LCS.MIT.EDU>
Subject: Re: Scheme shellscripts
To: titan!dorai@rice.edu
cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: <1666@kalliope.rice.edu>
Message-ID: <880716144458.6.JAMES@GREEN-GRASS.LCS.MIT.EDU>
Date: 16 Jul 88 08:01:32 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
A shellscript written in Scheme is like any other Scheme file, except that its
first line has to be:
runschemescript "$*" '
and its last line:
'
The quotes are used to delimit the Scheme code which forms the body of the
script. The script consists of a call of the Un*x command `runschemescript'
with two arguments, the first being the list of arguments to the Scheme
script, and the second the text of the Scheme code in the script. Thus, a
Scheme shellscript is a *true* schellscript, i.e., it is callable at the Un*x
command-line, though the main part of it is a piece of text which is Scheme.
The command `runschemescript' used above is a shellscript written in the usual
shell language. It is the following relatively simple piece of cshell:
...
If anyone can suggest further improvement I'll be glad to hear of it.
Your method, when executed, requires starting one /bin/csh to interpret
the shellscript, another /bin/csh to interpret the ``runschemescript''
shellscript, copying the scheme code into a temporary file, and invoking
the scheme implementation on that file.
I would suggest that you instead place your scheme code in a file whose
first line is ``#!/bin/scheme arg''. If your file is called foo, and
its first line is as given above, then when you execute foo, your Unix
will execute the command ``/bin/scheme arg foo''. You may omit arg, or
choose arg to be something which speeds up /bin/scheme, or tells it to
load the file whose name follows, or whatever. You will have to
convince your scheme to ignore the first line of foo, of course. This
method avoids starting up extra shells and copying files.
--Jim
∂18-Jul-88 1757 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl Re: Replace LETREC with "relaxed" internal DEFINES.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 17:56:54 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 18 Jul 88 20:33:53 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa09388; 18 Jul 88 19:30 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa07670; 18 Jul 88 19:12 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA17770; Mon, 18 Jul 88 15:13:25 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA13178; Mon, 18 Jul 88 15:15:35 PDT
Message-Id: <8807182215.AA13178@tekchips.CRL.TEK.COM>
To: ramsdell%linus@MITRE-BEDFORD.ARPA
Cc: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl
Subject: Re: Replace LETREC with "relaxed" internal DEFINES.
In-Reply-To: Your message of Fri, 15 Jul 88 07:47:43 EDT.
<8807151147.AA15914@huxley.sun.uucp>
Date: 18 Jul 88 15:15:32 PDT (Mon)
From: willc@tekchips.crl
I have several comments on the proposal to "RELAX THE LETREC RESTRICTION".
1. The proposal as submitted and entered into the agenda has no bearing
on LETREC versus DEFINE. Presumably anything done to relax the LETREC
restriction would relax the DEFINE restriction in exactly the same way,
since internal DEFINE is defined in terms of LETREC.
2. The compiler cannot simply be expected to "find an order that works,
if any does", since that is not computable. (Definitely not computable;
in an earlier message I wasn't sure.)
3. It is therefore not enough to say that the compiler must find the
"best" order, since the obvious meaning of "best" is not computable and
it isn't clear what might be meant by the best computable order.
4. To judge by a computer program submitted by John Ramsdell, the "best"
computable order is to be defined as follows: if an order that works can be
found by examining the static dependency graph of the LETREC variables and
the expressions giving their initial values (and by examining nothing else),
then the best order is any such order; otherwise the best order is arbitrary.
This does indeed relax the LETREC restriction found in R3RS.
5. Apparently this proposal would require readers to construct and to sort
static dependency graphs topologically in order to understand LETREC and
internal definitions, when the writer of the code can easily make the
dependencies explicit by nesting the LETREC or internal definitions within
a LET*. If the proposal ever affects the meaning of a program, therefore,
then either the writer of the program was deliberately being obscure or
else the writer has made a mistake.
6. (Reductio ad absurdum.) If this proposal is adopted, then it seems to
me that compilers should be required to choose an order of evaluation of
arguments that makes code like the following work:
(let ()
(define x)
(define y)
(define z)
((begin (set! z 3) +) (begin (set! y 2) x)
y
(begin (set! x 1) z)))
The computation that must be performed by the compiler or human reader
for this sort of code to be guaranteed to work is exactly the same as
the computation required by the proposed relaxation of the LETREC
restriction.
7. (Disclaimer.) I think it is wonderful that compilers compute
dependency graphs and topological sorts and so forth in order to
generate better code, but I think it is terrible when humans must
do the same.
Peace, Will
∂19-Jul-88 0018 @MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Jul 88 00:18:33 PDT
Received: from ATHENA.CS.YALE.EDU (TCP 20011000033) by MC.LCS.MIT.EDU 18 Jul 88 22:13:24 EDT
Received: by ATHENA.CS.YALE.EDU; Mon, 18 Jul 88 21:49:42 EDT
From: Paul Hudak <hudak-paul@YALE.ARPA>
Full-Name: Paul Hudak
Message-Id: <8807190149.AA08696@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2)
via WIMP-MAIL (Version 1.3/1.5) ; Mon Jul 18 21:54:35
Date: Mon, 18 Jul 88 21:54:31 EDT
To: RRRS-AUTHORS@mc.lcs.mit.edu, willc@tekchips.crl.arpa
I share Will's reservations about relaxing the restrictions on LETREC.
The only way I can see that makes the relaxation meaningful is to
change Scheme to a non-strict language, in which case, of course, ALL
restrictions can be removed. But I doubt if people will like that
idea...
I seem to recall someone mentioning that dependency analysis and
re-ordering of equations is used in functional programming languages.
Let me clarify this: it is used primarily to improve efficiency, does
not change the dynamic semantics of the language, but DOES change the
static semantics. In particular, type-correctness is impacted, by
allowing a broader class of well-typed programs under the
Hindley-Milner type system. This is viewed as a feature, but is
subject to the same criticism that Will mentions -- if a program is
rejected as ill-typed the user may have trouble figuring out how to
fix it. However this is not viewed as a serious problem because:
1) such kinds of type errors are subtle even without the re-ordering!
2) the re-ordering actually LESSONS the likelihood of such an error.
Neither of these arguments can be made in the case of LETREC.
-Paul
-------
∂20-Jul-88 1120 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu L&FP Transportation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Jul 88 11:20:51 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 20 Jul 88 14:14:21 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA17258; Wed, 20 Jul 88 09:50:39 MDT
Received: by cons.utah.edu (5.54/utah-2.0-leaf)
id AA03528; Wed, 20 Jul 88 09:50:19 MDT
Date: Wed, 20 Jul 88 09:50:19 MDT
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8807201550.AA03528@cons.utah.edu>
To: common-lisp@sail.stanford.edu, scheme@mc.lcs.mit.edu, fp@cs.yale.edu
Cc: chaillou@inria.inria.fr, cork@rice.edu, kessler%cons@cs.utah.edu
Subject: L&FP Transportation
For those of you arriving at the Salt Lake International Airport and
wanting transportation to Snowbird, here is the information.
Canyon Transportation has van service between the airport and
Snowbird. The charge is $10 per person, unless you are the only
person in the van, in which case the charge will be $20. They are
planning to be at the airport between 10 am and 10 pm on Saturday the
23rd and the same hours on Sunday the 24th. Look for ground
transportation after you claim your baggage and you should find them.
They may be stationed inside the airport near the baggage claim, or
outside at the curb.
If you need to make special arrangements with them, particularily,
outside of the 10am to 10pm hours, you may call them at the following
number:
(800)255-1841
You can also take a taxi, but that will cost around $40.
Bob.
∂20-Jul-88 2359 @MC.LCS.MIT.EDU,@RELAY.CS.NET:shin@carcvax.uconn
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Jul 88 23:59:31 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Jul 88 01:04:35 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa16189; 20 Jul 88 23:31 EDT
Received: from uconn by RELAY.CS.NET id ab26726; 20 Jul 88 23:16 EDT
Received: by CARCVAX.ARPA (5.51/4.7)
id AA11311; Wed, 20 Jul 88 09:00:51 EDT
Date: Wed, 20 Jul 88 09:00:51 EDT
From: Dong-Guk Shin <shin%carcvax.uconn@RELAY.CS.NET>
To: scheme <@RELAY.CS.NET:scheme@mc.lcs.mit.edu>
Could you please foward the message given below to the right receipient
or provide me his/her correct e-address? The message should be addressed
to MIT AI LAB who is in charge of the lisp language Scheme.
Possible names are: H. Abelson, R. Dybvig, C Haynes, G. Rozas, N. Adams,
D. Friedman, E. Kohlbecker, G. Sussman, D. Bartley, R. Halstead,
D. Oxley, M. Wand, G. Brooks, C. Hanson, and K. Pitman.
I have been trying to send the message to the following address (given in
one of the manual) and couldn't get it through.
INFO-CSCHEME%OZ@MC.LCS.MIT.EDU
Appreciate in advance.
***********************************************************************
Recently we have installed the Scheme on the SUNs. We have not digested
yet how to make complete use of it. Do you have any utility files that allow
us to manipulate property lists? We do not see them in "Revised3 Report
on the Algorithmic Language Scheme". Also we wish to know if there is
any debugging functions.
Shin
∂21-Jul-88 0442 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 04:42:12 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Jul 88 07:36:56 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA05899@BLOOM-BEACON.MIT.EDU>; Thu, 21 Jul 88 07:32:29 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Jul 88 21:00:41 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Subject: Re: Scheme shellscripts
Message-Id: <1700@kalliope.rice.edu>
References: <1666@kalliope.rice.edu>, <880716144458.6.JAMES@GREEN-GRASS.LCS.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
James William O'Toole Jr. <james@ZERMATT.LCS.MIT.EDU> writes:
> Date: 16 Jul 88 08:01:32 GMT
> From: titan!dorai@rice.edu (Dorai Sitaram)
>
> A shellscript written in Scheme is like any other Scheme file, except that its
> first line has to be:
> runschemescript "$*" '
> and its last line:
> '
>
> The quotes are used to delimit the Scheme code which forms the body of the
> script. The script consists of a call of the Un*x command `runschemescript'
> with two arguments, the first being the list of arguments to the Scheme
> script, and the second the text of the Scheme code in the script. Thus, a
> Scheme shellscript is a *true* schellscript, i.e., it is callable at the Un*x
> command-line, though the main part of it is a piece of text which is Scheme.
>
> The command `runschemescript' used above is a shellscript written in the usual
> shell language. It is the following relatively simple piece of cshell:
>
> ...
>
> If anyone can suggest further improvement I'll be glad to hear of it.
>
>Your method, when executed, requires starting one /bin/csh to interpret
>the shellscript, another /bin/csh to interpret the ``runschemescript''
>shellscript, copying the scheme code into a temporary file, and invoking
>the scheme implementation on that file.
>
>I would suggest that you instead place your scheme code in a file whose
>first line is ``#!/bin/scheme arg''. If your file is called foo, and
>its first line is as given above, then when you execute foo, your Unix
>will execute the command ``/bin/scheme arg foo''. You may omit arg, or
>choose arg to be something which speeds up /bin/scheme, or tells it to
>load the file whose name follows, or whatever. You will have to
>convince your scheme to ignore the first line of foo, of course. This
>method avoids starting up extra shells and copying files.
>
> --Jim
A Refresher on #!
-----------------
If `#! A A1 ...' is the first line of a shell script file whose name is B,
calling B with args B1 ... has the same effect as calling A with args
A1 ... B B1 ...
In the above, A has to be a full pathname of a *standard* Un*x command (like
cat, scheme, etc), i.e., it cannot be a user-fashioned command or shell script
(I found this out thru experimentation. Why is this?).
!# no rehserfeR A
-----------------
Jim [and J A Biep Durieux (private communication)] suggest that
#! /usr/local/scheme be the first line of a Scheme script: this has the
unfortunate effect that all arguments to a Scheme script will be loaded as
Scheme files [even though they are in general, just like any shell script
arguments, *not* Scheme files]. The script file itself is loaded into Scheme,
which is ok, provided that its first (non-Scheme) line can somehow be removed.
However, Jim and Biep are right in stating that #! can lead to a concise
and efficient implementation of Scheme scripts. Let the first line of a
Scheme script be the line
#! /bin/sh runschemescript
runschemescript is a Bourne script which looks like:
********************************************
foo=$1
shift
echo > .tmp '(set! $* (quote ('$*')))'
echo -n >> .tmp ';'
cat $foo >> .tmp
echo >> .tmp '(exit)'
scheme .tmp #this line could be 'exec scheme .tmp' but I don't know if
#that saves anything
********************************************
A Scheme script 'ss' looks like:
********************************************
#! /bin/sh runschemescript
<a body of Scheme code which
refers to the list of arguments
of `ss' by the variable $*>
********************************************
This Scheme code doesn't have the restriction of not being able to use quotes
in it. It also looks less ugly with the user not having to mention $* and use
Bourne quotes in his Scheme scripts.
ss, when called with arguments a1 ..., gets converted (by the #!) to the call
/bin/sh runschemescript ss a1 ...
which is the same as (with one subshell invocation)
runschemescript ss a1 ...
runschemescript then creates a .tmp file which sets a Scheme global variable
$* to a list (a1 ...) of ss's arguments; followed by the contents of the file
ss; followed by an (exit). [A judicious ';' is inserted at the right spot to
comment out the only non-Scheme portion of the file ss: the first line (with
#! ...).] ss can therefore be used as a regular shell script which is written
in Scheme rather than in Bourne.
I would like the first line of Scheme script to be just
#! runschemescript
instead of
#! /bin/sh runschemescript
but as said earlier, only standard Un*x commands seem to be accepted by #!.
Improvements are welcome.
--dorai
∂21-Jul-88 0613 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Replace LETREC with "relaxed" internal definitions.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 06:13:13 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 21 Jul 88 09:11:13 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA17452; Thu, 21 Jul 88 09:10:11 EDT
Posted-Date: Thu, 21 Jul 88 09:10:37 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA20563; Thu, 21 Jul 88 09:10:37 EDT
Date: Thu, 21 Jul 88 09:10:37 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807211310.AA20563@huxley.sun.uucp>
To: willc@tekchips.crl
Cc: RRRS-AUTHORS@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 18 Jul 88 15:15:32 PDT (Mon) <8807182215.AA13178@tekchips.CRL.TEK.COM>
Subject: Replace LETREC with "relaxed" internal definitions.
I just received a copy of the Proposals for a R4SR. To my surprise, I
found my wish that a dependency analysis be done on local definitions
was taken as proposal to be discussed at Sunday's meeting. I intended
the subject come up only in informal discussions. In order to
realistically institute such a big change, I would have to show an
efficient implementation in both an interpreter and a compiler, and
convince a number of people it is a good idea, before the subject is
discussed at a meeting. That time is curtainly not now.
I submitted the recent notes on this subject in response to Eric
Tiedemann's message on the specification of the order in which
elements of a combination are evaluated. In his note, he talked about
finding an "applicative order fixpoint" of LETREC, to solve Robert
Hieb's complaint that internal definitions look like top-level
definitions, but do not act like them. Someone then complained that
finding an applicative order fixpoint is uncomputable. However, a
dependency analysis is all that is needed, and I gave an algorithm
that does the analysis.
Please withdraw the proposal to Replace LETREC with "relaxed" internal
definitions. My proposal to eliminate NIL and T from the report is
quite serious.
John
∂21-Jul-88 1526 @MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU rec definition
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 15:26:12 PDT
Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 21 Jul 88 18:19:53 EDT
Date: Thu, 21 Jul 88 14:33:54 PDT
From: Max Hailperin <HAILPERIN@SUMEX-AIM.Stanford.EDU>
Subject: rec definition
To: scheme@mc.lcs.mit.edu
Message-ID: <12416161820.15.HAILPERIN@SUMEX-AIM.Stanford.EDU>
I know that rec was eliminated in R↑3RS, but I'm curious about it's definition
in schemes where it exists.
TI PC Scheme macroexpands (rec var val) to (letrec ((var val)) var), in
compliance with R↑2RS and it's own manual *provided val isn't a lambda
expression*. On the other hand, it macroexpands (rec var (lambda argl body))
into (letrec ((var (lambda argl body))) (lambda argl (var . argl))).
The question is: why? It can't be a bug, as it's a special case where there
is no need for one. But I don't understand, on the other hand, what it is
intended to achieve.
If someone from TI is on the list, I'd be grateful for the real answer.
However, I'd settle for some informed speculation from others familiar
with implementations and uses of rec. Do any other schemes implement
rec this way? Is there any programming paradigm it makes work where the
simple definition doesn't? (I know of one example of the reverse.) Is
it easier to compile the fancier version into efficient code in some cases
for some reason?
Thanks.
-------
∂21-Jul-88 1705 @MC.LCS.MIT.EDU:wagle@iuvax.cs.indiana.edu RE: lisp conf scheme agenda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 17:04:44 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 21 Jul 88 19:37:28 EDT
Received: by iuvax.cs.indiana.edu; id AA06607; Thu, 21 Jul 88 18:02:20 EST
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Thu, 21 Jul 88 18:02:20 EST
From: Perry Wagle <wagle@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: RE: lisp conf scheme agenda
I cannot make it to the the RRRS meeting on Sunday, 24 July. I am
teaching this summer and cannot take the time off.
I am a graduate student at IU, I have written my own Scheme System with
native code compiler on the VAX.
Here are my comments on Will's proposed agenda found in RRRS-AUTHORS.
Some of my comments are somewhat mundane. Some of them begin to be
profound.
I do not feel that now is the time for a standardized Scheme. There are
too many open issues: continuations, concurrency, macros, environments, etc.
I apologize ahead of time for any typos or opaque writing. I have made a
good deal of effort to remove all such, but I am now feeling rushed for time
to get this out before everybody starts flying to Snowbird Utah.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> RESERVED WORDS AND PORTABLE CODE. Require that implementations
> provide some way for programmers to work in a syntactic environment
> containing no reserved words other than those found in the report,
> without requiring that this be the default syntactic environment.
I'm not sure this leads to a desirable situation. If the R*RS is so yucky
that other environments are needed to actually do real programming, why even
have the R*RS environment? If nobody's using the R*RS environment for
serious work, then it's just a cute toy.
> DISJOINTNESS OF TYPES. Require that the following sets of objects
> be disjoint: booleans, pairs, symbols, numbers, characters, strings,
> vectors, procedures. Issue: add the singleton set containing the
> empty list to the list. Issue: remove characters from the list.
> Issue: add promises to the list, or flush force and delay altogether
> (see **OTHER PROPOSALS**).
Lacking a reason to make life more verbose by removing all vestiges of
shorthand/overloading ("punning"), I support dividing ALL types/values into
two classes: the class of TRUE types/values, and the class of FALSE
types/values. With this, there should be at least one true value,
designated #t, and one false value, designated #f. I don't care whether
these values are disjoint from other values of the same class or not.
I don't support a distinct boolean type. If there IS a boolean type, then
there should be exactly two boolean values (values interpretable as
boolean), #t and #f, and those should be the ONLY values allowed from the
first sub-expression of an IF. Having a distinct boolean type, and then not
really using it is ugly! Enforcing it adds a run-time error condition check
to IF, which is undesirable.
> ELIMINATE NIL, T. Remove nil and t from the report.
Human engineering is wierd. When I first learned LISP in 1975, NIL
offended me because it didn't look right (like a symbol, not a list). Then
I started actually writing code, and discovered that "nil" was a LOT easier
to see than "()" or "'()". And I've used NIL ever since. When I learned
SCHEME, I (obviously) had to bow to its insistance on calling "nil" a
symbol, but I still use it when I can, simply because its still easier for
me to see!
I propose (half jokingly) that the syntax "nil" denote the empty list and
not a symbol. That is, the single special case of the #! syntax.
> EQV?. Clean up the specification of eqv?, removing the requirement
> that it be true of two empty strings or empty vectors.
My impression of Will's EQV? axioms when I scanned over them is that they
looked an awful lot like EQ? and I didn't see the point (of having something
just barely different than EQ?).
I've always thought EQV? should return TRUE when EQ? "should" (due to
hashing) be TRUE, but isn't (bignums, strings, etc, but NOT lists).
I don't think EQV? has the right to be unspecified on anything computable.
EQ? does have the right since it ONLY compares pointers (without EVER
dereferencing them!).
> DUPLICATE FORMALS ARE IN ERROR. The list of formal variables in
> lambda, let, letrec, and do (but not let*) should not contain
> duplications. E.g. (lambda (x y x) ...) is an error. In the case
> of named let, the formals in the initial bindings list should be
> distinct, but it is ok (albeit useless) for the "name" to duplicate
> a formal. E.g. (let foo ((x 1) (foo 2)) ...) is legal.
Okay. (Pssst! What's the problem?)
> CHANGE WORDING OF LETREC RESTRICTION. From "...without referring
> to the value of any <variable>" to "...without referring to the
> value or location of any variable". Example:
>
> (letrec ((wanna-be-a-doctor 'doctor)
> (imagine-my-surprise! (begin
> (set! wanna-be-a-doctor 'nurse)
> 'zowie)))
> wanna-be-a-doctor)
Closure creation refers to the locations of its free variables. Therefore
this wording bugs me. Why not just come out and say "without STORING or
FETCHING from the location of any LHS-variable". The vague wording above
confuses me, and I know what it means!
> CLARIFY WORDING OF LETREC. Add the word "ALL" as follows:
> "...in a letrec expression, ALL the bindings are in effect while
> their initial values are being computed..."
I'd be happier with a wording of something more like: "All the
LHS-variables exist but are considered unbound while the RHS-values are
being computed. Only when all the RHS-values have been computed are the
LHS-variables considered to the bound to their corresponding RHS-values.".
> CLARIFY MEANING OF QUASIQUOTE. As in Pavel Curtis's proposal.
I missed Pavel Curtis's proposal (sorry Pavel!). However, my I already
feel that quasiquote should produce all fresh pairs. That is,
`(1 2 3) expands to (cons 1 (cons 2 (cons 3 '())))
And I will (and have) rewrite(n) quasiquote to have this behavior in scheme
systems that don't have this behavior.
> CLARIFY STATUS OF CI. Though CI is described as a suffix,
> it is generally just embedded.
No opinion.
> CLARIFY THE SPECIFICATION OF TRUNCATE.
> IMPROVE THE DISCUSSION OF EXACTNESS AND INEXACTNESS.
> CHANGE THE SYNTAX OF NUMBERS.
> CLARIFY THE STATUS OF EXPONENTS.
> EXPONENTS ILLEGAL IN FRACTIONS.
> EXACTNESS AND INEXACTNESS OF CONSTANTS.
No opinion. I haven't worried about numbers. Yet.
> **PART 2: POLICY ISSUES**
> FLUSH OPTIONAL FEATURES. Do away with the distinction between
> essential and optional features. In effect, make everything
> essential. Issue: some optional features should be dropped rather
> than made essential; which?
My Scheme system only has integer fixnum's. I feel that for my system to
be a "real-life scheme", it needs at least integer bignums. On the other
hand, I don't feel in any hurry to add inexact real bignums. Though if I
did, it would be nice if I had a standard to match up with. A library of
standard algorithms would be nice too.
> MAKE PROCEDURES MORE REGULAR. Add vector-copy, list-copy,
> list-fill!, list-set!, (make-list k); or remove procedures
> to make them more regular across the different kinds of
> sequences. Issue: what's the policy? Issue: generic
> copiers, fillers, etc. Issue: optional or essential?
It would would be nice to have a consistant set of fundamental operations.
However, though a few years back I was much in favor of generic copiers,
length measurers, etc, I am now strongly in favor of type-specific ones.
(LIST-LENGTH, STRING-LENGTH, etc). COPY is a little stranger, in that you
might desire to copy heterogenous data structures, and in that case a generic
COPY would make sense. Otherwise, a pair-specific copier still is useful.
> UNDERSPECIFICATION. What kinds of underspecification are
> desirable? What kinds are undesirable?
No unspecification is desirable. Optimizers should be completely
invisible. Scheme programs should have the same behavior on all scheme
systems. I should never have to consider "the optimizer" when I am
reasoning about my program (unless I EXPLICITLY set an optimizer level, and
in this way become implementation dependent).
*************************************************************************
* *
* Let me restate that as a general principle for emphasis *
* and clarity: My Scheme program should only become *
* implementation dependent if I explicitly say so, *
* otherwise the scheme program should be completely *
* portable across all scheme systems in syntax and behavior. *
* *
*************************************************************************
The only reasons for underspecification I've heard are to allow
concurrency and to allow stupid optimizers. Concurrency is out of the
question since then is no protection mechanism for critical sections. The
concept of condoning stupid optimizers horrifies me since I can imagine with
horror one that started inlining code, and then interleaving the evaluation
of sub-expressions "for efficiency". PERMUTE is completely undefined, you
know. No axioms, nothing.
Speaking of PERMUTE: you do realize that the lack of a definition of
PERMUTE makes this touted denotational semantics incomplete to the point of
uselessness? If non-determinism is so easy to reason about, how come the
denotational semantics can't? How am I supposed to do my proofs with a
missing fundamental and much used definition?
Query: What does:
(begin
(set! x 1)
(list (set! x (* x 3)) (set! x (+ x 4)))
x )
mean? (3, 5, 7, or 15?) What does:
(call/cc
(lambda (k)
(list (k 1) (k 2) (k 3)) ))
mean? (1, 2, or 3?)
> **PART 3: MAJOR PROPOSALS**
> MACROS. No complete proposal is ready for consideration. The
> macro and extend-syntax syntaxes have been proposed as least
> common denominator(s) to tide us over until we have a real macro
> proposal.
I strongly oppose any system that won't allow me to write naive macros.
Renaming my symbols without my express permission and not telling me is not
human engineering (macro substitution is not necessarily beta-reduction!).
It simply does not scale to tractable proofs of large macros. Other than
that extend-syntax suits me fine if it remains disjoint from the macro
expansion facility itself.
> MODULES.
> REPLACE LOAD WITH INCLUDE. The load procedure is convenient for
> interactive program development, but its dependence on an object
> with state (the external file system) makes it less satisfactory
> than include would be for describing complete programs.
> Presumably implementations would retain load as part of their
> programming environment even if it were replaced by include in
> the report. Issue: An alternative is to change the meaning of
> load in the report. Issue: Include also depends on an external
> file system; the only difference is that the dependency is removed
> at compile time rather than run time.
I oppose making *interactive* program development harder in favor of batch
processing. Both LOAD and INCLUDE have their uses. Both should be allowed.
Neither can provide the functionality of the other.
The top-level expressions in a file being LOADed should have exactly the
same semantics as typing the expressions in, one at a time, from a
read-eval-print loop. INCLUDE doesn't have to have this semantics.
In fact, I'll claim that LOAD starts up a fresh read-eval-print loop,
reading from a file instead of a keyset, and writing to oblivion instead
of a screen. It terminates upon EOF.
I conceive of INCLUDE more like a macro that returns that contents of a
file (probably wrapped with a begin).
> FIRST CLASS ENVIRONMENTS. In my opinion, no proposal for
> environments remains on the table. A proposal could be built
> around make-environment, the-environment, build-environment,
> Guzowski's with, or Pavel's recently withdrawn proposal.
> ADD EVAL. Add eval to section 6.10.4. Issue: one or two arguments?
> If two, how do you get an appropriate second argument?
> ADD SECOND ARGUMENT TO LOAD. If eval is added and takes a second
> argument, then shouldn't a second argument should be added to load
> also?
The fundamental abstraction is a read-eval-print loop (REP loop). A REP
loop reads from a stream of expressions (usually a keyset or a file (with
LOAD)) and writes a stream of values (usually a screen/window, or a datasink
(with LOAD)). A REP loop reads expressions, evaluates them for value AND
effect, outputs their values, then starts over again. This is a very
iterative, side-effecty approach, and I class it as one of the activities of
Meta-Programming, of which debugging is also a member. EVAL means nothing
without a REP loop, or something like it.
In particular, I view "define" as a command to a REP loop to add or modify
a symbol to its list of definitions (its extendable "base environment").
So called "local defines" as they are presently defined are therefore a
complete misnomer. They have a completely different meaning and use from
"top level defines". I would much prefer to refer to local defines with the
keyword "declare" and NOT "define". I don't care what "declare" means at
top level, I don't use "declare". I do use "define" as described above.
> ADD LAMBDA*. Adopt the Hieb/Dybvig proposal for procedures that
> dispatch on the number of arguments they are given, for allowing
> multiple values to be stored in variables, and for the & syntax.
> This proposal is an alternative to the next two proposals.
I used Bruce Duba's "match-lambda" to write the variable argument
procedures in my scheme system. I used the:
(define! write-char
(match-lambda
[ (char) (write-char char (default-output-port)) ]
[ (char port)
(die-if-not-port port)
(die-if-not-char char)
(syscall #!writec port char) ] ))
style to not replicate code. However, I did observe that this programming
approach uses MULAMBDA and thus eats PAIR's and causes garbage collections
(and my version 0 garbage collector is SLOW).
APPLY forces its list argument into the form of an actuals-list (which is
isomorphic to a finite (acyclic) proper list). MULAMBDA (lambda w/ #!rest)
converts actuals-lists to pair-lists. So there is already an internal
actuals-list representation, which causes all this gyration with APPLY and
MULAMBDA. Punning the actuals-list with multivalues-lists seems natural.
HAVING to convert back and forth from pair-lists is inefficient and
unnecessary.
I like the "&" proposal, but I haven't formally worked out the semantics
nor implemented it yet.
> MULTIPLE RETURN VALUES. Add optional procedures values and
> with-values such that (values x1 ...) returns values x1 ... and
> (with-values thunk proc) calls proc on the values returned by
> thunk. Issue: what do continuations that currently expect one
> return value do when given zero values or more than one value?
> The most popular answers are:
>
> a. It is an error.
> b. Ignore extra values; it is an error if there are no return
> values.
> c. Ignore extra values; the continuation gets an unspecified
> value if there are no return values.
> d. Ignore extra values; the continuation gets #f if there are
> no return values.
Unless the continuation takes variable numbers of arguments, it is an
error for the wrong number of values to be given to it. General principle
holds that adding and ignoring values is bad. Examples might convince me
otherwise. Annotation to specify which of many values is desired is easy.
> OPTIONAL ARGUMENTS. Add an optional #!optional syntax to lambda
> expressions to support optional arguments:
>
> (lambda (x #!optional y z . w) ...)
>
> If not supplied, y and z are bound to new locations holding a
> special default object. Add the procedure default-object? so that
> (default-object? y) is true if y is not supplied. It would be
> possible to pass the default object as an actual argument, thereby
> making it possible to obtain the default for y while specifying z
> explicitly.
I tried using a default-object approach for my variable argument
procedures. I dropped it in favor of the multiple formals list approach
described above, as it was clearer and shorter.
> RECORD OBJECTS. Jonathan's proposal:
No opinion.
(Later) I lied. I think RECORD OBJECTS should be a user-library module.
The need of RECORD OBJECTS to create objects of TYPE disjoint from all other
TYPEs is a very strong argument in favor of providing user defined types.
(Proposals anyone?)
> **PART 4: OTHER PROPOSALS**
> CHANGE WORDING OF SET! RESTRICTION. From "<Variable> must be
> bound in some region enclosing the set! expression or at top
> level" to "<Variable> must be bound in an enclosing lexical
> environment". Issue: need examples of code that illustrate
> the intended differences between the two wordings.
If you distinguish between "define" and "declare"... (see my discussion
elsewhere) I want to define globals while embedded in LETRECs.
Also, this doesn't seem too friendly to the interactive user (who your
already dumping on anyway, but...).
> FORMAL SEMANTICS FOR NUMERIC CONSTANTS. As proposed by Clinger,
> who doesn't think it is necessary.
With fifty different types of numbers, something formal might be nice.
> ELIMINATE DO. Remove do from the language.
Won't bother me...
> ELIMINATE NAMED LET. Remove named let from the language.
I use REC and RECUR.
> ELIMINATE =>. Remove the => notation from the language.
Never used it. (later:) Eeek. Never will either.
> ELIMINATE CASE. Remove case from the language.
HUH?!?
> ELIMINATE FORCE AND DELAY. Or make promises disjoint from other
> types.
I've decided to make suspensions (ala Friedman&Wise, 1976) disjoint from
other types in my Scheme System as I like to make streams of closures, and I
can't tell the difference between a closure and a suspension realized as a
closure. And this is a problem.
> ELIMINATE LAST-PAIR. Remove last-pair from the language.
I've used it. I can write one myself.
> ELIMINATE NUMERIC FORMATS. Eliminate (or redesign or simplify)
> the format arguments to number->string.
No opinion.
> ELIMINATE CALL-WITH-CURRENT-CONTINUATION. Remove
> call-with-current-continuation because it makes programs hard to
> understand.
I don't use CALL/CC (well I haven't for quite a while). I DO use
Continuation Passing Style, and my programs are probably hard to read. But
previously intractable programs are easy to write. I DO support functional
continuations and prompts, and have already (ab)used engines a number of
times to partially achieve this functionality (when I couldn't convert to
Continuation Passing Style).
> DEFINE WITH NO EXPRESSION. Optionally allow (define x) for top level
> definitions only. Issue: why not for internal definitions? Issue:
> If it becomes available for internal definitions, then it should also
> be available for letrec, let, let*, named let (?), and do (??).
Do NOT allow "define" with no expression. Do allow "declare" with no
expression. See my earlier discussion. No such thing as local defines.
Allow local "declare"s with no expression.
Symmetry arguments indicate that LETREC et al should allow empty
expressions. I wouldn't (and have never needed to) use them.
> ADD CALL. Add essential syntax: (call proc arg1 ...).
> ADD STATIC. Add essential syntax: (static id).
My compiler converts to this form. Almost. It also puts all constants
inside of QUOTE expressions, I'm contemplating recognizing tail recursion at
this point in the compilation process by splitting CALL into CALL and GOTO,
and I already split lexical variables from globals with GLOBAL and LEXICAL
(instead of static). I also make all variable locations explicit, but I am
probably going to retract that later on, unless I get a good algorithm for
detecting possibilities of stack-and-not-heap allocation.
So I might be against it because its not the way my compiler would want it.
Supporting code traversers this explicitly might be a bad idea anyway.
> PEEK-CHAR. Add a peek-char procedure. Issue: essential?
Would be cleaner and more robust than writing it yourself. I'd rather
worry about the I/O package in it entirety, though.
> ADD EQ-HASH, EQV-HASH.
No opinion.
> ADD DAYS-AFTER-J2000.0.
I favor a full fledged date treatment system/library.
> VALUE RETURNED BY ONE-ARMED IF, COND. Specify that (if E0 E1) returns
> #f if E0 is false, and that (cond ...) returns #f if no clauses apply.
I don't like one-armed if's (I use WHEN and UNLESS). I dislike
unspecified values. #f is fine. Just be sure to maintain tail-recursion
(Hi Bob!(:-)(:-)(:-)).
> VALUES RETURNED BY SIDE EFFECTS. Change the semantics of
> (set! x e), (set-car! x e), (write e p), et cetera, so that
> they return the value of e. Issue: why not return #!unspecified?
My Scheme System returns "e". #!unspecified is stupid. If you are
"lucky" it induces a run-time error right away. If you aren't, and didn't
throw it away, then your program is a time-bomb. Either using the value of
a side-effecting expression causes a COMPILE-TIME error, or it returns a
legitimate value -- anything else is bogus.
Anyone who doesn't use the value (ie throws it away) doesn't care what the
value is. #!unspecified doesn't even help him, really, in the event that he
slips. Anyone who wants to use a value needs something reasonable, and
#!unspecified isn't. The situation is not symmetrical.
> LEFT TO RIGHT EVALUATION OF ARGUMENTS. Change the semantics of
> procedure calls so that expressions are evaluated from left to
> right.
It would make program proofs easier. Combinatorial explosions tends to
make things intractable. See my previous arguments.
> LEFT TO RIGHT EVALUATION OF DEFINITIONS. Change the semantics
> of internal definitions so that they are evaluated from left to
> right. Issue: do the same for letrec?
Evaluation of RHS expressions should occur Left to Right. Binding of RHS
values to LHS variables should occur in no particular order, though it would
be nice if the binding occurred after ALL of the RHS expressions were
evaluated.
> CHANGE THE SPECIFICATION OF AND. Change and so it always returns
> #t or #f. Issue: the last position of an and becomes non-tail-
> recursive. Issue: If this proposal is not adopted, must and
> return the first false value it sees, or can it simply return #f?
Why brain-damage AND? Last position should be tail-recursive. Non-#t
values are okay, as are non-#f values. I don't believe in a distinct
boolean type anyway.
> RENAME CHARACTER COMPARISON PREDICATES. Change char=? etc to
> char= etc.
I use "char-eq?", "char-ne?", "char-ge?", etc. Its easier for me to see,
but its non-standard, which causes boot-strapping problems.
My feeling is that "=", "<>", "<=", etc don't need the "?" because they
already consist of special characters, and culturally are understood to
return true and false values. This argument presumably extends to relations
with alphabetic prefixes.
> RENAME SET! TO SET.
No. Why?
(Later:) LET is the non-destructive version of SET!. Seriously!
(That's the way I think about it sometimes).
Chez Scheme's Fluid Bindings are another non-destructive version
of SET!.
If I had first-class locations, I might have a third version.
> RENAME SET-CAR! TO SET-CAR, SET-CDR! TO SET-CDR. Issue:
> non-destructive versions make sense even though they're not in the
> report.
Not for destructive versions.
Keep the bang ("!") notation for all. Pronounce it as "bang" and not as
"destructively". Easier pronunciation might make you feel better.
> RENAME CHAR-READY? TO READ-CHAR-READY?. Issue: name:
> READY-TO-READ-CHAR? Issue: replace instead
> with read-char? (TYI-NO-HANG)?
READ-CHAR-NO-HANG. For some reason I'm concerned about non-atomicity.
> RELAX THE LETREC RESTRICTION. Require implementations to find
> an order that works, if any does. Issue: not computable?
Topological sorts of dependency graphs is certainly computable. I think
is even linear in time. The problem is what to do with cycles.
I'm happy with LETREC the way it is. If somebody wants to topsort, and
solve cycles, let them write a library macro called something else, and make
it publicly available, I won't mind though...
> DON'T SPECIFY WHETHER THE EMPTY LIST COUNTS AS TRUE OR FALSE.
I don't believe in booleans. So I believe the empty list is a false value.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> LOOSE ENDS not in Will's note, but in typeset copy handed to be just now:
> ADD TYPE-OF: (from Pavel)
In my implementation, there is an object of each type that doesn't exist.
This is an artifact of the linker, but rather than dismiss it as a hack, and
be rid of it, I kept them around in wait for a use for them. (The singleton
objects: (), #t, #f, etc are all of different primitive types, but are
POINTER-EQ? to the ghost-object of their types).
I was thinking that these ghost-objects would be ideal first-class types,
which implies that a first class type is of its own type:
(pair? (type-of (cons 1 2))) ==> #t
I even defined a predicate TYPE-EQ? that compares types of two objects,
which implies:
(define ghost-pair (type-of (cons 1 2)))
(define pair? (lambda (x) (type-eq? x ghost-pair)))
This seems rather implementation specific, but thought I'd throw it out
to see if anyone could abstract it to something interesting.
> CHAR renamed to CHARACTER (pavel):
I actually wouldn't mind INT, BOOL, and RAT. But then thats largely
because my screen is only 80 characters wide. I also find very long
identifiers hard to read.
I guess it comes down to: if you renamed CHAR to CHARACTER, I'd probably
rename them back.
OH! The real reason is that INTEGER, RATIONAL, and BOOLEAN are special.
That is, we don't have INTEGER+, INTEGER>=, RATIONAL*, RATIONAL<>,
BOOLEAN-AND, BOOLEAN-NOT, etc. In this sense CHAR is not special, and hence
is worthy and needful of the shorter name.
> CHANGE EXPONENT MARKER from E to ↑.
It would be confusing with exponentiation in other languages...
I like the thought, though.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> LOOSE ENDS not found in proposal anywhere:
> CASE STUPIDITY. Is case-insensitivity while reading symbols sane? Is it
> human engineering? Does it open whole new realms of error making? Is
> ASCII too powerful? Wouldn't Morse Code be simpler? Do you miss the
> grand old days of FORTRAN where even spaces weren't real?
At the same time I was chafing against the limitations of only two cases
of letters in ASCII, case-insensitity is foisted upon me. To me,
case-insensitivity is a hallmark of ANCIENT, not modern programming
languages. But be that as it may, case-insensitivity CAUSES errors.
I cannot believe that someone can think that "FOObaz", "FoObAz", "fooBAZ",
"foobaz", "FooBaz", "FOOBAZ", and "fOOBAz" are all the same identifier.
I've had to deal with programs that spelt keywords and variables a multitude
of ways, and it was just one more indication of the overall downright SHODDY
design. It was just another way to be sloppy, and the compiler allowed it.
I have two proposed solutions:
(1) Case Consistancy: the identifier must be refered to with the same case
signature across all usages. To refer to both "FOObaz" and "fooBAZ" is
a compile time error (NOT a read-time error!).
(2) (EQV? 'FOObaz 'fooBAZ) ==> #t, (EQ? 'FOObaz 'fooBAZ) ==> #f
have the compiler use EQV?, and let the macro expander use EQ?,
∂22-Jul-88 0738 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Making local definitions more like top-level definitions.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jul 88 07:38:44 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 88 10:31:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA28458; Fri, 22 Jul 88 10:30:02 EDT
Posted-Date: Fri, 22 Jul 88 10:30:31 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23270; Fri, 22 Jul 88 10:30:31 EDT
Date: Fri, 22 Jul 88 10:30:31 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807221430.AA23270@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: willc@tekchips.crl's message of 18 Jul 88 15:15:32 PDT (Mon) <8807182215.AA13178@tekchips.CRL.TEK.COM>
Subject: Making local definitions more like top-level definitions.
Old-Subject: Replace LETREC with "relaxed" internal DEFINES.
From willc:
>5. Apparently this proposal would require readers to construct and to sort
>static dependency graphs topologically in order to understand LETREC and
>internal definitions, when the writer of the code can easily make the
>dependencies explicit by nesting the LETREC or internal definitions within
>a LET*. If the proposal ever affects the meaning of a program, therefore,
>then either the writer of the program was deliberately being obscure or
>else the writer has made a mistake.
Two points: Eric Tiedemann talked about changing LETREC. I don't want
to change LETREC, but once you have local definitions that act more like
top-level definitions, LETREC is redundent, and can be expunged.
The "proposal" would require readers to construct and sort graphs only
if they choose to read programs imperatively. Hopefully, real
programmers would think of local definitions as equational assertions
with local scope. The meaning of the equations is derived from their
interdepencies, not the order of presentation. At top-level, there is
a curious interpretation of definitions which depends partly on the
order of presentation. With the semantics I have provided, top-level
definitions could be surrounded by a LAMBDA-expression so as to become
local definitions, and their meaning would not surprise a user. This
would make local definitions more like top-level definitions.
John
∂22-Jul-88 0937 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA On Modules in Scheme: Principles and Proposals
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jul 88 09:37:28 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 22 Jul 88 12:00:34 EDT
Full-Name:
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA00546; Fri, 22 Jul 88 11:35:26 EDT
Posted-Date: Fri, 22 Jul 88 11:35:54 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23334; Fri, 22 Jul 88 11:35:54 EDT
Date: Fri, 22 Jul 88 11:35:54 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8807221535.AA23334@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel's message of Tue, 14 Jun 88 10:31:25 PDT
Subject: On Modules in Scheme: Principles and Proposals
One feature I do not like about ML's module facility of 1984 is that
mutual recursion is not allowed between objects in different modules.
Without modules, programmers can freely define mutually recursive
objects. As a principle, it seems to me that the use of modules
should not change this capability. Jonathan told me his proposal
could be changed to include this capability. As a result, proposals
based on ML's modules seem to be the leading contenders for modules in
Scheme.
John
∂24-Jul-88 1517 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Non-upward-compatibility of Chez Scheme versions
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Jul 88 15:17:04 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Jul 88 18:08:57 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA11228@BLOOM-BEACON.MIT.EDU>; Sun, 24 Jul 88 18:01:39 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Jul 88 21:30:40 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Subject: Non-upward-compatibility of Chez Scheme versions
Message-Id: <1709@kalliope.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
`define-macro!', the form used to define macros in older versions of
Chez Scheme [TM, Cadence Research Systems] is also provided in the current
version (along with the fancier `extend-syntax'/`with'). However, the older
version (v.1.1, 1985) seems more powerful (expressive) than the current one
(v.2.0.3, 1987)!
In the old case, it is possible to specify not just text but closures in
a "macro"'s expansion pattern. For example, the following almost pointless
program,
(let ([null? null?])
(define-macro! nil? (x)
`(,null? ,x)) ; note comma before null?
works fine in v.1.1, `nil?' being a macro version of `null?'. As motivation
for using the closure `null?' rather than the variable `null?' in the above
macro expansion, one might consider that the global variable `null?' can now
be redefined to something else, but `nil?' will always test for nil-ness.
This ruse doesn't work in v.2.0.3:
The program (nil? 7) yields the diagnostic:
Error: nonsensical application (#<procedure null?> 7).
Anyone know why Cadence (Dybvig?) thought fit to do away with the old
Chez's more powerful macros? {I don't know Cadence's e-mail address.}
--dorai
ps: It might be argued that there might be newer ways (possibly using `extend-
syntax'/`with') to get the effect described above, if not with the same
program fragment. Nope. There just doesn't seem a way to get closures in
the expansion pattern in new Chez.
∂24-Jul-88 1848 @MC.LCS.MIT.EDU:Olin.Shivers@centro.soar.cs.cmu.edu Non-upward-compatibility of Chez Scheme versions
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Jul 88 18:48:45 PDT
Received: from CENTRO.SOAR.CS.CMU.EDU (TCP 20000557276) by MC.LCS.MIT.EDU 24 Jul 88 21:44:25 EDT
Date: Sun Jul 24 21:43:13 1988
From: Olin.Shivers@CENTRO.SOAR.CS.CMU.EDU
To: titan!dorai@rice.edu
CC: scheme@mc.lcs.mit.edu
In-reply-to: (Dorai Sitaram's message of 24 Jul 88 21:30:40 GMT <1709@kalliope.rice.edu>
Subject: Non-upward-compatibility of Chez Scheme versions
(let ([null? null?])
(define-macro! nil? (x)
`(,null? ,x)) ; note comma before null?
I don't use the Scheme's you use, but I think I can see at least one
problem with this macro: functions are *not* defined in Scheme to be
self-evaluating like, for example, integers are.
So instead of:
,null?
you need:
',null?
As in:
(let ((null? null?))
(define-macro! nil? (x)
`(',null ,x)))
-Olin
∂25-Jul-88 1422 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Non-upward-compatibility of Chez Scheme versions
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Jul 88 14:22:40 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Jul 88 17:09:30 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA07099@BLOOM-BEACON.MIT.EDU>; Mon, 25 Jul 88 17:00:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Jul 88 17:33:02 GMT
From: killer!pollux!ti-csl!mips!gateley@eddie.mit.edu (John Gateley)
Organization: TI Computer Science Center, Dallas
Subject: Re: Non-upward-compatibility of Chez Scheme versions
Message-Id: <54901@ti-csl.CSNET>
References: <1709@kalliope.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <1709@kalliope.rice.edu> dorai@titan.rice.edu (Dorai Sitaram) writes:
>`define-macro!', the form used to define macros in older versions of
>Chez Scheme [TM, Cadence Research Systems] is also provided in the current
>version (along with the fancier `extend-syntax'/`with'). However, the older
>version (v.1.1, 1985) seems more powerful (expressive) than the current one
>(v.2.0.3, 1987)!
Just a side note: you seem to be saying that the define-macro! form is more
powerful than extend-syntax and with. This is not true. Extend-syntax can be
used to do 3-d programming (the technique you describe in your message), and
any macro. It is completely general.
John Gateley
p.s. Extend-syntax was created by Eugene Kohlbecker.
∂26-Jul-88 0917 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu binding and assignment
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 88 09:17:22 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Jul 88 11:55:07 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA28505@BLOOM-BEACON.MIT.EDU>; Tue, 26 Jul 88 11:49:17 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Jul 88 13:53:26 GMT
From: ucsdhub!esosun!jackson@ucsd.edu (Jerry Jackson)
Organization: SAIC, San Diego
Subject: binding and assignment
Message-Id: <238@esosun.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
It occurred to me that there is an inconsistency in the scheme/lisp
treatment of assignment when it comes to symbols -- in all other
cases assignment means changing the contents of a cell of some kind,
while assignment to a symbol is treated as a renaming operation. I
figured this had resulted from the functional programming perspective
-- a binding is simply the name for a value in a particular context...
It seems non-intuitive that assigning to "a" is actually removing
the name "a" from some value and naming a different value "a".
I thought that a slightly different model might be useful --
Let binding be an irrevocable operation. Create a new data type
called a "variable" that has the following property -- When a variable
is returned from eval, it is dereferenced so that its contents are
returned, except when it is the first argument to a set! special form
or the result of a 'var' special form. My intent is that 'variable'
is the only mutable data type -- I'll give a few examples before
explaining the benefits of this model:
(define fact
(lambda (n)
(if (< n 2)
1
(* n (fact (1- n))))))
defines fact as you would imagine and works the same way you would
think -- however, following this with:
(set! fact 5)
would return an error -- fact is not bound to a variable
After evaluating:
(define fact2
(var (lambda (n)
(if (< n 2)
1
(* n (fact2 (1- n)))))))
(fact2 x) would give the same result as (fact x), but
(set! fact2 5) would succeed.
Note: typing "fact2" at this point would return 5, but
the expression: (var? fact2) -> t while (var? fact) -> nil
This produces several benefits:
1) the 'setf' form of CL is obtained for free in a much less
kludgey way -- e.g. after:
(define w (list (var 3) (var 4))) => w = (3 4)
evaluating:
(set! (cadr w) 5)
would cause w to appear as: (3 5)
2) built-in functions can be defined at the top level without using the
'var' form so that they cannot be redefined...
3) the need for things like "named-lambda" is lessened -- If a recursive
function is defined without using 'var', the value will never change
and you get the effect of a named-lambda for free
4) assignment becomes completely consistent and only one assignment
special form is needed instead of one for each type of mutable data --
It is no longer necessary to have vector-set!, set-car!,...
5) quoted constants are now actually guaranteed to be constant --
no more accidental program modification
6) inlining (or direct linking -- not through a symbol) of built-ins
is now allowable without constraints
Any comments?
+-----------------------------------------------------------------------------+
| Jerry Jackson UUCP: seismo!esosun!jackson |
| Geophysics Division, MS/22 ARPA: esosun!jackson@seismo.css.gov |
| SAIC SOUND: (619)458-4924 |
| 10210 Campus Point Drive |
| San Diego, CA 92121 |
+-----------------------------------------------------------------------------+
∂27-Jul-88 0035 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jul 88 00:34:59 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Jul 88 01:54:56 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA18235@BLOOM-BEACON.MIT.EDU>; Wed, 27 Jul 88 01:43:54 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Jul 88 03:35:10 GMT
From: agate!eris!mwm@labrea.stanford.edu (Mike (I'm in love with my car) Meyer)
Organization: Missionaria Phonibalonica
Subject: Re: Scheme shellscripts
Message-Id: <12601@agate.BERKELEY.EDU>
References: <1666@kalliope.rice.edu>, <880716144458.6.JAMES@GREEN-GRASS.LCS.MIT.EDU>, <1700@kalliope.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <various@many.sites> many people write shell scripts with
lines like:
echo > .tmp '(set! $* (quote ('$*')))'
in them. This has one nasty problem - try doing "cd /; <scheme-program>".
You'll find (well, you ought to find) that it dies - you can't create
the scratch file you want. Of course, if two people are in the
directory you're running in and running that command, you'll have
probles too.
Instead, try doing:
echo > /tmp/runscheme.$$ '(set! $* (quote ('$*')))'
This creates a file in /tmp with the process id of the shell executing
the script in it's name. That solves both problems at once.
<mike
--
My feet are set for dancing, Mike Meyer
Won't you turn your music on. mwm@berkeley.edu
My heart is like a loaded gun, ucbvax!mwm
Won't you let the water run. mwm@ucbjade.BITNET
∂27-Jul-88 2000 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme shellscripts
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Jul 88 19:59:54 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Jul 88 22:55:15 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA15325@BLOOM-BEACON.MIT.EDU>; Wed, 27 Jul 88 22:45:49 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Jul 88 21:58:30 GMT
From: quintus!ok@unix.sri.com (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Subject: Re: Scheme shellscripts
Message-Id: <203@quintus.UUCP>
References: <880716144458.6.JAMES@GREEN-GRASS.LCS.MIT.EDU>, <1700@kalliope.rice.edu>, <12601@agate.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <12601@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike Meyer) writes:
...
>Instead, try doing:
> echo > /tmp/runscheme.$$ '(set! $* (quote ('$*')))'
>This creates a file in /tmp ...
Um, /tmp is for system programs. /usr/tmp is the place for user temporary
files. A number of system V utilities support the convention of trying to
create files in $TMPDIR. It might be better, then, to do
scheme_temp=${TMPDIR:-/usr/tmp}/runscheme.$$
echo '(set! $* (quote ('$*')))' >$scheme_temp
You'll want to keep track of the file name so that you can delete it.
∂28-Jul-88 0358 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET Re: binding and assignment
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Jul 88 03:58:48 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 28 Jul 88 06:52:33 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4278; Thu, 28 Jul 88 06:50:17 EDT
Received: from DB0TUI6.BITNET (ZTUBTFAL) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 4277; Wed, 27 Jul 88 12:52:43 EDT
Received: by tub.UUCP; Wed, 27 Jul 88 18:48:10 +0200; AA08383
Received: by tub-tfs.uucp (3.2/SMI-3.0DEV3)
id AA03879; Wed, 27 Jul 88 18:43:57 +0200
Date: Wed, 27 Jul 88 18:43:57 +0200
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8807271643.AA03879@tub-tfs.uucp>
In-Reply-To: Jerry Jackson's message as of Jul 26, 13:53.
X-Mailer: Mail User's Shell (6.3 6/25/88)
To: pyramid!uunet!mc.lcs.mit.edu!scheme-request@tub.UUCP,
esosun!jackson%seismo.css.gov@tub.BITNET
Subject: Re: binding and assignment
Cc: scheme%mc.lcs.mit.edu@tub.BITNET
() It occurred to me that there is an inconsistency in the scheme/lisp
() treatment of assignment when it comes to symbols -- in all other
() cases assignment means changing the contents of a cell of some kind,
() while assignment to a symbol is treated as a renaming operation. I
() figured this had resulted from the functional programming perspective
() -- a binding is simply the name for a value in a particular context...
()
() It seems non-intuitive that assigning to "a" is actually removing
() the name "a" from some value and naming a different value "a".
I don't understand what you mean. You assign values to symbols and
this is realized by modifying the innermost environment, where the
symbol is bound.
You can use this scheme to define any mutable data structure. Consider
following implementation of cons (see also Abelson/Sussman,"The structure
and the interpretation of Computer Programs", pp 207) :
(define (my-cons x y)
(lambda (m)
(cond ((eq? m 'car) x)
((eq? m 'cdr) y)
((eq? m 'set-car!) (lambda (v) (set! x v)))
((eq? m 'set-cdr!) (lambda (v) (set! y v))))))
(define my-car (x) (x 'my-car))
(define my-cdr (x) (x 'my-cdr))
(define my-set-car! (x v) ((x 'set-car!) v))
(define my-set-cdr! (x v) ((x 'set-cdr!) v))
These implementation of cons is heavily influenced by the
representation of data structures in the lambda calculus. But you have
no assignment in the lambda calculus. I found it quite interesting how
well a very general assignment and lambda calculus can live together
(if you have call-by-name semantics).
() I thought that a slightly different model might be useful.
However your idea with the "var"- form is not so bad. (I only can't
understand the reasons you gave). A thing like this is realized in ML
(which is also a functional, but typed language, developed at
Edinburgh, from Robin Milner et al.)
They have a type 'a ref ('a is a type-variable) with the following
operations :
ref : 'a -> 'a ref
! : 'a ref -> 'a
(op :=) : 'a ref * 'a -> unit (* op means infix & unit is novalue).
A simple example (see R.Harpers "Introduction to Standard ML", p. 36):
(- is what the user types in, > are the systems responses).
- val x = ref 0;
> val x = ref(0) : int ref
- !x;
> 0 : int
- x := 3;
> () : unit
- !x;
> 3 : int
As might be clear you can use ref as a part of every data structure.
() This produces several benefits:
()
() 1) the 'setf' form of CL is obtained for free in a much less
() kludgey way -- e.g. after:
() ...
() 4) assignment becomes completely consistent and only one assignment
() special form is needed instead of one for each type of mutable data --
() It is no longer necessary to have vector-set!, set-car!,...
OK. But you export more about the implementation of a data type. No
problems with vectors and things like this, but if you implement a
more complex data type, you may decide to change the implementation
w.o. changing the interface. That becomes impossible, if your export
includes referential types.
() 2) built-in functions can be defined at the top level without using the
() 'var' form so that they cannot be redefined...
() ...
() 6) inlining (or direct linking -- not through a symbol) of built-ins
() is now allowable without constraints
I think that's more a point of the module structure of your program.
You often use modules and you don't want to change them, not only the
primitive functions. It should be possible to declare these different
usages of modules. (CommonLisp has package to realize modules, but it
lacks the possibility to declare a package as read-only).
() 3) the need for things like "named-lambda" is lessened -- If a recursive
() function is defined without using 'var', the value will never change
() and you get the effect of a named-lambda for free
named-lambda is a derivative from rec, and rec is the fixed-point
combinator. I think this is the onliest semantical clean way tp define
recursion. You should get an error if you use a variable on a point
where it is not defined. (That's the way ML works).
() 5) quoted constants are now actually guaranteed to be constant --
() no more accidental program modification
This should be garanteed by the production system, independenly of the
philosophy of assignments.
Thorsten
∂29-Jul-88 2328 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Amiga C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Jul 88 23:28:49 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 30 Jul 88 01:41:19 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA19144@BLOOM-BEACON.MIT.EDU>; Sat, 30 Jul 88 01:29:57 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 30 Jul 88 03:05:18 GMT
From: vu-vlsi!sword@psuvax1.psu.edu (David Talmage)
Organization: Villanova Univ. EE Dept.
Subject: Amiga C-Scheme?
Message-Id: <1774@vu-vlsi.Villanova.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Has anyone ported C-Scheme to the Amiga? I've got the sources on my
VAXen here at Villanova. Is it worth my time to try to make C-Scheme
run on my 2.5 MByte Amiga?
David Talmage
Villanova University/University Computing and Information Services
talmage@excalibur.UUCP
talmage@vuvaxcom.BITNET
∂31-Jul-88 0001 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Amiga C-Scheme?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jul 88 00:01:34 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Jul 88 02:56:35 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA18269@BLOOM-BEACON.MIT.EDU>; Sun, 31 Jul 88 02:46:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Jul 88 06:18:30 GMT
From: killer!elg@ames.arpa (Eric Green)
Organization: The Unix(R) Connection, Dallas, Texas
Subject: Amiga C-Scheme?
Message-Id: <5037@killer.DALLAS.TX.US>
References: <1774@vu-vlsi.Villanova.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In message <1774@vu-vlsi.Villanova.EDU>, sword@vu-vlsi.Villanova.EDU (David Talmage) says:
>Has anyone ported C-Scheme to the Amiga? I've got the sources on my
>VAXen here at Villanova. Is it worth my time to try to make C-Scheme
>run on my 2.5 MByte Amiga?
C-Scheme will probably run quite slowly on an Amiga (it's no
speed-demon on the Pyramid 90x machines at school). The memory image
on the Pyramids is around 2 megabytes, so you should be able to fit it
into memory. But you wouldn't be able to have much else in the
machine.
I would say that it wasn't worth it, but it depends on how much you
want Scheme. If you do decide to try it, make sure you have the latest
copy of C-Scheme from the Free Software Foundation. Between the 16.xx
Emacs tapes and the 17.xx Emacs tapes, C-Scheme was changed in fairly
major ways to make it more portable (I had a hard time bringing the
16.xx version up on the Pyramids, while the 17.xx version came up with
no problem at all).
--
Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
Snail Mail P.O. Box 92191 Lafayette, LA 70509
MISFORTUNE, n. The kind of fortune that never misses.
∂02-Aug-88 0539 @MC.LCS.MIT.EDU:gls@Think.COM Continuations and multiple values
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Aug 88 05:39:36 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 2 Aug 88 08:35:30 EDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Tue, 2 Aug 88 08:28:04 EDT
Received: by brigit.think.com; Tue, 2 Aug 88 08:30:26 EDT
Date: Tue, 2 Aug 88 08:30:26 EDT
From: gls@Think.COM
Message-Id: <8808021230.AA22090@brigit.think.com>
To: scheme@mc.lcs.mit.edu
Subject: Continuations and multiple values
Here I write down some of the ideas I put forward on multiple values
at the Scheme meeting of Sunday, July 24, 1988.
Different Lisp dialects have different theories about how to handle
multiple values when the "wrong" number are returned. The main point
of this note is that the implementation of these theories can be
moved out of CWCC and into VALUES, which can be written as user-level
code provided that some simple predicates are provided.
Let us suppose that every continuation accepts noly the "correct"
number of values. In other words, the continuation for evaluating
a subform of a combination requires one value; the continuation
for evaluating an IF predicate requires one value; and the continuation
for evaluating a non-final subform of BEGIN requires zero values.
Define (WITH-VALUES thunk f) to call the thunk with a continuation
that accepts as many arguments as f does. (In effect the continuation
is the composition of the continuation of the WITH-VALUES form with f.)
Then the simplest definition of VALUES is:
(define (values . r) (cwcc (lambda (k) (apply k r))))
Let the predicate (ACCEPTS? f n) be true if f will accept n arguments,
and false otherwise. (This is generally useful for writing interpreters.)
Suppose we want to allow excess values to be ignored. We can then
write:
(define (values . r)
(define (ignore-excess-values k z)
(if (accepts? k (length z))
(apply k z)
(if (null z)
(apply k r) ;take the error with all values
(ignore-excess-values k (cdr z)))))
(cwcc (lambda (k) (ignore-excess-values k r))))
A similar technique can be used to provide extra #F values as well if not
enough values were provided. (We don't know when to stop, but every
continuation must accept some number of values, so the process must
terminate.)
(define (values . r)
(define (ignore-excess-values k z)
(if (accepts? k (length z))
(apply k z)
(if (null z)
(supply-default-falses k r)
(ignore-excess-values k (cdr z)))))
(define (supply-default-falses k z)
(if (accepts? k (length z))
(apply k z)
(supply-default-falses k (cons '#f z))))
(cwcc (lambda (k) (ignore-excess-values k r))))
Now the assumption that a BEGIN continuation requires exactly zero values
is a bit stringent. This may be a good thing; perhaps one ought to mark
explicitly where a value is being discarded. One might have the syntax
(void x) -> (with-values (lambda () x) (lambda r (values)))
and then write
(begin (set! x 3)
(void (valued-function-with-side-effect x))
(+ x 1))
where we assume that set! is already defined to return zero values.
If this arrangement is not acceptable then perhaps BEGIN continuations
should accept 0 or 1 value, discarding the value if any.
Another paradigm we might wish to emulate is that where VALUES may
not be used except with continuations explicitly created by WITH-VALUES.
Here are two ways to do that; one requires a new predicate, and the
other is a crock.
If we have a predicate (WITH-VALUES-CONTINUATION? f) that is true
precisely of continuations created by WITH-VALUES, then we write simply
(define (values . r)
(cwcc (lambda (k)
(if (with-values-continuation? k)
...
(error)))))
On the other hand, instead of requiring such a built-in predicate
we can take advantage of the fact that no other continuation takes
more than one value (this is the crock):
(define old-with-values with-values)
(define (with-values thunk f)
(old-with-values thunk (lambda (foo bar . r) (apply f r))))
(define (values . r)
(cwcc (lambda (k)
(if (accepts? k 2) (apply k (cons #f (cons #f r))) (error)))))
The "foo bar" arguments ensure that only a VALUES can correctly provide the
values to a WITH-VALUES. The ACCEPTS? test determines whether the
continuation K was actually provided by a WITH-VALUES.
--Guy Steele
∂09-Aug-88 1520 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu "rabbit" report needed.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Aug 88 15:20:36 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 18:12:38 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA26954@BLOOM-BEACON.MIT.EDU>; Tue, 9 Aug 88 17:54:46 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Aug 88 18:08:10 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: "rabbit" report needed.
Message-Id: <838@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I need a copy of the rabbit report, and I believe MIT is
out of prints. Would someone who has the report be willing
to mail me a photocopy ? [will pay for the photocopying and
mailing costs] Please respond via e-mail.
thnx in advance. oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂10-Aug-88 0212 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme for the Mac?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Aug 88 02:12:29 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Aug 88 03:57:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA06826@BLOOM-BEACON.MIT.EDU>; Wed, 10 Aug 88 02:47:02 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Aug 88 05:47:08 GMT
From: fenchurch.mit.edu!jbs@eddie.mit.edu (Jeff Siegal)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Subject: Scheme for the Mac?
Message-Id: <9848@eddie.MIT.EDU>
References: <838@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
A friend is looking for a Scheme package for the Mac for learning
purposes. Any recommendations?
Jeff Siegal
∂10-Aug-88 1029 @MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu Scheme for the Mac?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Aug 88 10:29:14 PDT
Received: from a.cs.uiuc.edu (TCP 1200600045) by MC.LCS.MIT.EDU 10 Aug 88 13:13:13 EDT
Received: from kaplan.cs.uiuc.edu by a.cs.uiuc.edu with SMTP (UIUC-5.52/9.7)
id AA26313; Wed, 10 Aug 88 12:08:17 CDT
Received: by kaplan.cs.uiuc.edu (3.2/9.7)
id AA00210; Wed, 10 Aug 88 12:11:01 CDT
Date: Wed, 10 Aug 88 12:11:01 CDT
From: kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu (Simon Kaplan)
Message-Id: <8808101711.AA00210@kaplan.cs.uiuc.edu>
To: fenchurch.mit.edu!jbs@eddie.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Jeff Siegal's message of 10 Aug 88 05:47:08 GMT <9848@eddie.MIT.EDU>
Subject: Scheme for the Mac?
the best scheme available exists on the mac, it's sold by semantic
microsystems in portland oregon, their numbber is (503) 643-4539.
∂10-Aug-88 1318 @MC.LCS.MIT.EDU:maddox@renoir.Berkeley.EDU XSCHEME
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Aug 88 13:18:40 PDT
Received: from renoir.Berkeley.EDU (TCP 20010101004) by MC.LCS.MIT.EDU 10 Aug 88 16:13:09 EDT
Received: by renoir.Berkeley.EDU (5.59/1.29)
id AA26849; Wed, 10 Aug 88 13:11:13 PDT
Date: Wed, 10 Aug 88 13:11:13 PDT
From: maddox@renoir.Berkeley.EDU (William Maddox)
Message-Id: <8808102011.AA26849@renoir.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu
Subject: XSCHEME
Is there anywhere on the net where I can FTP a copy of XSCHEME?
XSCHEME is an implementation of Scheme by David Betz, author of XLISP,
a small and highly portable Common Lisp (psuedo-)subset written in C.
I am also interested in any other Scheme implementation that is
freely distributable in source form, easily ported to a 68K Unix
box, and economical in its use of resources (runs well in 2 meg or less).
Bill Maddox
ucbvax!renoir!maddox
maddox@renoir.berkeley.edu
∂12-Aug-88 0333 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: XSCHEME
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Aug 88 03:32:57 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 06:28:33 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA03329@BLOOM-BEACON.MIT.EDU>; Fri, 12 Aug 88 05:23:44 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Aug 88 13:43:22 GMT
From: mmm!com50!pai!erc@umn-cs.arpa (Eric Johnson)
Organization: Prime Automation, Inc., Burnsville, MN
Subject: Re: XSCHEME
Message-Id: <133@pai.UUCP>
References: <8808102011.AA26849@renoir.Berkeley.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8808102011.AA26849@renoir.Berkeley.EDU>, maddox@RENOIR.BERKELEY.EDU (William Maddox) writes:
>
> Is there anywhere on the net where I can FTP a copy of XSCHEME?
> XSCHEME is an implementation of Scheme by David Betz, author of XLISP,
> a small and highly portable Common Lisp (psuedo-)subset written in C.
> Bill Maddox
> ucbvax!renoir!maddox
> maddox@renoir.berkeley.edu
The latest XScheme is available on the Byte Information eXchange (BIX).
When I asked David Betz about posting XLisp to Usenet, he wrote that
eventually he wanted to post XScheme, but at the time (about a month ago)
XScheme was not finished enough (in his opinion) for posting. (Someone
beat me to the XLisp posting, so I haven't pursued the matter
further. When David Betz is satisfied XScheme is post-able, I
certainly wouldn't mind submitting it to a sources moderator. For now,
your best bet is to try BIX.)
I've been very impressed with Betz's work, especially since
XLisp helped me through an AI course (being able to work on
a PC, Mac and Unix workstation with the same program certainly
helped).
What I'm hoping for now is an XProlog.
-Eric
--
Eric F. Johnson | Phone +1 612-894-0313 | Are we
Prime Automation,Inc | UUCP: bungia!pai!erc | having
12201 Wood Lake Drive | UUCP: sun!tundra!pai!erc | fun
Burnsville, MN 55337 USA | DOMAIN: erc@pai.mn.org | yet?
∂14-Aug-88 0033 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Scheme for the Mac?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Aug 88 00:32:53 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Aug 88 03:27:51 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA19905@BLOOM-BEACON.MIT.EDU>; Sun, 14 Aug 88 03:22:00 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Aug 88 06:23:53 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Subject: Re: Scheme for the Mac?
Message-Id: <25632@ucbvax.BERKELEY.EDU>
References: <9848@eddie.MIT.EDU>, <8808101711.AA00210@kaplan.cs.uiuc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
If you want to get truly intimate with scheme, you might consider siod
(scheme in one definition.)
gjc%bucsf.bu.edu@bu-it.bu.edu (George J. Carrette)
is responsible for it. He distributes it as source code, and it runs on
the mac.
∂14-Aug-88 1102 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:SCHREQ@MC.LCS.MIT.EDU Periodic noise message; list policy reiterated
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Aug 88 11:02:33 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 14 Aug 88 13:57:08 EDT
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 129473; Sun 14-Aug-88 13:56:52 EDT
Date: Sun, 14 Aug 88 13:57 EDT
From: Scheme Requestee <SCHREQ@MC.LCS.MIT.EDU>
Subject: Periodic noise message; list policy reiterated
To: scheme@MC.LCS.MIT.EDU
Message-ID: <"19880814175700.5.schreq@MC"@QUESTION-AUTHORITY.AI.MIT.EDU>
[I periodically send this message in order to show the mailing list
policy blurb to people who may not have already seen it, and in order to
weed out bad addresses from the list. You can ignore this message if
you've already seen something like it.]
General information about the Scheme mailing list:
- The list is not moderated. If you send mail to scheme@mc.lcs.mit.edu,
it will be forwarded to the hundreds (thousands?) of list members on the
ARPA Internet, CSNET, BITNET, Usenet, JUNET, etc. If you have any doubt
about the suitability of your message for this audience, send it to
scheme-request@mc.lcs.mit.edu instead, and your message will be either
answered or forwarded.
- Avoid sending messages concerning MIT's scheme implementation (C
Scheme) to the list; users of the many other Scheme implementations
don't generally care to see such messages. There is a separate list,
info-cscheme@zurich.ai.mit.edu, for this purpose. To be added to that
list, send mail to info-cscheme-maintainer@zurich.ai.mit.edu.
- Similarly for T (Yale Scheme): send requests to
T-Discussion-Request@mc.lcs.mit.edu.
- Send administrative requests to scheme-request@mc.lcs.mit.edu. If
your machine is scheduled to change its name or routing, or to go off
the net, or if you move, please send mail to scheme-request so your
entry can be changed.
- Problem addresses on the list will be quietly removed from the list.
Your address may become invalid due to no fault of your own, and/or
without your being aware of it. For example, if your system becomes
inaccessible from the Internet for a week, of if it changes its name,
messages to you will bounce, and your entry will be removed from the
list. If you don't get any Scheme list messages for, say, a month, you
might want to send a message to scheme-request to verify that you're
still on.
- If you send a message and receive mailer error reports in reply,
forward the error reports to scheme-request@mc.lcs.mit.edu.
- If you think there will be more than one person at your site who wants
to be on the list, please set up a local redistribution list.
- There is bidirectional forwarding between Usenet's comp.lang.scheme
and the Internet Scheme list.
- Messages are archived in the following files:
LSPMAI; SCHEME MAIL1 on host AI.AI.MIT.EDU [oldest messages]
LSPMAI; SCHEME MAIL2 on host AI.AI.MIT.EDU
LSPMAI; SCHEME MAIL3 on host AI.AI.MIT.EDU
LSPMAI; SCHEME MAIL4 on host AI.AI.MIT.EDU
LSPMAI; SCHEME MAIL on host MC.LCS.MIT.EDU [newest messages]
Note that there are spaces in these filenames, so you may have to type
double quotes at your FTP program. If you don't have Internet FTP access,
tough luck.
- There is a file on host AI.AI.MIT.EDU, "LSPMAI; SCHEME IMPLS", that
has brief descriptions of available scheme implementations and how to
get them. If you want a copy of this file, but you don't have Internet
FTP access, send a request to scheme-request.
Jonathan Rees
14 August 1988
∂16-Aug-88 1356 @MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu A Quick Note on the Last L&FP Conference
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 13:56:39 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 16 Aug 88 16:24:21 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26479; Tue, 16 Aug 88 13:37:41 MDT
Received: by cons.utah.edu (5.54/utah-2.0-leaf)
id AA22021; Tue, 16 Aug 88 13:37:35 MDT
Date: Tue, 16 Aug 88 13:37:35 MDT
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8808161937.AA22021@cons.utah.edu>
To: common-lisp@sail.stanford.edu, scheme@mc.lcs.mit.edu, fp@cs.yale.edu
Cc: dswise@iuvax.cs.indiana.edu
Subject: A Quick Note on the Last L&FP Conference
One of the rumblings that I heard at the conference was that a number
of people didn't receive their copies of the Advance Program mailing
from ACM. Thus, it made it more difficult to register. If any of you
are members of SIGPLAN, SIGART, or SIGACT and you did not receive a
copy of the program some time in May, would you please send David Wise
a message (dswise@iuvax.cs.indiana.edu). He is trying to collect
actual data on the hits and misses of the mailing. Please send him
your name, mailing address at which you receive ACM materials, and
your ACM number if you have it.
Thanks.
Bob.
∂17-Aug-88 0426 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme Bibliography (Aug. 1988)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Aug 88 04:22:42 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 17 Aug 88 07:16:33 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA11198@BLOOM-BEACON.MIT.EDU>; Wed, 17 Aug 88 07:03:41 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Aug 88 22:01:38 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme Bibliography (Aug. 1988)
Message-Id: <842@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
BIB/REFER Database on SCHEME
This posting contains is a reasonable bibliography database on Scheme
(a crystal in the muddy language landscape), BIB/REFER format,
containing 82 entries sorted by date and first author, for your
perusal, corrections and enjoyment. I do not consider it complete
nor correct, hence your contributions and/or corrections are
gratefully accepted.
[Note: this posting also contains a r2bib (BibTeX) translation of the
database. I think BibTeX format is losing. If anyone knows of a better
bibliography format suitable for TeX, please let me know.]
So, here it is for your enjoyment. Happy Scheming... oz
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of shell archive."
# Contents: tags.doc scheme.bib scheme.bibtex
# Wrapped by oz@yunexus on Tue Aug 16 18:00:48 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'tags.doc' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'tags.doc'\"
else
echo shar: Extracting \"'tags.doc'\" \(422 characters\)
sed "s/↑X//" >'tags.doc' <<'END_OF_FILE'
XBIB (UofArizona) Field Tags
X
X%A - Author's name
X%B - Title of the book containing item
X%C - City of publication
X%D - Date
X%E - Editor(s) of book containing item
X%F - Caption
X%G - Government (NTIS) ordering number
X%I - Issuer (publisher)
X%J - Journal name
X%K - Keys for searching
X%N - Issue number
X%O - Other information
X%P - Page(s) of article
X%R - Technical report number
X%S - Series title
X%T - Title
X%V - Volume number
END_OF_FILE
if test 422 -ne `wc -c <'tags.doc'`; then
echo shar: \"'tags.doc'\" unpacked with wrong size!
fi
# end of 'tags.doc'
fi
if test -f 'scheme.bib' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'scheme.bib'\"
else
echo shar: Extracting \"'scheme.bib'\" \(15607 characters\)
sed "s/↑X//" >'scheme.bib' <<'END_OF_FILE'
X
X%A John Reynolds
X%T Definitional Interpreters for Higher Order Programming Languages
X%J ACM Conference Proceedings
X%P 717-740
X%I ACM
X%D 1972
X
X%A Gerald Jay Sussman
X%A Guy Lewis Steele, Jr.
X%T Scheme: an Interpreter for Extended Lambda Calculus
X%R MIT Artificial Intelligence Memo 349
X%C Cambridge, Mass.
X%D December 1975
X
X%A Guy Lewis Steele, Jr.
X%A Gerald Jay Sussman
X%T Lambda, the Ultimate Imperative
X%R MIT Artificial Intelligence Memo 353
X%C Cambridge, Mass.
X%D March 1976
X%K imperative
X
X%A Guy Lewis Steele, Jr.
X%T Lambda, the Ultimate Declarative
X%R MIT Artificial Intelligence Memo 379
X%C Cambridge, Mass.
X%D November 1976
X%K declarative
X
X%A Guy Lewis Steele, Jr.
X%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call
XImplementations Considered Harmful, or LAMBDA, the Ultimate GOTO
X%J ACM Conference Proceedings
X%P 153-162
X%I ACM
X%D 1977
X
X%A Guy Lewis Steele, Jr.
X%T Macaroni is Better than Spaghetti
X%J Proceedings of the Symposium on Artificial Intelligence and
XProgramming Languages
X%P 60-66
X%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64
X%D August 1977
X
X%A Mitchell Wand
X%T Continuation-Based Program Transformation Strategies
X%J Journal of the ACM
X%V 27
X%N 1
X%P 174-180
X%D 1978
X
X%A Guy Lewis Steele, Jr.
X%A Gerald Jay Sussman
X%T The Revised Report on Scheme, a Dialect of Lisp
X%R MIT Artificial Intelligence Memo 452
X%C Cambridge, Mass.
X%D January 1978
X
X%A Guy Lewis Steele, Jr.
X%T Rabbit: a Compiler for Scheme
X%R MIT Artificial Intelligence Laboratory Technical Report 474
X%C Cambridge, Mass.
X%D May 1978
X
X%A Guy Lewis Steele, Jr.
X%A Gerald Jay Sussman
X%T The Art of the Interpreter, or the Modularity Complex
X(parts zero, one, and two)
X%R MIT Artificial Intelligence Memo 453
X%C Cambridge, Mass.
X%D May 1978
X%K modularity
X
X%A Drew McDermott
X%T An Efficient Environment Allocation Scheme in an Interpreter
Xfor a Lexically-Scoped Lisp
X%J Conference Record of the 1980 Lisp Conference
X%P 154-162
X%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
X%D 1980
X%O Proceedings reprinted by ACM
X
X%A Steven S. Muchnick
X%A Uwe F. Pleban
X%T A Semantic Comparison of Lisp and Scheme
X%J Conference Record of the 1980 Lisp Conference
X%P 56-65
X%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
X%D 1980
X
X%A Guy Lewis Steele, Jr.
X%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
X%B AI: An MIT Perspective
X%E Patrick Henry Winston
X%E Richard Henry Brown
X%I MIT Press
X%C Cambridge, Mass.
X%D 1980
X
X%A Guy Lewis Steele, Jr.
X%A Gerald Jay Sussman
X%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism
X%J Conference Record of the 1980 Lisp Conference
X%P 163-172
X%I The Lisp Conference
X%D 1980
X
X%A Mitchell Wand
X%T Continuation-Based Multiprocessing
X%J Conference Record of the 1980 Lisp Conference
X%P 19-28
X%I The Lisp Conference
X%D 1980
X
X%A Guy Lewis Steele, Jr.
X%A Gerald Jay Sussman
X%T Design of a Lisp-based Processor
X%J CACM
X%V 23
X%N 11
X%P 628-645
X%D November 1980
X
X%A Gerald Jay Sussman
X%A Jack Holloway
X%A Guy Lewis Steele, Jr.
X%A Alan Bell
X%T Scheme-79 - Lisp on a Chip
X%J IEEE Computer
X%V 14
X%N 7
X%P 10-21
X%D July 1981
X%I IEEE
X
X%A John Batali
X%A Edmund Goodhue
X%A Chris Hanson
X%A Howie Shrobe
X%A Richard M. Stallman
X%A Gerald Jay Sussman
X%T The Scheme-81 Architecture - System and Chip
X%J Proceedings, Conference on Advanced Research in VLSI
X%P 69-77
X%E Paul Penfield, Jr.
X%C Artech House, Dedham MA.
X%D 1982
X%K scheme81
X
X%A Peter Henderson
X%T Functional Geometry
X%J Conference Record of the 1982 ACM Symposium on Lisp and
XFunctional Programming
X%P 179-187
X%D 1982
X
X%A Jonathan A. Rees
X%A Norman I. Adams
X%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool
X%J Conference Record of the 1982 ACM Symposium on Lisp and
XFunctional Programming
X%P 114-122
X%D 1982
X
X%A Gerald Jay Sussman
X%T LISP, Programming and Implementation
X%B Functional Programming and its Applications
X%E Darlington, Henderson, Turner
X%I Cambridge University Press
X%C London
X%D 1982
X
X%A Pee Hong Chen
X%A W.Y. Chi
X%A E.M. Ost
X%A L.D. Sabbagh
X%A G. Springer
X%T Scheme Graphics Reference Manual
X%R Computer Science Technical Report No. 145
X%I Indiana University
X%C Bloomington, Indiana
X%D August 1983
X
X%A Pee Hong Chen
X%A Daniel P. Friedman
X%T Prototyping data flow by translation into Scheme
X%R Computer Science Technical Report #147
X%I Indiana University
X%C Bloomington, Indiana
X%D August 1983
X
X%A Carol Fessenden
X%A William Clinger
X%A Daniel P. Friedman
X%A Christopher T. Haynes
X%T Scheme 311 version 4 Reference Manual
X%R Computer Science Technical Report 137
X%I Indiana University
X%C Bloomington, Indiana
X%D February 1983
X%O Superceded by Computer Science Technical Report 153, 1985
X
X%A William Clinger
X%T The Scheme 311 compiler: An Exercise in Denotational Semantics
X%J Conference Record of the 1984 ACM Symposium on Lisp and
XFunctional Programming
X%P 356-364
X%D 1984
X%K comp311
X
X%A Daniel P. Friedman
X%A Christopher T. Haynes
X%A Eugene E. Kohlbecker
X%T Programming with Continuations
X%B Program Transformation and Programming Environments
X%P 263-274
X%E P. Pepper
X%I Springer-Verlag
X%D 1984
X
X%A Christopher T. Haynes
X%A Daniel P. Friedman
X%T Engines Build Process Abstractions
X%J Conference Record of the 1984 ACM Symposium on Lisp and
XFunctional Programming
X%C Austin, TX.
X%P 18-24
X%D 1984
X
X%A Christopher T. Haynes
X%A Daniel P. Friedman
X%A Mitchell Wand
X%T Continuations and Coroutines
X%J Conference Record of the 1984 ACM Symposium on Lisp and
XFunctional Programming
X%C Austin, TX.
X%P 293-298
X%D 1984
X
X%A Daniel P. Friedman
X%A Mitchell Wand
X%T Reification: reflection without metaphysics
X%J Conference Record of the 1984 ACM Symposium on LISP and Functional
XProgramming
X%C Austin, TX.
X%P 348-355
X%D August 1984
X
X%A Jonathan A. Rees
X%A Norman I. Adams
X%A James R. Meehan
X%T The T manual, fourth edition
X%I Yale University Computer Science Department
X%D January 1984
X
X%A Guillermo J. Rozas
X%T Liar, an Algol-like Compiler for Scheme
X%I S. B. Thesis, MIT Department of Electrical Engineering and Computer
XScience
X%D January 1984
X
X%T MIT Scheme Manual, Seventh Edition
X%I Department of Electrical Engineering and Computer Science, MIT
X%C Cambridge, Mass.
X%D September 1984
X
X%T MacScheme Reference Manual
X%I Semantic Microsystems
X%C Sausalito, Calif.
X%D 1985
X
X%A Harold Abelson
X%A Gerald Jay Sussman
X%A Julie Sussman
X%T Structure and Interpretation of Computer Programs
X%I MIT Press
X%C Cambridge, Mass.
X%D 1985
X%K sicp
X
X%A William Clinger
X%A Daniel P. Friedman
X%A Mitchell Wand
X%T A Scheme for a Higher-Level Semantic Algebra
X%B Algebraic Methods in Semantics
X%E J. Reynolds, M. Nivat
X%P 237-250
X%I Cambridge University Press
X%C London
X%D 1985
X
X%A Amitabh Srivastava
X%A Don Oxley
X%A Aditya Srivastava
X%T An (other) Integration of Logic and Functional Programming
X%J Proceedings of the Symposium on Logic Programming
X%P 254-260
X%I IEEE
X%D 1985
X
X%E William Clinger
X%T The Revised Revised Report on Scheme, or An Uncommon Lisp
X%R MIT Artificial Intelligence Memo 848
X%C Cambridge, Mass.
X%O Also published as Computer Science Department Technical Report 174,
XIndiana University, June 1985
X%D August 1985
X%K rrrs
X
X%A Daniel P. Friedman
X%A Christopher T. Haynes
X%T Constraining Control
X%J Proceedings of the Twelfth Annual Symposium on Principles of
XProgramming Languages
X%C New Orleans, LA.
X%P 245-254
X%I ACM
X%D January 1985
X
X%A Daniel P. Friedman
X%A Christopher T. Haynes
X%A Eugene E. Kohlbecker
X%A Mitchell Wand
X%T Scheme 84 Interim Reference Manual
X%R Computer Science Technical Report 153
X%I Indiana University
X%C Bloomington, Indiana
X%D January 1985
X%K scheme84
X
X%A Peehong Chen
X%A L. David Sabbagh
X%T Scheme as an Interactive Graphics Programming Environment
X%R Computer Science Technical Report No. 166
X%I Indiana University
X%C Bloomington, Indiana
X%D March 1985
X
X%T TI Scheme Language Reference Manual
X%I Texas Instruments, Inc.
X%O Preliminary version 1.0
X%D November 1985
X
X%A Michael A. Eisenberg
X%T Bochser: An Integrated Scheme Programming System
X%R MIT Computer Science Technical Report 349
X%C Cambridge, Mass.
X%D October 1985
X%K bochser
X
X%T Transliterating Prolog into Scheme
X%A Matthias Felleisen
X%R Computer Science Technical Report #182
X%I Indiana University
X%C Bloomington, Indiana
X%D October 1985
X
X%A David H. Bartley
X%A John C. Jensen
X%T The Implementation of PC Scheme
X%J Proceedings of the 1986 ACM Conference on Lisp
Xand Functional Programming
X%P 86-93
X%D 1986
X%K pcscheme
X
X%A R. Kent Dybvig
X%A Daniel P. Friedman
X%A Christopher T. Haynes
X%T Expansion-Passing style: Beyond Conventional Macros
X%J Proceedings of the 1986 ACM Conference on Lisp and
XFunctional Programming
X%P 143-150
X%D 1986
X
X%A Marc Feeley
X%A Guy LaPalme
X%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE
X%O Submitted for Publication
X%D 1986
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%T A Closer Look At Export and Import Statements
X%J Journal of Computer Languages
X%V 11
X%N 1
X%P 29-37
X%I Pergamon Press
X%D 1986
X
X%A Daniel P. Friedman
X%A Matthias Felleisen
X%T The Little LISPer: Second Edition
X%I Science Research Associates, Inc.
X%C Palo Alto, California
X%D 1986
X
X%A Christopher T. Haynes
X%A Daniel P. Friedman
X%A Mitchell Wand
X%T Obtaining Coroutines With Continuations
X%J Journal of Computer Languages
X%V 11
X%N 3/4
X%P 143-153
X%I Pergamon Press
X%D 1986
X
X%A Mitchell Wand
X%T Finding the Source of Type Errors
X%J Conference Record of the Thirteenth Annual Symposium on
XPrinciples of Programming Languages
X%P 38-43
X%I ACM
X%C St. Peterburg, Fla.
X%D 1986
X
X%A Mitchell Wand
X%T From Interpreter to Compiler: A Representational Derivation
X%B Programs as Data Objects
X%I Springer-Verlag Lecture Notes
X%D 1986
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%T Control operators, the SECD-machine, and the lambda-calculus
X%J 3rd Working Conference on the Formal Description of
XProgramming Concepts
X%C Ebberup, Denmark
X%P 193-219
X%D August 1986
X
X%A Eugene E. Kohlbecker
X%T Syntactic Extensions in the Programming Language Lisp
X%R Computer Science Technical Report #199 (PhD Dissertation)
X%I Indiana University
X%C Bloomington, Indiana
X%D August 1986
X
X%A Eugene E. Kohlbecker
X%A Daniel P. Friedman
X%A Matthias Felleisen
X%A Bruce Duba
X%T Hygienic macro expansion
X%J Symposium on LISP and Functional Programming
X%P 151-161
X%D August 1986
X%O To appear in Lisp and Symbolic Computation
X
X%A Mitchell Wand
X%T The mystery of the tower revealed: a non-reflective
Xdescription of the reflective tower
X%J Proceedings of the 1986 ACM Symposium on LISP and Functional Programming
X%P 298-307
X%D August 1986
X
X%E Jonathan A. Rees
X%E William Clinger
X%T Revised↑3 Report on the Algorithmic Language Scheme
X%J ACM Sigplan Notices
X%V 21
X%N 12
X%D December 1986
X
X%A Christopher T. Haynes
X%T Logic Continuations
X%J Proceedings of the Third International Conference on
XLogic Programming
X%P 671-685
X%I Springer-Verlag
X%D Jul 1986
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%A Eugene E. Kohlbecker
X%A Bruce Duba
X%T Reasoning with Continuations
X%J Proceedings of the Symposium on Logic in Computer Science
X%P 131-141
X%I IEEE Computer Society Press
X%C Washigton DC
X%D June 1986
X
X%A David Kranz
X%A Richard Kelsey
X%A Jonathan A. Rees
X%A Paul Hudak
X%A James Philbin
X%A Norman I. Adams
X%T Orbit: An Optimizing Compiler for Scheme
X%J Proceedings of the SIGPLAN '86 Symposium on Compiler
XConstruction
X%P 219-233
X%I ACM
X%O Published as SIGPLAN Notices 21(7), July 1986
X%D June 1986
X%K orbit
X
X%A Marc Feeley
X%T Deux Approches a' L'implantation du Language Scheme
X%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
XOpe'rationelle, University of Montreal
X%D May 1986
X
X%A R. Kent Dybvig
X%T The Scheme Programming Language
X%I Prentice-Hall, Inc.
X%C Englewood Cliffs, New Jersey
X%D 1987
X%K splang
X
X%A Marc Feeley
X%A Guy LaPalme
X%T Using Cloures for Code Generation
X%J Journal of Computer Languages
X%V 12
X%N 1
X%P 47-66
X%I Pergamon Press
X%D 1987
X
X%A Matthias Felleisen
X%T Reflections on Landin's J-Operator: A Partly Historical Note
X%J Journal of Computer Languages
X%V 12
X%N 3/4
X%P 197-207
X%I Pergamon Press
X%D 1987
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%T A Reduction Semantics for Imperative Higher-Order Languages
X%J Parallel Architectures and Languages Europe
X%E De Bakker, Nijman and Treleaven
X%B Lecture Notes in Computer Science
X%V 259
X%I Springer-Verlag
X%C Berlin
X%P 206-223
X%D 1987
X
X%T A syntactic theory of sequential control
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%A Eugene E. Kohlbecker
X%A Bruce Duba
X%J Theoretical Computer Science
X%V 52
X%P 205-237
X%D 1987
X
X%A Daniel P. Friedman
X%A Matthias Felleisen
X%T The Little LISPer
X%I MIT Press
X%D 1987
X%O Trade Edition
X%K littlelisper
X
X%A Christopher T. Haynes
X%A Daniel P. Friedman
X%T Abstracting Timed Preemption with Engines
X%J Journal of Computer Languages
X%V 12
X%N 2
X%P 109-121
X%I Pergamon Press
X%D 1987
X
X%A Matthias Felleisen
X%T The Calculi of lambda-v-cs conversion: a syntactic
Xtheory of control and state in imperative higher-order programming
Xlanguages
X%R Computer Science Technical Report #226. (PhD Dissertation)
X%I Indiana University
X%C Bloomington, Indiana
X%D August 1987
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%A Bruce Duba
X%A John Merrill
X%T Beyond Continuations
X%R Computer Science Dept. Technical Report #216
X%I Indiana University
X%C Bloomington, Indiana
X%D February, 1987
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%T A calculus for assignments in higher-order languages
X%J Conference Record of the 14th Annual ACM Symposium on Principles of
XProgramming Languages
X%C Munich, West Germany
X%P 314-345
X%D January 1987
X
X%A Matthias Felleisen
X%A Daniel P. Friedman
X%T A Syntactic Theory of Sequential State
X%R Computer Science Dept. Technical Report #230
X%I Indiana University
X%C Bloomington, Indiana
X%D October 1987
X
X%T Embedding continuations in procedural objects
X%A Christopher T. Haynes
X%A Daniel P. Friedman
X%J ACM Transactions on Programming Languages and Systems
X%V 9
X%N 4
X%P 582-598
X%D October 1987
X
X%A Michael Eisenberg
X%T Programming In Scheme
X%E Harold Abelson
X%I Scientific Press
X%C Redwood City, CA
X%D 1988
X
X%A Mitchell Wand
X%A Daniel P. Friedman
X%T The Mystery of the Tower Revealed: A Non-Reflective
XDescription of the Reflective Tower
X%B Meta-Level Architectures and Reflection
X%E P. Maes and D. Nardi
X%I Elsevier Sci. Publishers B.V. (North Holland)
X%P 111-134
X%D 1988
X%O Also to appear in Lisp and Symbolic Computation
X
X%A Daniel P. Friedman
X%A Mitchell Wand
X%A Christopher T. Haynes
X%A Eugene E. Kohlbecker
X%T Programming Languages: Their Abstractions, Representations,
Xand Implementations
X%I M.I.T. Press and McGraw Hill
X%D 1988-1989
X%O in progress
X
X%A George Springer
X%A Daniel P. Friedman
X%T An Introduction to the Art of Programming in Scheme
X%D 1988-1989
X%O in progress
X
X%A Harold Abelson
X%A Gerald Jay Sussman
X%T Lisp: A Langauge for Stratified Design
X%J BYTE
X%D February 1988
X%P 207-218
X
X%A William Clinger
X%T Semantics of Scheme
X%J BYTE
X%D February 1988
X%P 221-227
X
X%A Alan Bawden
X%A Jonathan Rees
X%T Syntactic Closures
X%J Proceedings of the 1988 ACM Symposium on LISP
Xand Functional Programming
X%C Salt Lake City, Utah.
X%D July 1988
X
X%A Matthias Felleisen
X%A Mitchell Wand
X%A Daniel P. Friedman
X%A Bruce Duba
X%T Abstract Continuations: A Mathematical Semantics for
XHandling Functional Jumps
X%J Proceedings of the 1988 ACM Symposium on LISP
Xand Functional Programming
X%C Salt Lake City, Utah.
X%D July 1988
X
X%A John Franco
X%A Daniel P. Friedman
X%T Creating Efficient Programs by Exchanging Data for Procedures
X%R Computer Science Technical Report #245
X%I Indiana University
X%C Bloomington, Indiana
X%D March 1988
X
X%A Mitchell Wand
X%A Daniel P. Friedman
X%T Compiling lambda expressions using continuations and
Xfactorizations
X%J Computer Languages 3
X%D 241-263
X%D 1978
END_OF_FILE
if test 15607 -ne `wc -c <'scheme.bib'`; then
echo shar: \"'scheme.bib'\" unpacked with wrong size!
fi
# end of 'scheme.bib'
fi
if test -f 'scheme.bibtex' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'scheme.bibtex'\"
else
echo shar: Extracting \"'scheme.bibtex'\" \(20265 characters\)
sed "s/↑X//" >'scheme.bibtex' <<'END_OF_FILE'
X@article{key1,
X author = "John Reynolds",
X year = "1972",
X publisher = "ACM",
X journal = "ACM Conference Proceedings",
X pages = "717-740",
X title = "Definitional Interpreters for Higher Order Programming Languages"
X}
X
X@techreport{key2,
X author = "Gerald Jay Sussman and Guy Lewis Steele, Jr.",
X address = "Cambridge, Mass.",
X year = "December 1975",
X title = "Scheme: an Interpreter for Extended Lambda Calculus"
X}
X
X@techreport{imperative,
X author = "Guy Lewis Steele, Jr. and Gerald Jay Sussman",
X address = "Cambridge, Mass.",
X year = "March 1976",
X title = "Lambda, the Ultimate Imperative"
X}
X
X@techreport{declarative,
X author = "Guy Lewis Steele, Jr.",
X address = "Cambridge, Mass.",
X year = "November 1976",
X title = "Lambda, the Ultimate Declarative"
X}
X
X@article{key5,
X author = "Guy Lewis Steele, Jr.",
X year = "1977",
X publisher = "ACM",
X journal = "ACM Conference Proceedings",
X pages = "153-162",
X title = "Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call Implementations Considered Harmful, or LAMBDA, the Ultimate GOTO"
X}
X
X@article{key6,
X author = "Guy Lewis Steele, Jr.",
X year = "August 1977",
X journal = "Proceedings of the Symposium on Artificial Intelligence and Programming Languages",
X pages = "60-66",
X title = "Macaroni is Better than Spaghetti"
X}
X
X@article{key7,
X author = "Mitchell Wand",
X year = "1978",
X journal = "Journal of the ACM",
X number = "1",
X pages = "174-180",
X title = "Continuation-Based Program Transformation Strategies",
X volume = "27"
X}
X
X@techreport{key8,
X author = "Guy Lewis Steele, Jr. and Gerald Jay Sussman",
X address = "Cambridge, Mass.",
X year = "January 1978",
X title = "The Revised Report on Scheme, a Dialect of Lisp"
X}
X
X@techreport{key9,
X author = "Guy Lewis Steele, Jr.",
X address = "Cambridge, Mass.",
X year = "May 1978",
X title = "Rabbit: a Compiler for Scheme"
X}
X
X@techreport{modularity,
X author = "Guy Lewis Steele, Jr. and Gerald Jay Sussman",
X address = "Cambridge, Mass.",
X year = "May 1978",
X title = "The Art of the Interpreter, or the Modularity Complex (parts zero, one, and two)"
X}
X
X@article{key11,
X author = "Drew McDermott",
X year = "1980",
X publisher = "The Lisp Conference, P.O. Box 487, Redwood Estates CA.",
X journal = "Conference Record of the 1980 Lisp Conference",
X pages = "154-162",
X title = "An Efficient Environment Allocation Scheme in an Interpreter for a Lexically-Scoped Lisp"
X}
X
X@article{key12,
X author = "Steven S. Muchnick and Uwe F. Pleban",
X year = "1980",
X publisher = "The Lisp Conference, P.O. Box 487, Redwood Estates CA.",
X journal = "Conference Record of the 1980 Lisp Conference",
X pages = "56-65",
X title = "A Semantic Comparison of Lisp and Scheme"
X}
X
X@book{key13,
X author = "Guy Lewis Steele, Jr.",
X booktitle = "AI: An MIT Perspective",
X address = "Cambridge, Mass.",
X year = "1980",
X editor = "Patrick Henry Winston Richard Henry Brown",
X publisher = "MIT Press",
X title = "Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO"
X}
X
X@article{key14,
X author = "Guy Lewis Steele, Jr. and Gerald Jay Sussman",
X year = "1980",
X publisher = "The Lisp Conference",
X journal = "Conference Record of the 1980 Lisp Conference",
X pages = "163-172",
X title = "The Dream of a Lifetime: a Lazy Variable Extent Mechanism"
X}
X
X@article{key15,
X author = "Mitchell Wand",
X year = "1980",
X publisher = "The Lisp Conference",
X journal = "Conference Record of the 1980 Lisp Conference",
X pages = "19-28",
X title = "Continuation-Based Multiprocessing"
X}
X
X@article{key16,
X author = "Guy Lewis Steele, Jr. and Gerald Jay Sussman",
X year = "November 1980",
X journal = "CACM",
X number = "11",
X pages = "628-645",
X title = "Design of a Lisp-based Processor",
X volume = "23"
X}
X
X@article{key17,
X author = "Gerald Jay Sussman and Jack Holloway and Guy Lewis Steele, Jr. and Alan Bell",
X year = "July 1981",
X publisher = "IEEE",
X journal = "IEEE Computer",
X number = "7",
X pages = "10-21",
X title = "Scheme-79 - Lisp on a Chip",
X volume = "14"
X}
X
X@article{scheme81,
X author = "John Batali and Edmund Goodhue and Chris Hanson and Howie Shrobe and Richard M. Stallman and Gerald Jay Sussman",
X address = "Artech House, Dedham MA.",
X year = "1982",
X editor = "Paul Penfield, Jr.",
X journal = "Proceedings, Conference on Advanced Research in VLSI",
X pages = "69-77",
X title = "The Scheme-81 Architecture - System and Chip"
X}
X
X@article{key19,
X author = "Peter Henderson",
X year = "1982",
X journal = "Conference Record of the 1982 ACM Symposium on Lisp and Functional Programming",
X pages = "179-187",
X title = "Functional Geometry"
X}
X
X@article{key20,
X author = "Jonathan A. Rees and Norman I. Adams",
X year = "1982",
X journal = "Conference Record of the 1982 ACM Symposium on Lisp and Functional Programming",
X pages = "114-122",
X title = "T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool"
X}
X
X@book{key21,
X author = "Gerald Jay Sussman",
X booktitle = "Functional Programming and its Applications",
X address = "London",
X year = "1982",
X editor = "Darlington, Henderson, Turner",
X publisher = "Cambridge University Press",
X title = "LISP, Programming and Implementation"
X}
X
X@techreport{key22,
X author = "Pee Hong Chen and W.Y. Chi and E.M. Ost and L.D. Sabbagh and G. Springer",
X address = "Bloomington, Indiana",
X year = "August 1983",
X publisher = "Indiana University",
X title = "Scheme Graphics Reference Manual"
X}
X
X@techreport{key23,
X author = "Pee Hong Chen and Daniel P. Friedman",
X address = "Bloomington, Indiana",
X year = "August 1983",
X publisher = "Indiana University",
X title = "Prototyping data flow by translation into Scheme"
X}
X
X@techreport{key24,
X author = "Carol Fessenden and William Clinger and Daniel P. Friedman and Christopher T. Haynes",
X address = "Bloomington, Indiana",
X year = "February 1983",
X publisher = "Indiana University",
X title = "Scheme 311 version 4 Reference Manual"
X}
X
X@article{comp311,
X author = "William Clinger",
X year = "1984",
X journal = "Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming",
X pages = "356-364",
X title = "The Scheme 311 compiler: An Exercise in Denotational Semantics"
X}
X
X@book{key26,
X author = "Daniel P. Friedman and Christopher T. Haynes and Eugene E. Kohlbecker",
X booktitle = "Program Transformation and Programming Environments",
X year = "1984",
X editor = "P. Pepper",
X publisher = "Springer-Verlag",
X pages = "263-274",
X title = "Programming with Continuations"
X}
X
X@article{key27,
X author = "Christopher T. Haynes and Daniel P. Friedman",
X address = "Austin, TX.",
X year = "1984",
X journal = "Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming",
X pages = "18-24",
X title = "Engines Build Process Abstractions"
X}
X
X@article{key28,
X author = "Christopher T. Haynes and Daniel P. Friedman and Mitchell Wand",
X address = "Austin, TX.",
X year = "1984",
X journal = "Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming",
X pages = "293-298",
X title = "Continuations and Coroutines"
X}
X
X@article{key29,
X author = "Daniel P. Friedman and Mitchell Wand",
X address = "Austin, TX.",
X year = "August 1984",
X journal = "Conference Record of the 1984 ACM Symposium on LISP and Functional Programming",
X pages = "348-355",
X title = "Reification: reflection without metaphysics"
X}
X
X@book{key30,
X author = "Jonathan A. Rees and Norman I. Adams and James R. Meehan",
X year = "January 1984",
X publisher = "Yale University Computer Science Department",
X title = "The T manual, fourth edition"
X}
X
X@book{key31,
X author = "Guillermo J. Rozas",
X year = "January 1984",
X publisher = "S. B. Thesis, MIT Department of Electrical Engineering and Computer Science",
X title = "Liar, an Algol-like Compiler for Scheme"
X}
X
X@book{key32,
X address = "Cambridge, Mass.",
X year = "September 1984",
X publisher = "Department of Electrical Engineering and Computer Science, MIT",
X title = "MIT Scheme Manual, Seventh Edition"
X}
X
X@book{key33,
X address = "Sausalito, Calif.",
X year = "1985",
X publisher = "Semantic Microsystems",
X title = "MacScheme Reference Manual"
X}
X
X@book{sicp,
X author = "Harold Abelson and Gerald Jay Sussman and Julie Sussman",
X address = "Cambridge, Mass.",
X year = "1985",
X publisher = "MIT Press",
X title = "Structure and Interpretation of Computer Programs"
X}
X
X@book{key35,
X author = "William Clinger and Daniel P. Friedman and Mitchell Wand",
X booktitle = "Algebraic Methods in Semantics",
X address = "London",
X year = "1985",
X editor = "J. Reynolds, M. Nivat",
X publisher = "Cambridge University Press",
X pages = "237-250",
X title = "A Scheme for a Higher-Level Semantic Algebra"
X}
X
X@article{key36,
X author = "Amitabh Srivastava and Don Oxley and Aditya Srivastava",
X year = "1985",
X publisher = "IEEE",
X journal = "Proceedings of the Symposium on Logic Programming",
X pages = "254-260",
X title = "An (other) Integration of Logic and Functional Programming"
X}
X
X@techreport{rrrs,
X address = "Cambridge, Mass.",
X year = "August 1985",
X editor = "William Clinger",
X title = "The Revised Revised Report on Scheme, or An Uncommon Lisp"
X}
X
X@article{key38,
X author = "Daniel P. Friedman and Christopher T. Haynes",
X address = "New Orleans, LA.",
X year = "January 1985",
X publisher = "ACM",
X journal = "Proceedings of the Twelfth Annual Symposium on Principles of Programming Languages",
X pages = "245-254",
X title = "Constraining Control"
X}
X
X@techreport{scheme84,
X author = "Daniel P. Friedman and Christopher T. Haynes and Eugene E. Kohlbecker and Mitchell Wand",
X address = "Bloomington, Indiana",
X year = "January 1985",
X publisher = "Indiana University",
X title = "Scheme 84 Interim Reference Manual"
X}
X
X@techreport{key40,
X author = "Peehong Chen and L. David Sabbagh",
X address = "Bloomington, Indiana",
X year = "March 1985",
X publisher = "Indiana University",
X title = "Scheme as an Interactive Graphics Programming Environment"
X}
X
X@book{key41,
X year = "November 1985",
X publisher = "Texas Instruments, Inc.",
X title = "TI Scheme Language Reference Manual"
X}
X
X@techreport{bochser,
X author = "Michael A. Eisenberg",
X address = "Cambridge, Mass.",
X year = "October 1985",
X title = "Bochser: An Integrated Scheme Programming System"
X}
X
X@techreport{key43,
X author = "Matthias Felleisen",
X address = "Bloomington, Indiana",
X year = "October 1985",
X publisher = "Indiana University",
X title = "Transliterating Prolog into Scheme"
X}
X
X@article{pcscheme,
X author = "David H. Bartley and John C. Jensen",
X year = "1986",
X journal = "Proceedings of the 1986 ACM Conference on Lisp and Functional Programming",
X pages = "86-93",
X title = "The Implementation of PC Scheme"
X}
X
X@article{key45,
X author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes",
X year = "1986",
X journal = "Proceedings of the 1986 ACM Conference on Lisp and Functional Programming",
X pages = "143-150",
X title = "Expansion-Passing style: Beyond Conventional Macros"
X}
X
X@misc{key46,
X author = "Marc Feeley and Guy LaPalme",
X year = "1986",
X title = "Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE"
X}
X
X@article{key47,
X author = "Matthias Felleisen and Daniel P. Friedman",
X year = "1986",
X publisher = "Pergamon Press",
X journal = "Journal of Computer Languages",
X number = "1",
X pages = "29-37",
X title = "A Closer Look At Export and Import Statements",
X volume = "11"
X}
X
X@book{key48,
X author = "Daniel P. Friedman and Matthias Felleisen",
X address = "Palo Alto, California",
X year = "1986",
X publisher = "Science Research Associates, Inc.",
X title = "The Little LISPer: Second Edition"
X}
X
X@article{key49,
X author = "Christopher T. Haynes and Daniel P. Friedman and Mitchell Wand",
X year = "1986",
X publisher = "Pergamon Press",
X journal = "Journal of Computer Languages",
X number = "3/4",
X pages = "143-153",
X title = "Obtaining Coroutines With Continuations",
X volume = "11"
X}
X
X@article{key50,
X author = "Mitchell Wand",
X address = "St. Peterburg, Fla.",
X year = "1986",
X publisher = "ACM",
X journal = "Conference Record of the Thirteenth Annual Symposium on Principles of Programming Languages",
X pages = "38-43",
X title = "Finding the Source of Type Errors"
X}
X
X@book{key51,
X author = "Mitchell Wand",
X booktitle = "Programs as Data Objects",
X year = "1986",
X publisher = "Springer-Verlag Lecture Notes",
X title = "From Interpreter to Compiler: A Representational Derivation"
X}
X
X@article{key52,
X author = "Matthias Felleisen and Daniel P. Friedman",
X address = "Ebberup, Denmark",
X year = "August 1986",
X journal = "3rd Working Conference on the Formal Description of Programming Concepts",
X pages = "193-219",
X title = "Control operators, the SECD-machine, and the lambda-calculus"
X}
X
X@techreport{key53,
X author = "Eugene E. Kohlbecker",
X address = "Bloomington, Indiana",
X year = "August 1986",
X publisher = "Indiana University",
X title = "Syntactic Extensions in the Programming Language Lisp"
X}
X
X@article{key54,
X author = "Eugene E. Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba",
X year = "August 1986",
X journal = "Symposium on LISP and Functional Programming",
X pages = "151-161",
X title = "Hygienic macro expansion"
X}
X
X@article{key55,
X author = "Mitchell Wand",
X year = "August 1986",
X journal = "Proceedings of the 1986 ACM Symposium on LISP and Functional Programming",
X pages = "298-307",
X title = "The mystery of the tower revealed: a non-reflective description of the reflective tower"
X}
X
X@article{key56,
X year = "December 1986",
X editor = "Jonathan A. Rees William Clinger",
X journal = "ACM Sigplan Notices",
X number = "12",
X title = "Revised↑3 Report on the Algorithmic Language Scheme",
X volume = "21"
X}
X
X@article{key57,
X author = "Christopher T. Haynes",
X year = "Jul 1986",
X publisher = "Springer-Verlag",
X journal = "Proceedings of the Third International Conference on Logic Programming",
X pages = "671-685",
X title = "Logic Continuations"
X}
X
X@article{key58,
X author = "Matthias Felleisen and Daniel P. Friedman and Eugene E. Kohlbecker and Bruce Duba",
X address = "Washigton DC",
X year = "June 1986",
X publisher = "IEEE Computer Society Press",
X journal = "Proceedings of the Symposium on Logic in Computer Science",
X pages = "131-141",
X title = "Reasoning with Continuations"
X}
X
X@article{orbit,
X author = "David Kranz and Richard Kelsey and Jonathan A. Rees and Paul Hudak and James Philbin and Norman I. Adams",
X year = "June 1986",
X publisher = "ACM",
X journal = "Proceedings of the SIGPLAN '86 Symposium on Compiler Construction",
X pages = "219-233",
X title = "Orbit: An Optimizing Compiler for Scheme"
X}
X
X@book{key60,
X author = "Marc Feeley",
X year = "May 1986",
X publisher = "M.Sc. Thesis, De'partement d'Informatique et de Recherche Ope'rationelle, University of Montreal",
X title = "Deux Approches a' L'implantation du Language Scheme"
X}
X
X@book{splang,
X author = "R. Kent Dybvig",
X address = "Englewood Cliffs, New Jersey",
X year = "1987",
X publisher = "Prentice-Hall, Inc.",
X title = "The Scheme Programming Language"
X}
X
X@article{key62,
X author = "Marc Feeley and Guy LaPalme",
X year = "1987",
X publisher = "Pergamon Press",
X journal = "Journal of Computer Languages",
X number = "1",
X pages = "47-66",
X title = "Using Cloures for Code Generation",
X volume = "12"
X}
X
X@article{key63,
X author = "Matthias Felleisen",
X year = "1987",
X publisher = "Pergamon Press",
X journal = "Journal of Computer Languages",
X number = "3/4",
X pages = "197-207",
X title = "Reflections on Landin's J-Operator: A Partly Historical Note",
X volume = "12"
X}
X
X@article{key64,
X author = "Matthias Felleisen and Daniel P. Friedman",
X booktitle = "Lecture Notes in Computer Science",
X address = "Berlin",
X year = "1987",
X editor = "De Bakker, Nijman and Treleaven",
X publisher = "Springer-Verlag",
X journal = "Parallel Architectures and Languages Europe",
X pages = "206-223",
X title = "A Reduction Semantics for Imperative Higher-Order Languages",
X volume = "259"
X}
X
X@article{key65,
X author = "Matthias Felleisen and Daniel P. Friedman and Eugene E. Kohlbecker and Bruce Duba",
X year = "1987",
X journal = "Theoretical Computer Science",
X pages = "205-237",
X title = "A syntactic theory of sequential control",
X volume = "52"
X}
X
X@book{littlelisper,
X author = "Daniel P. Friedman and Matthias Felleisen",
X year = "1987",
X publisher = "MIT Press",
X title = "The Little LISPer"
X}
X
X@article{key67,
X author = "Christopher T. Haynes and Daniel P. Friedman",
X year = "1987",
X publisher = "Pergamon Press",
X journal = "Journal of Computer Languages",
X number = "2",
X pages = "109-121",
X title = "Abstracting Timed Preemption with Engines",
X volume = "12"
X}
X
X@techreport{key68,
X author = "Matthias Felleisen",
X address = "Bloomington, Indiana",
X year = "August 1987",
X publisher = "Indiana University",
X title = "The Calculi of lambda-v-cs conversion: a syntactic theory of control and state in imperative higher-order programming languages"
X}
X
X@techreport{key69,
X author = "Matthias Felleisen and Daniel P. Friedman and Bruce Duba and John Merrill",
X address = "Bloomington, Indiana",
X year = "February, 1987",
X publisher = "Indiana University",
X title = "Beyond Continuations"
X}
X
X@article{key70,
X author = "Matthias Felleisen and Daniel P. Friedman",
X address = "Munich, West Germany",
X year = "January 1987",
X journal = "Conference Record of the 14th Annual ACM Symposium on Principles of Programming Languages",
X pages = "314-345",
X title = "A calculus for assignments in higher-order languages"
X}
X
X@techreport{key71,
X author = "Matthias Felleisen and Daniel P. Friedman",
X address = "Bloomington, Indiana",
X year = "October 1987",
X publisher = "Indiana University",
X title = "A Syntactic Theory of Sequential State"
X}
X
X@article{key72,
X author = "Christopher T. Haynes and Daniel P. Friedman",
X year = "October 1987",
X journal = "ACM Transactions on Programming Languages and Systems",
X number = "4",
X pages = "582-598",
X title = "Embedding continuations in procedural objects",
X volume = "9"
X}
X
X@book{key73,
X author = "Michael Eisenberg",
X address = "Redwood City, CA",
X year = "1988",
X editor = "Harold Abelson",
X publisher = "Scientific Press",
X title = "Programming In Scheme"
X}
X
X@book{key74,
X author = "Mitchell Wand and Daniel P. Friedman",
X booktitle = "Meta-Level Architectures and Reflection",
X year = "1988",
X editor = "P. Maes and D. Nardi",
X publisher = "Elsevier Sci. Publishers B.V. (North Holland)",
X pages = "111-134",
X title = "The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower"
X}
X
X@book{key75,
X author = "Daniel P. Friedman and Mitchell Wand and Christopher T. Haynes and Eugene E. Kohlbecker",
X year = "1988-1989",
X publisher = "M.I.T. Press and McGraw Hill",
X title = "Programming Languages: Their Abstractions, Representations, and Implementations"
X}
X
X@misc{key76,
X author = "George Springer and Daniel P. Friedman",
X year = "1988-1989",
X title = "An Introduction to the Art of Programming in Scheme"
X}
X
X@article{key77,
X author = "Harold Abelson and Gerald Jay Sussman",
X year = "February 1988",
X journal = "BYTE",
X pages = "207-218",
X title = "Lisp: A Langauge for Stratified Design"
X}
X
X@article{key78,
X author = "William Clinger",
X year = "February 1988",
X journal = "BYTE",
X pages = "221-227",
X title = "Semantics of Scheme"
X}
X
X@article{key79,
X author = "Alan Bawden and Jonathan Rees",
X address = "Salt Lake City, Utah.",
X year = "July 1988",
X journal = "Proceedings of the 1988 ACM Symposium on LISP and Functional Programming",
X title = "Syntactic Closures"
X}
X
X@article{key80,
X author = "Matthias Felleisen and Mitchell Wand and Daniel P. Friedman and Bruce Duba",
X address = "Salt Lake City, Utah.",
X year = "July 1988",
X journal = "Proceedings of the 1988 ACM Symposium on LISP and Functional Programming",
X title = "Abstract Continuations: A Mathematical Semantics for Handling Functional Jumps"
X}
X
X@techreport{key81,
X author = "John Franco and Daniel P. Friedman",
X address = "Bloomington, Indiana",
X year = "March 1988",
X publisher = "Indiana University",
X title = "Creating Efficient Programs by Exchanging Data for Procedures"
X}
X
X@article{key82,
X author = "Mitchell Wand and Daniel P. Friedman",
X year = "241-263 1978",
X journal = "Computer Languages 3",
X title = "Compiling lambda expressions using continuations and factorizations"
X}
X
END_OF_FILE
if test 20265 -ne `wc -c <'scheme.bibtex'`; then
echo shar: \"'scheme.bibtex'\" unpacked with wrong size!
fi
# end of 'scheme.bibtex'
fi
echo shar: End of shell archive.
exit 0
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂19-Aug-88 0335 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme biblio. (acknowledgements)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Aug 88 03:35:22 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Aug 88 06:29:49 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA05816@BLOOM-BEACON.MIT.EDU>; Fri, 19 Aug 88 06:22:16 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Aug 88 03:15:22 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme biblio. (acknowledgements)
Message-Id: <844@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In my previous posting, I forgot to acknowledge the contributions
of Ken Dickey, Dan Friedman and Mark MacLennan. Also forgot to mention
that the core of the bibliography was shamelessy snarfed [months ago]
from R↑3 Report on Scheme.
Many thnx. Looking forward to additional contributions: Tech Reports,
Articles, Implementation Descriptions, whatever. Scheme all the way.
oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂20-Aug-88 0350 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Rabbit report. (NTIS)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Aug 88 03:50:15 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 20 Aug 88 06:45:36 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA07576@BLOOM-BEACON.MIT.EDU>; Sat, 20 Aug 88 06:39:30 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Aug 88 17:18:00 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Re: Rabbit report. (NTIS)
Message-Id: <847@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Many thanks to those who have responded to my query. I decided
to order it from NTIS, as it would have been just as costly
to have someone else photocopy their own report and mail it to
me. In case others are interested, here is the info:
NTIS# : ADA061996 PHONE : (703) 487 4650
COST : 25.00 (paper copy)
PAGES : 276
%A Guy Lewis Steele, Jr.
%T Rabbit: a Compiler for Scheme
%R MIT Artificial Intelligence Laboratory Technical Report 474
%C Cambridge, Mass.
%D May 1978
oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂22-Aug-88 1135 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Bibliography (Aug. 1988)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 11:35:51 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 22 Aug 88 14:30:59 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Mon, 22 Aug 88 14:30:09 EDT
Received: by joplin.think.com; Mon, 22 Aug 88 14:29:52 EDT
Date: Mon, 22 Aug 88 14:29:52 EDT
From: gls@Think.COM
Message-Id: <8808221829.AA03276@joplin.think.com>
To: attcan!utzoo!yunexus!oz@uunet.uu.net
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Ozan Yigit's message of 16 Aug 88 22:01:38 GMT <842@yunexus.UUCP>
Subject: Scheme Bibliography (Aug. 1988)
This is a wonderful resource! Thank you for your efforts.
However, there is a bug. I spell my name with no comma before
the "Jr.". (Leslie Lamport cites this fact in the LaTeX manual,
page 142. Unfortunately his solution to the problem is incorrect.
The correct inverted form is "Steele, Guy L., Jr." and not
"Steele Jr., Guy L.")
--Guy
∂22-Aug-88 1622 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Snowbird minutes?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 16:22:06 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 22 Aug 88 19:10:05 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 AUG 88 15:54:05 PDT
Date: Mon, 22 Aug 88 15:54:04 PDT
From: Pavel.pa@Xerox.COM
Subject: Snowbird minutes?
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880822-155405-1202@Xerox>
Well, it's been almost a month since the meeting in Utah and I'm still in the
dark about what took place (other than a note from Guy, I think, saying
something about what was decided concerning macros). Could someone please send
out a description of what was decided about everything else? A lot of radical
stuff was on that agenda and I'd really like to know the directions in which my
implementation should be moving to maintain adherence to the agreed-upon
language.
Thanks,
Pavel
∂22-Aug-88 2107 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Parallel Scheme(Lisp) on Sequent
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 21:07:07 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Aug 88 23:57:11 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA00208@BLOOM-BEACON.MIT.EDU>; Mon, 22 Aug 88 23:54:52 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Aug 88 02:01:10 GMT
From: lee@louie.udel.edu (Hong Ryul Lee)
Organization: University of Delaware
Subject: Parallel Scheme(Lisp) on Sequent
Message-Id: <3791@louie.udel.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
We are trying to install MIT 'fscheme' on the Sequent parallel processor
to run LISP programs.
If someone has already been using 'fscheme' or any other parallel LISP on
Sequent, we would like to receive some information.
Or if on going of installation, we would like to exchange informations.
Also if you know anyone working parallel Lisp on Sequent, please let me know
his/her name and address.
Hong Lee (lee@louie.udel.edu)
Dept of Computer Science
University of Delaware
∂23-Aug-88 0808 SCHREQ@MC.LCS.MIT.EDU info-cscheme-request
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88 08:08:39 PDT
Date: Tue, 23 Aug 88 11:02:34 EDT
From: Scheme Requestee <SCHREQ@MC.LCS.MIT.EDU>
Subject: info-cscheme-request
To: SCHEME@MC.LCS.MIT.EDU
Message-ID: <470902.880823.SCHREQ@MC.LCS.MIT.EDU>
Date: Mon, 15 Aug 88 11:06:19 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
To: scheme-request@mc.lcs.mit.edu
Re: Periodic noise message; list policy reiterated
To be added to info-cscheme, send mail to
info-cscheme-request@zurich.ai.mit.edu
not
info-cscheme-maintainer@zurich.ai.mit.edu
The latter address bounces back. You should update your general
information message.
∂24-Aug-88 0731 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 07:31:31 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 24 Aug 88 10:28:45 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA05911; Wed, 24 Aug 88 09:01:52 EDT
Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA24779; Wed, 24 Aug 88 09:02:34 EDT
Date: Wed, 24 Aug 88 09:02:34 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8808241302.AA24779@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let -> ???
Was there any agreement reached on the new name for named let?
John
∂24-Aug-88 0951 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 09:51:26 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 24 Aug 88 12:48:32 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Wed, 24 Aug 88 12:47:10 EDT
Received: by joplin.think.com; Wed, 24 Aug 88 12:47:18 EDT
Date: Wed, 24 Aug 88 12:47:18 EDT
From: gls@Think.COM
Message-Id: <8808241647.AA04415@joplin.think.com>
To: ramsdell%linus@mitre-bedford.arpa
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.arpa's message of Wed, 24 Aug 88 09:02:34 EDT <8808241302.AA24779@huxley.sun.uucp>
Subject: named let -> ???
Posted-From: The MITRE Corp., Bedford, MA
Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
Date: Wed, 24 Aug 88 09:02:34 EDT
From: ramsdell%linus@mitre-bedford.arpa
Was there any agreement reached on the new name for named let?
John
The name "reclet" occurred to me at Snowbird, and Dan Friedman
informed me that I wasn't the first to think of it.
--Guy
∂24-Aug-88 1416 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 14:16:37 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Aug 88 17:14:03 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Wed, 24 Aug 88 14:50:28 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: gls@THINK.COM
Subject: Re: named let -> ???
Cc: rrrs-authors@mc.lcs.mit.edu
This is the first I rememeber hearing of "reclet", and I like it.
∂24-Aug-88 1454 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Named LET -> RECLET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 14:54:51 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 AUG 88 17:38:03 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA05200@VX.LCS.MIT.EDU>; Wed, 24 Aug 88 17:46:34 edt
Date: Wed, 24 Aug 88 17:46:34 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Named LET -> RECLET
Doesn't this generate confusion? LETREC vs RECLET?
Why not something like ITERLET or just ILET to suggest
that named LET is used for iteration rather than more
general recursion (for which LETREC is used)?
~Ziggy
∂24-Aug-88 1612 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 16:12:13 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Aug 88 18:39:56 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 15:14:58 PDT
Date: Wed, 24 Aug 88 14:55:42 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: named let -> ???
In-reply-to: "dyb@iuvax.cs.indiana.edu's message of Wed, 24 Aug 88 14:50:28 EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880824-151458-2690@Xerox>
Before this looks too much like concensus, I don't like the name ``reclet'' at
all and am perfectly happy with it being a special case of the LET syntax.
``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
great difference in semantics. I can't see how the average newcomer to the
language is going to be able to keep them straight.
Why are folks so keen on changing the name?
Pavel
∂24-Aug-88 1703 @MC.LCS.MIT.EDU:markf@montreux Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 17:02:55 PDT
Received: from montreux (TCP 2212600364) by MC.LCS.MIT.EDU 24 Aug 88 17:36:01 EDT
Received: by MONTREUX.AI.MIT.EDU; Wed, 24 Aug 88 17:33:10 edt
Message-Id: <8808242133.AA20669@montreux>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: named let -> ???
Date: Wed, 24 Aug 88 17:33:07 -0400
From: markf@montreux
--------
How about letloop. Sure would minimize changes to existing
programs :-)
∂24-Aug-88 1703 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 17:03:13 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 24 Aug 88 18:09:34 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 88 14:58:56 PDT
Date: Wed, 24 Aug 88 14:55:42 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: named let -> ???
In-reply-to: "dyb@iuvax.cs.indiana.edu's message of Wed, 24 Aug 88 14:50:28 EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880824-145856-2650@Xerox>
Before this looks too much like concensus, I don't like the name ``reclet'' at
all and am perfectly happy with it being a special case of the LET syntax.
``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
great difference in semantics. I can't see how the average newcomer to the
language is going to be able to keep them straight.
Why are folks so keen on changing the name?
Pavel
∂24-Aug-88 1750 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 17:50:11 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 24 Aug 88 20:40:45 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Wed, 24 Aug 88 19:38:52 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: Pavel.pa@XEROX.COM, rrrs-authors@mc.lcs.mit.edu
Subject: Re: named let -> ???
> Why are folks so keen on changing the name?
>
> Pavel
The use of "let" with a special syntax has proven to cause problems
for us in teaching Scheme at the introductory level, and it also makes
it more difficult to scan a program for its control structures. We
have found that students have trouble understanding the similarities
between "let" and named "let"; we had no such trouble with "recur".
While I certainly prefer the name "recur" to either "reclet" or named
"let", I understand that some people do not like the name "recur",
because it implies that the construct is used solely for recursion
(the fact that iteration is a special case of recursion notwithstanding).
I suppose they will dislike "reclet" for the same reason, but if not,
I would be happier with "reclet" than with named "let".
∂24-Aug-88 1933 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Named LET -> RECLET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 19:32:54 PDT
Received: from chamartin (TCP 2206400253) by MC.LCS.MIT.EDU 24 Aug 88 22:28:48 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Wed, 24 Aug 88 22:29:18 edt
Date: Wed, 24 Aug 88 22:29:18 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8808250229.AA06590@chamartin>
To: ziggy@VX.LCS.MIT.EDU
Cc: rrrs-authors@mc
In-Reply-To: Michael R. Blair's message of Wed, 24 Aug 88 17:46:34 edt
Subject: Named LET -> RECLET
Doesn't this generate confusion? LETREC vs RECLET?
Why not something like ITERLET or just ILET to suggest
that named LET is used for iteration rather than more
general recursion (for which LETREC is used)?
I for one use it for general recursion, so any connotation of
iteration seems wrong to me. This is the reason the original ITERATE
was renamed.
∂25-Aug-88 0817 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 08:17:44 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 25 Aug 88 11:15:19 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Thu, 25 Aug 88 11:13:19 EDT
Received: by joplin.think.com; Thu, 25 Aug 88 11:13:49 EDT
Date: Thu, 25 Aug 88 11:13:49 EDT
From: gls@Think.COM
Message-Id: <8808251513.AA04983@joplin.think.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 24 Aug 88 14:55:42 PDT <880824-151458-2690@Xerox>
Subject: named let -> ???
Date: Wed, 24 Aug 88 14:55:42 PDT
From: Pavel.pa@xerox.com
Before this looks too much like concensus, I don't like the name ``reclet'' at
all and am perfectly happy with it being a special case of the LET syntax.
``reclet'' doesn't sound different enough from ``letrec'' to accomodate the
great difference in semantics. I can't see how the average newcomer to the
language is going to be able to keep them straight.
Well, I worried about this a bit before proposing it. A (very weak)
defense is that the C folks seem to get along having two library functions
names "modf" and "fmod" that do similar but distinct things. Yuk.
--Guy
∂25-Aug-88 0835 @MC.LCS.MIT.EDU:bartley@mips.csc.ti.com named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 08:35:23 PDT
Received: from ti.com (TCP 1201600056) by MC.LCS.MIT.EDU 25 Aug 88 11:20:33 EDT
Received: by ti.com id AA04999; Thu, 25 Aug 88 10:19:15 CDT
Received: from mips by tilde id AA14066; Thu, 25 Aug 88 10:08:02 CDT
Received: by mips id AA19443; Thu, 25 Aug 88 10:07:54 CDT
Date: Thu, 25 Aug 88 10:07:54 CDT
From: David Bartley <bartley@mips.csc.ti.com>
Message-Id: <8808251507.AA19443@mips>
To: dyb@iuvax.cs.indiana.edu
Cc: Pavel.pa@XEROX.COM, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "R. Kent Dybvig"'s message of Wed, 24 Aug 88 19:38:52 EST <8808250147.AA01590@tilde>
Subject: named let -> ???
>Date: Wed, 24 Aug 88 19:38:52 EST
>From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
> [...]
>The use of "let" with a special syntax has proven to cause problems
>for us in teaching Scheme at the introductory level, and it also makes
>it more difficult to scan a program for its control structures. We
>have found that students have trouble understanding the similarities
>between "let" and named "let"; we had no such trouble with "recur".
>
>While I certainly prefer the name "recur" to either "reclet" or named
>"let", I understand that some people do not like the name "recur",
>because it implies that the construct is used solely for recursion
>(the fact that iteration is a special case of recursion notwithstanding).
>I suppose they will dislike "reclet" for the same reason, but if not,
>I would be happier with "reclet" than with named "let".
I hope you weren't thinking of me when you mentioned "some people,"
since I don't deny that giving the LET a name only makes sense if
recursion is going to take place. However, I do have two objections
to the name RECUR.
(1) Named LET is both a binding construct and a control construct (and
thus is similar to LAMBDA). As you are reading along in the program,
the first action is to bind some variables and start executing a body,
just like LET. Thus, I see it as a binding construct primarily, and a
control construct secondarily. (Incidentally, this is why I preferred
the keyword LABEL over REC back when that construct existed.)
(2) I associate the verb "recur" with the action of calling a
procedure recursively, not with the action of creating the procedure
to be called. Putting the keyword RECUR in place of LET is like
putting the word GOTO in front of every labelled Fortran statement.
I'll be happy with any choice of a keyword that doesn't overly
de-emphasize the binding aspects of the construct and doesn't misplace
a perfectly good verb. LET suits me just fine.
--db--
∂25-Aug-88 0901 @MC.LCS.MIT.EDU,@STONY-BROOK.SCRC.Symbolics.COM,@GRYPHON.SCRC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 09:00:57 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 25 Aug 88 11:45:22 EDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 450512; 25 Aug 88 11:44:13 EDT
Date: Thu, 25 Aug 88 11:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: named let -> ???
To: Pavel.PA@Xerox.COM
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: <880824-151458-2690@Xerox>
Message-ID: <880825114357.0.KMP@GRYPHON.SCRC.Symbolics.COM>
I briefly worried that if you introduced a name like reclet, that someone
would eventually come asking for recletrec, but I guess it's clear that
such a primitive would be meaningless. Phew...
Anyway, I agree with Pavel that special syntax is better than a new name
in this case.
∂25-Aug-88 0917 @MC.LCS.MIT.EDU:markf@montreux named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 09:16:58 PDT
Received: from montreux (TCP 2212600364) by MC.LCS.MIT.EDU 25 Aug 88 11:55:19 EDT
Received: by MONTREUX.AI.MIT.EDU; Thu, 25 Aug 88 11:52:25 edt
Message-Id: <8808251552.AA21115@montreux>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let -> ???
Reply-To: markf@zurich.ai.mit.edu
Date: Thu, 25 Aug 88 11:52:18 -0400
From: markf@montreux
As David Bartley said, named let is both a binding constuct (like
let) and a control construct (like lambda), so how about lambda-let
(or let-lambda).
∂25-Aug-88 0930 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu named-let proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 09:30:42 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 25 Aug 88 11:58:57 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Thu, 25 Aug 88 10:57:09 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named-let proposal
As the user community continues to grow at its current pace
it is emcumbent on us to recognize that many universities will
be teaching Scheme to undergraduates. Dan Friedman and I have
been grappling with what we should do about the named let problem.
Students at Indiana University are quite confused about named
let as they are taught to understand let as a binding construct
having nothing to do with recursion. One of the good things about
Scheme is that it is in the process of removing puns from LISP.
Now, we need to remove a pun from Scheme. The feeling that I
got from the meeting is that we don't want to lose two aspects of
the operation. The first is that it creates a recursive definition
and the second is that it does binding like let. The suggestion
by Guy to introduce reclet was good because it satisfied both these
concerns, on the otherhand some were upset because it seemed to close
to letrec. So, I will suggest bindrec. It has both aspects and
seems easy to say. My concern is that pedagogically, named let
in the presence of unnamed let is a disaster and since I am writing
a book for freshman and would like some way of doing named let the
time has come to resolve this issue.
... George Springer
∂25-Aug-88 0948 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 09:48:15 PDT
Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 25 Aug 88 12:29:02 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 25 Aug 88 12:28:50 edt
Date: Thu, 25 Aug 88 12:28:50 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8808251628.AA15067@dumbo>
To: bartley@mips.csc.ti.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: David Bartley's message of Thu, 25 Aug 88 10:07:54 CDT <8808251507.AA19443@mips>
Subject: named let -> ???
Reply-To: arthur%zurich@mc.lcs.mit.edu
LET suits me just fine, too. Named LET is purely a binding construct; it is
only special because a name gets bound to the LAMBDA which is the LET. Thus,
you are naming the let. If the name does change, why not NAMED-LET ? But I'd
rather name named LET LET.
Arthur
∂25-Aug-88 1040 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 10:40:50 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 25 Aug 88 13:38:18 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Thu, 25 Aug 88 12:11:28 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: KMP@SCRC-STONY-BROOK.ARPA, Pavel.PA@XEROX.COM
Subject: Re: named let -> ???
Cc: RRRS-Authors@mc.lcs.mit.edu
> I briefly worried that if you introduced a name like reclet, that someone
> would eventually come asking for recletrec, but I guess it's clear that
> such a primitive would be meaningless. Phew...
>
> Anyway, I agree with Pavel that special syntax is better than a new name
> in this case.
This reminds me of the name I almost suggested, "let+". (The body of
the expression is executed at least once and possibly many times.) I
also worried about names like "letrec+", and worse, "let*+" (or was
that "let+*"?). If we could agree to flush "let*"...
∂25-Aug-88 1239 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU Yet more Named Let flamage
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 12:39:09 PDT
Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 25 Aug 88 15:35:49 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 25 Aug 88 15:35:44 edt
Date: Thu, 25 Aug 88 15:35:44 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8808251935.AA15159@dumbo>
To: rrrs-authors@mc
Subject: Yet more Named Let flamage
Reply-To: arthur%zurich@mc.lcs.mit.edu
Why don't we just wait until the Macros Committee decides what the standard
Scheme macro syntax will be, and then everyone can write a macro to name named
LET whatever they like? Point being: why waste so many computrons choosing a
name for something which already has one?
Arthur
∂25-Aug-88 1301 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: named LET -> RECLET
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 13:01:36 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Aug 88 15:38:44 EDT
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 25 Aug 88 15:38-EDT
Message-Id: <2797529834-15567018@RTS-8>
Sender: ziggy@RTS-8
Date: Thu, 25 Aug 88 15:37:14 EDT
From: Ziggy@VX
To: rrrs-authors@mc
Subject: Re: named LET -> RECLET
If NAMED-LET is too long, why not NLET ? LETWRETCH ?
∂25-Aug-88 1741 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Summarizing the named-let debate
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 17:41:42 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 25 Aug 88 20:32:18 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 25 AUG 88 17:21:18 PDT
Date: Thu, 25 Aug 88 17:21:10 PDT
From: Pavel.pa@Xerox.COM
Subject: Summarizing the named-let debate
To: RRRS-Authors@MC.LCS.MIT.Edu
Message-ID: <880825-172118-5155@Xerox>
My responses to today's rash of suggestions on this debate:
I agree with Guy; his defense of the name ``reclet'' (that C programmers seems
to get along with the names ``fmod'' and ``modf'') is pretty weak stuff. Yuk,
indeed.
I found David Bartlett's arguments, concerning ``let'' being a binding
construct, very convincing. I think that Arthur Gleckler made the completing
point of this argument, though, when he pointed out that the named variety of
let is also purely a binding form; it simply gives a name to one more thing than
an unnamed one.
If one simply must change the name, then I also support Arthur's suggestion
there: ``named-let''.
I don't like MarkF's names, ``lambda-let'' (or ``let-lambda'') since I see no
mnemonic value in these. ``lambda'' is not the only control construct in
Scheme, so it is not a good representative for all control notions.
George Springer's idea to use ``bindlet'' seems wrong to me as well, since
``bind'' and ``let'' feel almost like synonyms to me.
The main argument for any change at all, however, seems to come from educators,
who claim that the idea of adding recursion to a purely binding form is odd to
students. This claim seems odd to me. What can be so hard about ``let'' being
an abbreviation for
((lambda bvl . body) . args)
and named ``let'' simply adding one more binding into the expansion:
((rec name (lambda bvl . body)) . args)
I'm not saying that these claims of pedagogical difficulty are false, just that
I don't yet understand the details of the problem. Could one of the educators
(George? Kent?) please explain further just what the problem is? It just seems
that exploiting the close correspondence above should work well to make the idea
clear.
Until I can understand the difficulty better, I am forced to continue my support
of the current named ``let'' syntax.
Pavel
∂25-Aug-88 2350 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Clarification on named let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Aug 88 23:50:21 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 26 Aug 88 01:11:27 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Fri, 26 Aug 88 00:09:37 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Clarification on named let
I guess there is a general confusion about why "let" as it is currently
defined is irrational and unbecoming a language which has taken great
pains to be as clear and simple as possible. For those who may have
forgotten, (let name ((i e) ...) b ...) cannot be rewriten with rec
because rec is not part of the rrrs language. So, the rewriting of
named let generally takes the form of (letrec ((name (lambda (i ...) b ...)))
(name e ...)). This is a complicated macro even with a tool like
extend-syntax. We are talking about freshman where the requirements to
enter a state supported school are well below those of most private schools.
When you think about what simple-minded tools we've had to teach over
the last few decades, it is such a breath of fresh air to teach something
as beuatiful and elegant as Scheme. However, the overloading of the syntax
of let is a mistake and our students, and I personally, find it abhorent.
Now what choice have you left the writers of the books who help make Scheme
a household word by encouraging the teachers throughout the world that
this stuff is indeed teachable and definitely worth knowing. This is
our decision: Since our sensibilites as well as our students comprehension
suffer greatly, we have opted for always using letrec. This is painful
because that requires more than is generally necessary. Why are we stuck
like that? Well you see there is no macro mechanism and likely there
won't be one before our book gets out and since we wish to stay within
the bounds of the standard, we have been left with no choice. I find the
behavior of the community incomprehensible in its insistence on staying with
a dreadful mistake. Bright people never have difficulty with bizarre
nuances in languages. Look at unix, for example, or worse yet, tex.
But that is not the audience we are dealing with. We have a nice, clean
simple tool except for named let and we only need a consensus for a new
name in order to express programs in the appropriate style for freshmen.
I enjoyed reading the rationale by Pavel concerning why he did not like
my suggestion of "bindlet". I agree with him that "bindlet" is a
bad name and that is why I did not suggest it. I proposed bindrec, which
I still like and which I believe satisfies all of the criteria that have
been enunciated.
... George Springer
∂26-Aug-88 0623 @MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU Clarification on named let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 06:22:52 PDT
Received: from chamartin (TCP 2206400253) by MC.LCS.MIT.EDU 26 Aug 88 09:20:30 EDT
Received: by CHAMARTIN.AI.MIT.EDU; Fri, 26 Aug 88 09:20:46 edt
Date: Fri, 26 Aug 88 09:20:46 edt
From: jinx@CHAMARTIN.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8808261320.AA07344@chamartin>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Fri, 26 Aug 88 00:09:37 EST
Subject: Clarification on named let
Reply-To: jinx@zurich.ai.mit.edu
I find the behavior of the community incomprehensible in its
insistence on staying with a dreadful mistake.
Some people do not view it as a mistake, but rather as a natural
extension to the LET syntax. You are trying to portray your
subjective arguments of elegance and taste as matters of rationality
and clarity, and they are not, they are purely matters of taste. I
have no objection with the fact that you do not like the feature, and
I'm willing to consider alternative names (although none of the ones
mentioned so far are appealing), but PLEASE let's not start accusing
each other of irrationality.
BTW, it does not seem to me that the expansion for "named" LET is
considerably more complicated than the one for "normal" LET. It seems
to me that all the (nonexistent) hair would appear in destructuring
and associating the bindings. Maybe your comment about the expansion
is more of a comment on the tools you are using to write your macros.
∂26-Aug-88 0917 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Named-let squabble: Kiss and make up!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 09:17:40 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 26 Aug 88 12:15:47 EDT
Received: by ZOHAR.AI.MIT.EDU; Fri, 26 Aug 88 12:21:38 edt
Date: Fri, 26 Aug 88 12:21:38 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8808261621.AA16813@zohar>
To: springer@iuvax.cs.indiana.edu, jinx@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Named-let squabble: Kiss and make up!
I observe a bit of friction here:
A: I find the behavior of the community incomprehensible in its
insistence on staying with a dreadful mistake.
B: Some people do not view it as a mistake, but rather as a natural
extension to the LET syntax. You are trying to portray your
subjective arguments of elegance and taste as matters of rationality
and clarity, and they are not, they are purely matters of taste.
This kind of minor squabble cannot be very important.
Perhaps the correct stance is that the existing named let syntax
continue to be supported for those who like it and a new special form
be allocated for those who would like an alternative that they find
more appropriate for their teaching style.
I generally don't like allocating reserved words, but sometimes I
think it is necessary to compromise on such an issue. Why not have
Kent and George choose their favorite, and we can all agree not to
argue too strongly about it.
Please pick a pretty name that is not likely to conflict with anyone's
current usage. Thank you.
∂26-Aug-88 0943 @MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU Summarizing the named-let debate
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 09:43:24 PDT
Received: from mojave.Stanford.EDU (TCP 4405400170) by MC.LCS.MIT.EDU 26 Aug 88 12:37:01 EDT
Received: by mojave.Stanford.EDU (5.59/inc-1.0)
id AA05645; Fri, 26 Aug 88 09:36:05 PDT
Date: Fri, 26 Aug 88 09:36:05 PDT
From: daniel@mojave.Stanford.EDU (Daniel Weise)
Message-Id: <8808261636.AA05645@mojave.Stanford.EDU>
To: Pavel.pa@Xerox.COM
Cc: RRRS-Authors@MC.LCS.MIT.Edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Thu, 25 Aug 88 17:21:10 PDT <880825-172118-5155@Xerox>
Subject: Summarizing the named-let debate
I'm not saying that these claims of pedagogical difficulty are
false, just that I don't yet understand the details of the
problem. Could one of the educators (George? Kent?) please
explain further just what the problem is? It just seems that
exploiting the close correspondence above should work well to
make the idea clear.
I teach Stanford masters and phd students and have the same problems
George and Dan do. To the uninitiated, "named let" is a confusing and
unnatural extension of LET. They ask, "what's that funny identifier
doing there, and why should such a simple syntactic modification change
the meaning so much?"
Overloading LET is a surprise, it makes students unsure of what they
understand. If we are suddenly allowed to change the meaning of LET,
then we also should be able to change LAMBDA and IF as well.
I advocate (and will use in future classes) LABEL+LET because the
form both introduces a LABEL (am I being reactionary?) and does a LET.
I dislike NAMED-LET because the let expression is not being named,
some procedure is being named.
Daniel
∂26-Aug-88 1137 @MC.LCS.MIT.EDU:gls@Think.COM Clarification on named let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 11:37:22 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 26 Aug 88 14:34:43 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 26 Aug 88 14:30:11 EDT
Received: by joplin.think.com; Fri, 26 Aug 88 14:33:12 EDT
Date: Fri, 26 Aug 88 14:33:12 EDT
From: gls@Think.COM
Message-Id: <8808261833.AA05612@joplin.think.com>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Fri, 26 Aug 88 00:09:37 EST <8808260648.AA14352@Think.COM>
Subject: Clarification on named let
I was not happy with "bindrec", but I didn't put my finger on why until
I read your most recent note (which I found very clear and to the point).
I don't like "bindrec" because the suffix "rec" doesn't mean what it
does in "letrec". Letrec differs from let in a matter of scope only,
in that the variables to be bound are made available in parts of
the program text that would otherwise be surprising, because they
are executed before the variables are really available. Bindrec,
on the other hand, provides an ADDITIONAL name for an additional
entity, and I regard it as secondary that this name has a rec-type
binding.
I might be happier if there were a "bind" just like bindrec, which also
gives a name to the function but not a rec-bound name. Such a form would
of course be useless, but that's the price of symmetry. My point is that
I believe the issue has been confused up to now because there are
separarable notions here that have been conceptually mingled because the
suffix "rec" was used to mean two different things.
It may be worthwhile to ponder whether a named letrec makes sense.
I think so, and in that case we need a name for that idea too.
Then clearly named let should not be called bindrec, for then
named letrec would be bindrecrec (more yuk).
How about letfn (and letfnrec)?
--Guy
∂26-Aug-88 1149 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Why named LET anyway?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 11:49:01 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 AUG 88 14:39:12 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA01957@VX.LCS.MIT.EDU>; Wed, 9 Mar 88 06:32:21 est
Date: Wed, 9 Mar 88 06:32:21 est
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Why named LET anyway?
At the risk of beating a dead horse...
As a programmer who daily hacks in Scheme, it is
indeed useful to have LETREC, LET*, named-LET ...
but as a student in the MIT Intro. Programming
course years ago (6.001) I was always contented
with mere LET and internal DEFINE. I was never
confused and, although I noticed that frobs like
named-LET save on average 15-20 keystrokes, I did
not feel an unquenchable desire for a cliche macro.
Why exactly do some of you find it necessary to
teach your students about these variant forms?
Couldn't an argument be made that it is better to
teach a minimum of mechanism to a student and save
the niceties for ``professional'' programmers?
Unless your course purports to teach ``profession''.
This is not intended as a flame... I hope to learn
something by your replies.
~Ziggy
P.S. Note that SI&CP do not mention LET* or LETREC
or named-LET, yet many consider it a good book.
∂26-Aug-88 1213 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Clarification on named let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 12:13:09 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 26 Aug 88 15:11:23 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 AUG 88 12:10:13 PDT
Date: Fri, 26 Aug 88 12:10:08 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Clarification on named let
In-reply-to: "springer@iuvax.cs.indiana.edu's message of Fri, 26 Aug 88 00:09:37
EST"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880826-121013-6303@Xerox>
Re: ``bindlet'': Oops. Ahem.
Re: ``bindrec'': How will a naive user keep it separate in their mind from
``letrec''?
Re: a picky point concerning the expansion of named ``let'': Actually, the R3RS
expansion is a bit more complex than you said, since the evaluation of the
bound-variable expressions is not in the scope of the name of the ``let'':
(let name ((i e) ...) b ...)
((letrec ((name (lambda (i ...) b ...)))
name)
e ...)
Changing the reserved word that goes at the front of the named-let form will not
in any way simplify the expansion, so I don't much care how complex the
expansion is (at least if we all agree that it's a useful idiom at all). In
what way will changing the reserved word make teaching this form any easier?
I don't understand Daniel Weise's (rhetorical) question, ``why should such a
simple syntactic modification change the meaning so much?'' As far as I can
tell, the only change to the meaning is that one more name is bound over the
scope of the body. This is no more major a change than the addition of another
variable/value pair to a normal let. My very point about the named form of
``let'' is that it is a very minor extension of the semantics.
Please, teachers, answer this question for me:
What goes wrong when you explain named-let as being exactly like the unnamed
kind except that one more thing has been given a name? That is, we have named
the ``lambda'' that encapsulates the body. I assume that you do not teach
``let'' as a special form but as a useful abbreviation for an applied
``lambda''. If this assumption is not true, then that explains much and I
change my question to ``why don't you teach it as an abbreviation?''
Again, I'm not trying to claim that the way you're teaching things is wrong, I'm
trying to understand what breaks down when you try it this way. I am also a
teacher, but have never taught a course in Scheme, so I'm trying to use your
experience to understand what does and doesn't work in the classroom, and why.
Thank you for your time,
Pavel
∂26-Aug-88 1233 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Why named LET anyway?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Aug 88 12:33:14 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 26 Aug 88 15:29:55 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 AUG 88 12:22:25 PDT
Date: Fri, 26 Aug 88 12:22:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Why named LET anyway?
In-reply-to: "ziggy@VX.LCS.MIT.EDU's message of Wed, 9 Mar 88 06:32:21 est"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <880826-122225-6327@Xerox>
Personally, I see named let, letrec, and let* as having three very different
uses. Named let is for loops and other single-function recursions in which I
wish immediately to call the function after its binding. Letrec is for
multiple-function recursions and those single-function ones in which there is
other work to be done before calling the function. Let* is completely unrelated
to recursion and is simply to avoid the indenting complexity of
immediately-nested (unnamed) lets.
Both named let and letrec can be simulated reasonably well with internal
defines, but for named let cases, I find the extra overhead of breaking out the
function definition explicitly in a define a bit distasteful and a bit harder to
read. Really, it is a matter of taste. I do use internal defines quite
extensively for the definition of locally-required auxillary functions,
recursive or otherwise. I think, though I 'm not really aware of it at the
time, that I usually avoid letrec in favor of internal defines, simply for
indenting reasons.
I hope that I've made one programmer's reasoning clear.
As for SI&CP being considered a good book in spite of its silence on let*,
letrec*, and named let, it is worth remembering that the book does not have as
its major purpose the teaching of the Scheme programming language, but rather
some concepts much more general than that. For its particular pedagogical
purposes, internal defines are entirely sufficient.
Pavel
∂28-Aug-88 0839 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu named-let proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Aug 88 08:39:05 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Aug 88 11:37:07 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa14359; 28 Aug 88 11:36 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id ac27495;
28 Aug 88 11:21 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
id AA10037; Sat, 27 Aug 88 19:04:42 edt
Date: Sat, 27 Aug 88 19:04:42 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Sat, 27 Aug 88 19:04:42 edt
To: rrrs-authors.2@cs.brandeis.edu
In-Reply-To: George Springer's message of Thu, 25 Aug 88 10:57:09 EST <8808251632.AA16299@zurich>
Subject: named-let proposal
*Sigh* I've said this privately to several people, but it seems time
to state it publically: I have taught a number of freshman (admittedly
at MIT, but I will repeat the experiment this semester at Brandeis)
and have encountered no trouble in teaching named let. The trick
appears to be in introducing things in the following order:
(a) Internal (not incremental) define for making internal loops; a la
Abelson and Sussman book.
(b) Introducing let with many examples as a binding form.
(c) Finally, after the frustration of two weeks of writing loops that
are hard to read because the initial conditions appear at the END of
the program, introducing the name in a let to make the "loop" easier
to read.
I understand that this ordering is repugnant to the folks at Indiana,
but I submit that this form of repugnance doesn't really justify a
language change, and it appears to be the ONLY issue.
One final note: I find it virtually impossible to believe that
students at Indiana can easily and comfortably navigate their way
through the early introduction of lambda and letrec, and then stumble
on named let. Even some of our seniors have trouble reading programs
that use letrec to completely replace internal define!
--Jim Miller
∂29-Aug-88 2324 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu named let again
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Aug 88 23:24:13 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 30 Aug 88 00:39:56 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Mon, 29 Aug 88 23:35:59 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let again
I think I have figured out just why I do not like named "let", though I
am sure others are bound to disagree with my reasoning. It has to do
with abstraction. To wit, the "just giving a name to one more piece of
the transformation" argument does not work if you are trying to look at
things abstractly. Once we understand that "let" is shorthand for
direct application of "lambda", we forget it, and rightly so. "let"
expresses the local binding of variables to values, and the fact that
the local binding is accomplished by direct application of a "lambda"
expression is irrelevant. For the same reason, David Bartley's
argument in favor of named "let" is not persuasive, since local binding
is not the same thing as looping or recurring. In naming something, we
should consider what it expresses rather than how it works. That is
why I like the name "recur", and I think David's argument against it is
weak. If you look at how the construct works, i.e., by creating a
procedure and invoking it, then "recur" does not make sense. But if
you look at what it expresses, i.e., a loop or recurrence, then "recur"
does make sense. Perhaps the name "recurrence" would make slightly
more sense than "recur" if it were not twice as long as "recur".
I am willing to go along with Gerry's suggestion and add "recur" to the
report as optional syntax. We can put both forms of "let" together
where the unnamed form is now and say that the named form of "let" is
the same as "recur". "recur" would be described where the named form
of "let" is currently.
Kent
∂29-Aug-88 2337 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named-let proposal
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Aug 88 23:37:03 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 30 Aug 88 00:52:55 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Mon, 29 Aug 88 23:51:02 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jmiller%cs.brandeis.edu@RELAY.CS.NET
Subject: Re: named-let proposal
Cc: rrrs-authors@mc.lcs.mit.edu
> I understand that this ordering is repugnant to the folks at Indiana,
I do not find your method of introducing students to internal "define"s
first, "let" second, and named "let" third "repugnant". However, I do
have problems with it. We use "letrec" for two reasons other than the
obvious historical reason. The first is that internal "define"s look
like imperative operations, whereas "letrec" bindings do not. The
second is that "letrec" emphasizes the relationship between names and
values, as does "let"; with "letrec" this relationship is a circular
one. In my opinion, this relationship is not as easy to see with
internal "define"s. We spend a lot of time trying to be sure that
students learn that names and procedures are separable, i.e., that the
relationships between names and procedures are external in that they
depend on the binding construct. This is why we use "lambda" every
time we define a procedure at top level, e.g.:
(define id (lambda (x) x))
instead of using the shorter "defun"-style syntax:
(define (id x) x)
This also explains why we prefer "rec" to "named-lambda". These may
seem like picky points to many (most?), but we want to be sure that the
syntax we use does not give false impressions.
Kent
∂31-Aug-88 1634 @MC.LCS.MIT.EDU:gls@Think.COM Scheme Bibliography (Aug. 1988)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 16:34:01 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 30 Aug 88 13:19:41 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 30 Aug 88 13:10:57 EDT
Received: by joplin.think.com; Tue, 30 Aug 88 13:17:38 EDT
Date: Tue, 30 Aug 88 13:17:38 EDT
From: gls@Think.COM
Message-Id: <8808301717.AA28656@joplin.think.com>
To: oz@yunexus.arpa
Cc: Think.COM!gls@ai.toronto.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Ozan Yigit's message of Mon, 29 Aug 88 14:34:39 EDT <8808291834.AA15954@yunexus.UUCP>
Subject: Scheme Bibliography (Aug. 1988)
Date: Mon, 29 Aug 88 14:34:39 EDT
From: oz@yunexus.arpa (Ozan Yigit)
...
Ps: I have ordered a copy of your rabbit report from NTIS. Do you
happen to have a machine-readable copy of the compiler + vm ??
No, I'm afraid not. Unless they still exist on old MIT backup
tapes, they're gone.
--Guy
∂31-Aug-88 1748 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Bibliography database
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 17:48:34 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Aug 88 00:08:12 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA14412@BLOOM-BEACON.MIT.EDU>; Tue, 30 Aug 88 23:59:06 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Aug 88 22:19:04 GMT
From: mcvax!unido!inria!crin!masini@uunet.uu.net (Gerald MASINI)
Organization: C.R.I.N
Subject: Bibliography database
Message-Id: <594@crin.crin.fr>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Our site has been disconnected from the net for a few days, so I don't
know if this kind of thing has already been posted.
Here is the bibliography database posted some time ago by (apologies,
I've lost the header of the transaction !), converted into the BibTeX
format. The entries are sorted in alphabetical order, and then in
chronological order. The field KEYWORD is of my own and can be ignored.
Some entries are not complete and are followed by the unknown fields as
comments. I've added two entries (steele79, greussay84) to the database.
I would be very pleased to receive your eventual corrections, new entries
or any comments.
Thanx in advance.
---- cut here ---- cut here ---- cut here ---- cut here ---- cut here ----
% ---- ABBREVIATIONS
@string{ail = "Artificial Intelligence Laboratory, MIT"}
@string{aim = "AI Memo"}
@string{at = "Austin, Texas"}
@string{cacm = "Communications of the ACM"}
@string{cm = "Cambridge, Massachusetts"}
@string{jacm = "Journal of the ACM"}
@string{lc80 = "Conference Record of the 1980 Lisp Conference"}
@string{mitp = "MIT Press"}
@string{pp = "Pittsburgh, Pennsylvania"}
@string{sv = "Springer-Verlag"}
@string{slfp82 = "Proceedings of the 1982 ACM Conference
on Lisp and Functional Programming"}
@string{slfp84 = "Proceedings of the 1984 ACM Conference
on Lisp and Functional Programming"}
@string{slfp86 = "Proceedings of the 1986 ACM Conference
on Lisp and Functional Programming"}
% ---- DATABASE
% ---- aaaa
@BOOK{abelson85,
AUTHOR = {H. Abelson and G.J. Sussman and J. Sussman},
TITLE = {{Structure and Interpretation of Computer Programs}},
PUBLISHER = mitp,
ADDRESS = cm,
YEAR = 1985,
KEYWORDS = {scheme}}
% ---- bbbb
@INPROCEEDINGS{bartley86,
AUTHOR = {D.H. Bartley and J.C. Jensen},
TITLE = {{The Implementation of PC Scheme}},
BOOKTITLE = slfp86,
YEAR = 1986,
PAGES = {86--93},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@INPROCEEDINGS{batali82,
AUTHOR = {J. Batali and E. Goodhue and C. Hanson and H. Shrobe
and R.M. Stallman and G.J. Sussman},
TITLE = {{The Scheme-81 Architecture --- System and Chip}},
BOOKTITLE = {{Proceedings of the Conference on Advanced Research in VLSI}},
YEAR = 1982,
PAGES = {69--77},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
% ---- cccc
@INPROCEEDINGS{clinger84,
AUTHOR = {W. Clinger},
TITLE = {{The Scheme 311 Compiler: An Exercise in Denotational Semantics}},
BOOKTITLE = slfp84,
ADDRESS = at,
YEAR = 1984,
PAGES = {356--364},
KEYWORDS = {scheme}}
@TECHREPORT{clinger85,
AUTHOR = {W. Clinger},
TITLE = {{The Revised Revised Report on Scheme, or An Uncommon Lisp}},
TYPE = aim,
NUMBER = 848,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1985,
KEYWORDS = {scheme}}
@TECHREPORT{clinger85a,
AUTHOR = {W. Clinger},
TITLE = {{The Revised Revised Report on Scheme, or An Uncommon Lisp}},
NUMBER = 174,
INSTITUTION = {Computer Science Department, Indiana University},
YEAR = 1985,
KEYWORDS = {scheme}}
% ---- dddd
@INPROCEEDINGS{dybvig86,
AUTHOR = {R.K. Dybvig and D.P. Friedman and C.T. Haynes},
TITLE = {{Expansion-Passing Style: Beyond Conventional Macros}},
BOOKTITLE = slfp86,
YEAR = 1986,
PAGES = {143--150},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@BOOK{dybvig87,
AUTHOR = {R.K. Dybvig},
TITLE = {{The Scheme Programming Language}},
PUBLISHER = {Prentice-Hall},
ADDRESS = {Englewood Cliffs, New Jersey},
YEAR = 1987,
KEYWORDS = {scheme}}
% ---- eeee
@TECHREPORT{eisenberg85,
AUTHOR = {M.A. Eisenberg},
TITLE = {{Bochser: An Integrated Scheme Programming System}},
NUMBER = 349,
INSTITUTION = {MIT},
ADDRESS = cm,
YEAR = 1985,
KEYWORDS = {scheme}}
% ---- ffff
@MISC{feeley86,
AUTHOR = {M. Feeley and G. LaPalme},
TITLE = {{Closure Generation Based on Viewing LAMBDA
as EPSILON plus COMPILE}},
YEAR = 1986,
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% HOWPUBLISHED = {},
@MASTERTHESIS{feeley86a,
AUTHOR = {M. Feeley},
TITLE = {{\it Deux approches \`{a} l'implantation du language Scheme}},
SCHOOL = {D\'{e}partement d'Informatique et de Recherche
Op\'{e}rationelle, Universit\'{e} de Montreal},
YEAR = 1986,
KEYWORDS = {scheme}}
@ARTICLE{feeley87,
AUTHOR = {M. Feeley and G. LaPalme},
TITLE = {{Using Cloures for Code Generation}},
JOURNAL = {{Computer Languages}},
VOLUME = 12,
NUMBER = 1,
YEAR = 1987,
PAGES = {47--66},
KEYWORDS = {scheme}}
@ARTICLE{felleisen86,
AUTHOR = {M. Felleisen and D.P. Friedman},
TITLE = {{A Closer Look at Export and Import Statements}},
JOURNAL = {Computer Languages},
VOLUME = 11,
NUMBER = 1,
PAGES = {29--37},
YEAR = 1986,
KEYWORDS = {scheme}}
@INPROCEEDINGS{felleisen86a,
AUTHOR = {M. Felleisen and D.P. Friedman and E.E. Kohlbecker and B. Duba},
TITLE = {{Reasoning with Continuations}},
BOOKTITLE = {Proceedings of the Symposium on Logic in Computer Science},
ADDRESS = {Washigton DC},
YEAR = 1986,
PAGES = {131--141},
KEYWORDS = {scheme}}
@TECHREPORT{fessenden83,
AUTHOR = {C. Fessenden and W. Clinger and D.P. Friedman and C.T. Haynes},
TITLE = {{Scheme 311, version 4. Reference Manual}},
TYPE = {Computer Science Technical Report},
NUMBER = 137,
INSTITUTION = {Indiana University},
YEAR = 1983,
KEYWORDS = {scheme}}
@INCOLLECTION{friedman84,
AUTHOR = {D.P. Friedman and C.T. Haynes and E.E. Kohlbecker},
TITLE = {{Programming with Continuations}},
BOOKTITLE = {{Program Transformation and Programming Environments}},
EDITOR = {P. Pepper},
PUBLISHER = sv,
YEAR = 1984,
PAGES = {263--274},
KEYWORDS = {scheme}}
@INPROCEEDINGS{friedman85,
AUTHOR = {D.P. Friedman and C.T. Haynes},
TITLE = {{Constraining Control}},
BOOKTITLE = {{Proceedings of the 12th Annual Symposium
on Principles of Programming Languages}},
YEAR = 1985,
PAGES = {245--254},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@TECHREPORT{friedman85a,
AUTHOR = {D.P. Friedman and C.T. Haynes and E.E. Kohlbecker and M. Wand},
TITLE = {{Scheme 84 Interim Reference Manual}},
NUMBER = 153,
INSTITUTION = {Computer Science Department, Indiana University},
YEAR = 1985,
KEYWORDS = {scheme}}
@BOOK{friedman87,
AUTHOR = {D.P. Friedman and M. Felleisen},
TITLE = {{The Little LISPer}},
PUBLISHER = mitp,
ADDRESS = cm,
YEAR = 1987,
KEYWORDS = {scheme}}
% ---- gggg
@INPROCEEDINGS{greussay84,
AUTHOR = {P. Greussay},
TITLE = {{Pr\'{e}sentation de SCHEME \`{a} partir d'exemples}},
BOOKTITLE = {Actes des 2\`{e}mes Journ\'{e}es d'Etude
sur les Langages Orient\'{e} Objets.
Bigre+Globule No. 41},
ADDRESS = {Brest},
YEAR = 1984,
PAGES = {5--41},
KEYWORDS = {scheme}}
% ---- hhhh
@INPROCEEDINGS{haynes84,
AUTHOR = {C.T. Haynes and D.P. Friedman},
TITLE = {{Engines Build Process Abstractions}},
BOOKTITLE = slfp84,
ADDRESS = at,
YEAR = 1984,
PAGES = {18--24},
KEYWORDS = {scheme}}
@INPROCEEDINGS{haynes84a,
AUTHOR = {C.T. Haynes and D.P. Friedman and M. Wand},
TITLE = {{Continuations and Coroutines}},
BOOKTITLE = slfp84,
ADDRESS = at,
YEAR = 1984,
PAGES = {293--298},
KEYWORDS = {scheme}}
@ARTICLE{haynes86,
AUTHOR = {C.T. Haynes and D.P. Friedman and M. Wand},
TITLE = {{Obtaining Coroutines with Continuations}},
JOURNAL = {Computer Languages},
VOLUME = 11,
NUMBER = {3--4},
YEAR = 1986,
PAGES = {143--153},
KEYWORDS = {scheme}}
@INPROCEEDINGS{haynes86a,
AUTHOR = {C.T. Haynes},
TITLE = {{Logic Continuations}},
BOOKTITLE = {{Proceedings of the 3rd International Conference
on Logic Programming}},
YEAR = 1986,
PAGES = {671--685},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@INPROCEEDINGS{henderson82,
AUTHOR = {P. Henderson},
TITLE = {{Functional Geometry}},
BOOKTITLE = slfp82,
ADDRESS = pp,
YEAR = 1982,
PAGES = {179--187},
KEYWORDS = {scheme}}
% ---- kkkk
@PHDTHESIS{kohlbecker86,
AUTHOR = {E.E. Kohlbecker},
TITLE = {{Syntactic Extensions in the Programming Language Lisp}},
SCHOOL = {Indiana University},
YEAR = 1986,
KEYWORDS = {scheme}}
@BOOK{kranz86,
AUTHOR = {D. Kranz and R. Kelsey and J.A. Rees and P. Hudak
and J. Philbin and N.I. Adams},
BOOKTITLE = {{Proceedings of the SIGPLAN 1986 Symposium
on Compiler Construction}},
YEAR = 1986,
PAGES = {219--233},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% TITLE = {},
%%%%%%%%%%%%%%%% ADDRESS = {},
% ---- mmmm
@INPROCEEDINGS{mcdermott80,
AUTHOR = {D. McDermott},
TITLE = {{An Efficient Environment Allocation Scheme
in an Interpreter for a Lexically-Scoped Lisp}},
BOOKTITLE = lc80,
YEAR = 1980,
PAGES = {154--162},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@INPROCEEDINGS{muchnick80a,
AUTHOR = {S.S. Muchnick and U.F. Pleban},
TITLE = {{A Semantic Comparison of Lisp and Scheme}},
BOOKTITLE = lc80,
YEAR = 1980,
PAGES = {56--65},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
% ---- rrrr
@INPROCEEDINGS{rees82,
AUTHOR = {J.A. Rees and N.I. Adams},
TITLE = {{T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool}},
BOOKTITLE = slfp82,
ADDRESS = pp,
YEAR = 1982,
PAGES = {114--122},
KEYWORDS = {scheme}}
@MANUAL{rees84,
AUTHOR = {J.A. Rees and N.I. Adams and J.R. Meehan},
TITLE = {{The T Manual}},
EDITION = {Fourth},
ORGANIZATION = {Computer Science Department, Yale University},
YEAR = 1984,
KEYWORDS = {scheme}}
@INPROCEEDINGS{reynolds72,
AUTHOR = {J. Reynolds},
TITLE = {{Definitional Interpreters
for Higher Order Programming Languages}},
YEAR = 1972,
PAGES = {717--740},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% BOOKTITLE = {{ACM Conference Proceedings}}, ????
%%%%%%%%%%%%%%%% ADDRESS = {},
@MISC{rozas84,
AUTHOR = {G.J. Rozas},
TITLE = {{\it Liar, an Algol-Like Compiler for Scheme}},
HOWPUBLISHED = {{S.B. Thesis, MIT Department of Electrical
Engineering and Computer Science}},
YEAR = 1984,
KEYWORDS = {scheme}}
% ---- ssss
@INPROCEEDINGS{srivastava85,
AUTHOR = {A. Srivastava and D. Oxley and A. Srivastava},
TITLE = {{An (Other) Integration of Logic and Functional Programming}},
BOOKTITLE = {Proceedings of the Symposium on Logic Programming},
YEAR = 1985,
PAGES = {254--260},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@TECHREPORT{steele76,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{Lambda, the Ultimate Imperative}},
TYPE = aim,
NUMBER = 353,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1976,
KEYWORDS = {scheme}}
@TECHREPORT{steele76a,
AUTHOR = {G.L. Steele Jr.},
TITLE = {{Lambda, the Ultimate Declarative}},
TYPE = aim
NUMBER = 379,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1976,
KEYWORDS = {scheme}}
@INPROCEEDINGS{steele77,
AUTHOR = {G.L. Steele Jr.},
TITLE = {{Debunking the ``Expensive Procedure Call'' Myth,
or Procedure Call Implementations Considered Harmful,
or LAMBDA, the Ultimate GOTO}},
YEAR = 1977,
PAGES = {153--162},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% BOOKTITLE = {ACM Conference Proceedings}, ????
%%%%%%%%%%%%%%%% ADDRESS = {},
@INPROCEEDINGS{steele77a,
AUTHOR = {G.L. Steele Jr.},
TITLE = {{Macaroni is Better than Spaghetti}},
BOOKTITLE = {{Proceedings of the Symposium
on Artificial Intelligence and Programming Languages}},
YEAR = 1977,
PAGES = {60--66},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@TECHREPORT{steele78,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{The Revised Report on Scheme, a Dialect of Lisp}},
TYPE = aim,
NUMBER = 452,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1978,
KEYWORDS = {scheme}}
@TECHREPORT{steele78a,
AUTHOR = {G.L. Steele Jr.},
TITLE = {{Rabbit: A Compiler for Scheme}},
NUMBER = 474,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1978,
KEYWORDS = {scheme}}
@TECHREPORT{steele78a,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{The Art of the Interpreter,
or the Modularity Complex (parts zero, one, and two)}},
TYPE = aim,
NUMBER = 453,
INSTITUTION = ail,
YEAR = 1978,
KEYWORDS = {scheme}}
@TECHREPORT{steele79,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{Design of LISP-Based Processors
or, SCHEME: A Dielectric LISP
or, Finite Memories Considered Harmful
or, LAMBDA: The Ultimate Opcode}},
TYPE = aim,
NUMBER = 514,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = {1979},
KEYWORDS = {scheme}}
@INCOLLECTION{steele80,
AUTHOR = {G.L. Steele Jr.},
TITLE = {{Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO}},
BOOKTITLE = {{AI: An MIT Perspective}},
EDITOR = {R.H. Brown},
PUBLISHER = mitp,
ADDRESS = cm,
YEAR = 1980,
KEYWORDS = {scheme}}
@INPROCEEDINGS{steele80a,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{The Dream of a Lifetime: A Lazy Variable Extent Mechanism}},
BOOKTITLE = lc80,
YEAR = 1980,
PAGES = {163--172},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@ARTICLE{steele80b,
AUTHOR = {G.L. Steele Jr. and G.J. Sussman},
TITLE = {{Design of a Lisp-Based Processor}},
JOURNAL = cacm,
VOLUME = 23,
NUMBER = 11,
PAGES = {628--645},
YEAR = 1980,
KEYWORDS = {scheme}}
@TECHREPORT{sussman75,
AUTHOR = {G.J. Sussman and G.L. Steele Jr.},
TITLE = {{Scheme: An Interpreter for Extended Lambda Calculus}},
TYPE = aim,
NUMBER = 349,
INSTITUTION = ail,
ADDRESS = cm,
YEAR = 1975,
KEYWORDS = {scheme}}
@ARTICLE{sussman81,
AUTHOR = {G.J. Sussman and J. Holloway and G.L. Steele Jr. and A. Bell},
TITLE = {{Scheme-79 --- Lisp on a Chip}},
VOLUME = 14,
NUMBER = 7,
YEAR = 1981,
PAGES = {10--21},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% JOURNAL = {IEEE Computer},
% ---- wwww
@ARTICLE{wand78,
AUTHOR = {M. Wand},
TITLE = {{Continuation-Based Program Transformation Strategies}},
JOURNAL = jacm,
VOLUME = 27,
NUMBER = 1,
YEAR = 1978,
PAGES = {174--180},
KEYWORDS = {scheme}}
@INPROCEEDINGS{wand80,
AUTHOR = {M. Wand},
TITLE = {{Continuation-Based Multiprocessing}},
BOOKTITLE = lc80,
YEAR = 1980,
PAGES = {19--28},
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% ADDRESS = {},
@INCOLLECTION{wand86,
AUTHOR = {M. Wand},
TITLE = {{From Interpreter to Compiler: A Representational Derivation}},
BOOKTITLE = {{Programs as Data Objects}},
PUBLISHER = {Springer-Verlag Lecture Notes},
YEAR = 1986,
KEYWORDS = {scheme}}
%%%%%%%%%%%%%%%% PAGES = {},
---- cut here ---- cut here ---- cut here ---- cut here ---- cut here ----
--
Ge'rald MASINI CRIN (Centre de Recherche en Informatique de Nancy)
uucp: masini@crin.crin.fr
post: CRIN B.P. 239 54506 Vandoeuvre-les-Nancy Cedex FRANCE
phone: +33 83.91.21.45
∂31-Aug-88 1749 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Gabriel benchmarks in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 17:48:55 PDT
Received: from cs.utah.edu (TCP 1200000004) by MC.LCS.MIT.EDU 31 Aug 88 17:29:33 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA13482; Wed, 31 Aug 88 15:28:18 MDT
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA06495; Wed, 31 Aug 88 15:28:14 MDT
Date: Wed, 31 Aug 88 15:28:14 MDT
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8808312128.AA06495@car.utah.edu>
To: scheme@mc.lcs.mit.edu
Subject: Gabriel benchmarks in Scheme
A while back Will Clinger sent out his set of Gabriel benchmarks which
he had rewritten in Scheme. I have sent a message directly to him
asking for a copy, but I get no reply. Perhaps he is on vacation.
But I need them now (so I don't have to write them myself). Does
anyone have a copy they can send me or know of a machine from which I
can ftp a copy?
Thanks,
Harold
∂01-Sep-88 0852 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 08:52:31 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 1 Sep 88 11:50:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA17410; Thu, 1 Sep 88 11:48:41 EDT
Posted-Date: Thu, 1 Sep 88 11:49:55 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA06194; Thu, 1 Sep 88 11:49:55 EDT
Date: Thu, 1 Sep 88 11:49:55 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809011549.AA06194@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Wed, 24 Aug 88 12:47:18 EDT <8808241647.AA04415@joplin.think.com>
Subject: named let -> ???
Posted-From: The MITRE Corp., Bedford, MA
Posted-Date: Wed, 24 Aug 88 09:02:34 EDT
Date: Wed, 24 Aug 88 09:02:34 EDT
From: ramsdell%linus@mitre-bedford.arpa
Was there any agreement reached on the new name for named let?
John
I guess the answer is no.
Here are some more names to ponder: LET-TAG, LET-MARK, LABEL,
LET-LABEL, LET-REF, LET-NOTE, and LET-NAMED. There were many other
proposals generated quite awhile ago when this subject was last
discussed. Would someone retrieve those suggestions? Search for
LABEL, as I remember I once suggested it near the time the subject was
discussed.
John
PS. I hope we do not decide this issue based on what can be taught to
first year students. After all, they can do quite well using just
ordinary LET and local DEFINE's.
∂01-Sep-88 1146 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 11:46:20 PDT
Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU 1 Sep 88 14:40:52 EDT
Received: by MURREN.AI.MIT.EDU; Thu, 1 Sep 88 14:38:14 edt
Date: Thu, 1 Sep 88 14:38:14 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809011838.AA04335@murren>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 1 Sep 88 11:49:55 EDT <8809011549.AA06194@huxley.sun.uucp>
Subject: named let -> ???
Reply-To: hal@zurich.ai.mit.edu
With acknowledgement to Lewis Carroll's well-known distinctions--
Since named let is already called named let, and we have already
agreed to optionally keep the current syntax, which calls the name of
named let a named form of let, why don't we just name it named-let, to
minimize the confusion?
-- Hal
∂01-Sep-88 1221 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA NAMED-LET sounds good to me.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 12:20:58 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 1 Sep 88 15:02:39 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA23322; Thu, 1 Sep 88 15:00:49 EDT
Posted-Date: Thu, 1 Sep 88 15:02:02 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA06429; Thu, 1 Sep 88 15:02:02 EDT
Date: Thu, 1 Sep 88 15:02:02 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809011902.AA06429@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Thu, 1 Sep 88 14:38:14 edt <8809011838.AA04335@murren>
Subject: NAMED-LET sounds good to me.
Posted-Date: Thu, 1 Sep 88 14:38:14 edt
Date: Thu, 1 Sep 88 14:38:14 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Reply-To: hal@zurich.ai.mit.edu
With acknowledgement to Lewis Carroll's well-known distinctions--
Since named let is already called named let, and we have already
agreed to optionally keep the current syntax, which calls the name of
named let a named form of let, why don't we just name it named-let, to
minimize the confusion?
-- Hal
This sounds quite sensible to me. I am sold! I vote for NAMED-LET.
John
∂01-Sep-88 1254 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU NAMED-LET sounds good to me, too.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 12:54:32 PDT
Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 1 Sep 88 15:44:22 EDT
Received: by DUMBO.AI.MIT.EDU; Thu, 1 Sep 88 15:41:33 edt
Date: Thu, 1 Sep 88 15:41:33 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8809011941.AA21774@dumbo>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 1 Sep 88 15:02:02 EDT <8809011902.AA06429@huxley.sun.uucp>
Subject: NAMED-LET sounds good to me, too.
Reply-To: arthur%zurich@mc.lcs.mit.edu
NAMED-LET is fine by me, too, as long as we don't remove the existing syntax.
Arthur
∂01-Sep-88 1838 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 18:38:41 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 1 Sep 88 21:36:56 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Thu, 1 Sep 88 20:31:41 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: hal@ZURICH.AI.MIT.EDU
Subject: Re: named let -> ???
Cc: rrrs-authors@mc.lcs.mit.edu
Date: Thu, 1 Sep 88 14:38:14 edt
From: Hal Abelson <hal@murren.ai.mit.edu>
Subject: named let -> ???
With acknowledgement to Lewis Carroll's well-known distinctions--
Since named let is already called named let, and we have already
agreed to optionally keep the current syntax, which calls the name of
named let a named form of let, why don't we just name it named-let, to
minimize the confusion?
-- Hal
The name "named-let" has many of the same problems as the named form of
"let", so it would be senseless to make this change. Gerry proposed that
George and I pick a name. I suggested "recur" as the name, and George
tells me that "recur" is his choice as well. So please, let's just plan
to add "recur", leave the named form of "let", and then let's get on to
other problems.
Kent
∂02-Sep-88 1048 @MC.LCS.MIT.EDU:gls@Think.COM named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Sep 88 10:47:18 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 2 Sep 88 13:37:06 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 2 Sep 88 13:21:38 EDT
Received: by joplin.think.com; Fri, 2 Sep 88 13:34:53 EDT
Date: Fri, 2 Sep 88 13:34:53 EDT
From: gls@Think.COM
Message-Id: <8809021734.AA08862@joplin.think.com>
To: hal@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Hal Abelson's message of Thu, 1 Sep 88 14:38:14 edt <8809011838.AA04335@murren>
Subject: named let -> ???
Date: Thu, 1 Sep 88 14:38:14 edt
From: hal@murren.ai.mit.edu (Hal Abelson)
Reply-To: hal@zurich.ai.mit.edu
With acknowledgement to Lewis Carroll's well-known distinctions--
Since named let is already called named let, and we have already
agreed to optionally keep the current syntax, which calls the name of
named let a named form of let, why don't we just name it named-let, to
minimize the confusion?
-- Hal
Let's get this straight:
The name of it is called "`named let'".
The name of it actually is "named-let".
But it is called "named let".
And it actually *is* "(defmacro named-let (name bindings . body) ...)"?
--Guy
∂02-Sep-88 1145 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA named let ::: call it A-LET-NAMED
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Sep 88 11:45:46 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 2 Sep 88 14:43:41 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA13650; Fri, 2 Sep 88 14:42:12 EDT
Posted-Date: Fri, 2 Sep 88 14:43:26 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA07265; Fri, 2 Sep 88 14:43:26 EDT
Date: Fri, 2 Sep 88 14:43:26 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8809021843.AA07265@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Subject: named let ::: call it A-LET-NAMED
If we call it A-LET-NAMED, you can have code that looks like:
(a-let-named loop ((a 0))
....
)
Makes it sound epic. (Just kidding.)
John
∂03-Sep-88 1329 NET-ORIGIN@MC.LCS.MIT.EDU Scheme Bibliography (Sept. 1988) Notes, Additions.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Sep 88 13:29:05 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 SEP 88 16:18:57 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA11580@EDDIE.MIT.EDU>; Sat, 3 Sep 88 16:17:20 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA13476@BLOOM-BEACON.MIT.EDU>; Sat, 3 Sep 88 05:58:06 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Sep 88 17:21:42 GMT
From: att!chinet!mcdchg!clyde!watmath!utgpu!utzoo!yunexus!oz@bloom-beacon.mit.edu (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme Bibliography (Sept. 1988) Notes, Additions.
Message-Id: <850@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Notes:
o Scheme Bibliography will probably appear as a section
in Lisp Pointers, titled "Readings In Scheme".
o Noone appears to have any additions to the bibliography,
as I have a total "contributor's silence".
o Well, foo. they missed :-). Four entries were added, as
included at the end of this article, in diff -c format.
[Use patch program to bring your database up-to-date:
in the directory containing scheme.bib: patch <this-article]
[Non-Unix folk, send mail for a copy of the full database
if needed.]
o I Received much mail about the biblio. Nice to see
that it is useful to so many.
o Abstracts needed: If you have any abstracts (or could
put together one) for the entries in the biblio, it
would really be appreciated. Abstracts would make the
bibliography much more useful. [Any takers ??]
o Happy Scheming...
The latest addition to the biblio (included in the diff)
%A Olin Shivers
%T Control Flow Analysis in Scheme
%J Proceedings of the Sigplan 1988 Conterence on Programming Language
Design and Implementation
%P 164-174
%C Atlanta, Georgia
%D June 1988
%K schflow
Abstract:
Traditional flow analysis techniques, such as the ones typically
employed by optimizing Fortran compilers do not work for Scheme-like
languages. This paper presents a flow analysis technique - control flow
analysis - which is applicable to Scheme-like languages.
=============== updates for scheme.bib
*** scheme.bib Fri Sep 2 12:51:53 1988
--- scheme.bib.new Fri Sep 2 12:25:21 1988
***************
*** 35,40 ****
--- 35,41 ----
%P 153-162
%I ACM
%D 1977
+ %K ultimate
%A Guy Lewis Steele, Jr.
%T Macaroni is Better than Spaghetti
***************
*** 43,48 ****
--- 44,50 ----
%P 60-66
%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64
%D August 1977
+ %K macaroni
%A Mitchell Wand
%T Continuation-Based Program Transformation Strategies
***************
*** 52,57 ****
--- 54,68 ----
%P 174-180
%D 1978
+ %A Mitchell Wand
+ %A Daniel P. Friedman
+ %T Compiling lambda expressions using continuations and
+ factorizations
+ %J Journal of Computer Languages
+ %V 3
+ %P 241-263
+ %D 1978
+
%A Guy Lewis Steele, Jr.
%A Gerald Jay Sussman
%T The Revised Report on Scheme, a Dialect of Lisp
***************
*** 58,63 ****
--- 69,75 ----
%R MIT Artificial Intelligence Memo 452
%C Cambridge, Mass.
%D January 1978
+ %K r-report
%A Guy Lewis Steele, Jr.
%T Rabbit: a Compiler for Scheme
***************
*** 64,69 ****
--- 76,82 ----
%R MIT Artificial Intelligence Laboratory Technical Report 474
%C Cambridge, Mass.
%D May 1978
+ %K rabbit
%A Guy Lewis Steele, Jr.
%A Gerald Jay Sussman
***************
*** 74,79 ****
--- 87,99 ----
%D May 1978
%K modularity
+ %A Uwe F. Pleban
+ %T The Standard Semantics of a Subset of SCHEME, a Dialect of LISP
+ %R Computer Science Technical Report TR-79-3
+ %I University of Kansas
+ %C Lawrence, Kansas
+ %D July 1979
+
%A Drew McDermott
%T An Efficient Environment Allocation Scheme in an Interpreter
for a Lexically-Scoped Lisp
***************
*** 91,96 ****
--- 111,124 ----
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
+ %A Uwe F. Pleban
+ %T A Denotational Approach to Flow Analysis and Optimization of
+ SCHEME, A Dialect of LISP
+ %R Ph.D. Dissertation
+ %I University of Kansas
+ %C Lawrence, Kansas
+ %D 1980
+
%A Guy Lewis Steele, Jr.
%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
%B AI: An MIT Perspective
***************
*** 99,104 ****
--- 127,133 ----
%I MIT Press
%C Cambridge, Mass.
%D 1980
+ %K rename+goto
%A Guy Lewis Steele, Jr.
%A Gerald Jay Sussman
***************
*** 107,112 ****
--- 136,142 ----
%P 163-172
%I The Lisp Conference
%D 1980
+ %K lazy
%A Mitchell Wand
%T Continuation-Based Multiprocessing
***************
*** 135,140 ****
--- 165,171 ----
%P 10-21
%D July 1981
%I IEEE
+ %K scheme79
%A John Batali
%A Edmund Goodhue
***************
*** 164,169 ****
--- 195,201 ----
Functional Programming
%P 114-122
%D 1982
+ %K T
%A Gerald Jay Sussman
%T LISP, Programming and Implementation
***************
*** 202,207 ****
--- 234,240 ----
%C Bloomington, Indiana
%D February 1983
%O Superceded by Computer Science Technical Report 153, 1985
+ %K scheme311
%A William Clinger
%T The Scheme 311 compiler: An Exercise in Denotational Semantics
***************
*** 209,215 ****
Functional Programming
%P 356-364
%D 1984
! %K comp311
%A Daniel P. Friedman
%A Christopher T. Haynes
--- 242,248 ----
Functional Programming
%P 356-364
%D 1984
! %K compile311
%A Daniel P. Friedman
%A Christopher T. Haynes
***************
*** 261,276 ****
--- 294,319 ----
%I S. B. Thesis, MIT Department of Electrical Engineering and Computer
Science
%D January 1984
+ %K liar
+ %A Richard Schooler
+ %A James W. Stamos
+ %T Proposal For a Small Scheme Implementation
+ %R MIT Lab for Computer Science Memo TM-267
+ %C Cambridge, Mass.
+ %D October 1984
+
%T MIT Scheme Manual, Seventh Edition
%I Department of Electrical Engineering and Computer Science, MIT
%C Cambridge, Mass.
%D September 1984
+ %K mitscheme
%T MacScheme Reference Manual
%I Semantic Microsystems
%C Sausalito, Calif.
%D 1985
+ %K macscheme
%A Harold Abelson
%A Gerald Jay Sussman
***************
*** 279,285 ****
%I MIT Press
%C Cambridge, Mass.
%D 1985
! %K sicp
%A William Clinger
%A Daniel P. Friedman
--- 322,328 ----
%I MIT Press
%C Cambridge, Mass.
%D 1985
! %K siocp
%A William Clinger
%A Daniel P. Friedman
***************
*** 450,455 ****
--- 493,499 ----
%P 151-161
%D August 1986
%O To appear in Lisp and Symbolic Computation
+ %K hygienic
%A Mitchell Wand
%T The mystery of the tower revealed: a non-reflective
***************
*** 457,462 ****
--- 501,507 ----
%J Proceedings of the 1986 ACM Symposium on LISP and Functional Programming
%P 298-307
%D August 1986
+ %K tower
%E Jonathan A. Rees
%E William Clinger
***************
*** 465,470 ****
--- 510,516 ----
%V 21
%N 12
%D December 1986
+ %K rrrrs
%A Christopher T. Haynes
%T Logic Continuations
***************
*** 544,554 ****
%P 206-223
%D 1987
- %T A syntactic theory of sequential control
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%J Theoretical Computer Science
%V 52
%P 205-237
--- 590,600 ----
%P 206-223
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
+ %T A syntactic theory of sequential control
%J Theoretical Computer Science
%V 52
%P 205-237
***************
*** 571,576 ****
--- 617,623 ----
%P 109-121
%I Pergamon Press
%D 1987
+ %K engines
%A Matthias Felleisen
%T The Calculi of lambda-v-cs conversion: a syntactic
***************
*** 608,616 ****
%C Bloomington, Indiana
%D October 1987
- %T Embedding continuations in procedural objects
%A Christopher T. Haynes
%A Daniel P. Friedman
%J ACM Transactions on Programming Languages and Systems
%V 9
%N 4
--- 655,663 ----
%C Bloomington, Indiana
%D October 1987
%A Christopher T. Haynes
%A Daniel P. Friedman
+ %T Embedding continuations in procedural objects
%J ACM Transactions on Programming Languages and Systems
%V 9
%N 4
***************
*** 671,676 ****
--- 718,724 ----
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
+ %K macrology
%A Matthias Felleisen
%A Mitchell Wand
***************
*** 683,688 ****
--- 731,745 ----
%C Salt Lake City, Utah.
%D July 1988
+ %A Olin Shivers
+ %T Control Flow Analysis in Scheme
+ %J Proceedings of the Sigplan 1988 Conterence on Programming Language
+ Design and Implementation
+ %P 164-174
+ %C Atlanta, Georgia
+ %D June 1988
+ %K schflow
+
%A John Franco
%A Daniel P. Friedman
%T Creating Efficient Programs by Exchanging Data for Procedures
***************
*** 690,700 ****
%I Indiana University
%C Bloomington, Indiana
%D March 1988
-
- %A Mitchell Wand
- %A Daniel P. Friedman
- %T Compiling lambda expressions using continuations and
- factorizations
- %J Computer Languages 3
- %D 241-263
- %D 1978
--- 747,749 ----
oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂04-Sep-88 1112 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU named let -> ???
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Sep 88 11:12:31 PDT
Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU 4 Sep 88 14:11:17 EDT
Received: by MURREN.AI.MIT.EDU; Sun, 4 Sep 88 14:08:05 edt
Date: Sun, 4 Sep 88 14:08:05 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809041808.AA11117@murren>
To: gls@Think.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: gls@Think.COM's message of Fri, 2 Sep 88 13:34:53 EDT <8809021734.AA08862@joplin.think.com>
Subject: named let -> ???
Reply-To: hal@zurich.ai.mit.edu
Let's get this straight:
The name of it is called "`named let'".
The name of it actually is "named-let".
But it is called "named let".
And it actually *is* "(defmacro named-let (name bindings . body) ...)"?
--Guy
Yes, that's right. Also, if if we optionally allow the current syntax
(let <name> <bindings> . <body>)
then the name of it could also be called "a named form of let".
∂04-Sep-88 1124 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU problems with named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Sep 88 11:23:54 PDT
Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU 4 Sep 88 14:20:11 EDT
Received: by MURREN.AI.MIT.EDU; Sun, 4 Sep 88 14:16:36 edt
Date: Sun, 4 Sep 88 14:16:36 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809041816.AA11136@murren>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: problems with named-let
Reply-To: hal@zurich.ai.mit.edu
Your mail mentioned "other problems with named let" besides the
overloading of LET. I thought that this was the major objection. What
are some others? I'm curious about this, since I'm guessing that it
has to do with how you introduce it to students and I'd like to know.
How do you feel about calling this TAG or LABEL? I don't like RECUR
since it sounds too much like "recursion". Pedagogically, I feel
nervous about naming this construct something that implies that it is
evolves a particular "shape" of process, such as recursion or
iteration. I do like LABEL or TAG or NAMED-LET because it draws
attention the fact that something is being named, which for students
is a nice point.
-- Hal
∂04-Sep-88 2249 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: problems with named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Sep 88 22:49:41 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Sep 88 00:58:15 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Sun, 4 Sep 88 23:55:40 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: hal@ZURICH.AI.MIT.EDU
Subject: Re: problems with named-let
Cc: rrrs-authors@mc.lcs.mit.edu
> From: Hal Abelson <hal@murren.ai.mit.edu>
> Subject: problems with named-let
> Your mail mentioned "other problems with named let" besides the
> overloading of LET. I thought that this was the major objection. What
> are some others? I'm curious about this, since I'm guessing that it
> has to do with how you introduce it to students and I'd like to know.
It has to do with the more serious issue of abstraction that I talked
about in an earlier note, all or most of which applies equally well to
"named-let" as to "let" because "named-let" is called "named let".
> How do you feel about calling this TAG or LABEL? I don't like RECUR
> since it sounds too much like "recursion". Pedagogically, I feel
> nervous about naming this construct something that implies that it is
> evolves a particular "shape" of process, such as recursion or
> iteration. I do like LABEL or TAG or NAMED-LET because it draws
> attention the fact that something is being named, which for students
> is a nice point.
I believe that anything we can do to emphasize that iteration is a
special case of recursion is ultimately to the benefit of the student.
This is one of the main reasons I like "recur". I can see why you
think it is beneficial to draw attention to the fact that something is
being named, but I think it is far more important that the name
describe what the entire form (usually) does. It is clear that the
entire form usually performs some sort of recursion, so "label", "tag",
and "named-let" are all inappropriate.
Kent
∂04-Sep-88 2312 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Scheme standard group: anything happening ??
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Sep 88 23:12:28 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 Sep 88 02:07:20 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA03308@BLOOM-BEACON.MIT.EDU>; Mon, 5 Sep 88 01:50:51 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Sep 88 16:54:19 GMT
From: mnetor!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Scheme standard group: anything happening ??
Message-Id: <851@yunexus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Isn't there supposed to be a "scheme standard" group formed and
working ?? What is happening with it ?? When would there be a working
paper, some progress report, something ?? It has been quite a while
since we heard [April 8] about its formation. Chris Haynes,
Will Clinger: What is cooking ??
oz
--
Crud that is not paged | Usenet: ...!utzoo!yunexus!oz
is still crud. | ...uunet!mnetor!yunexus!oz
andrew@alice | Bitnet: oz@[yulibra|yuyetti]
| Phonet: +1 416 736-5257x3976
∂05-Sep-88 1345 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu problems with named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 88 13:45:02 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 5 Sep 88 16:43:32 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa09493; 5 Sep 88 16:40 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id ac00385;
5 Sep 88 16:23 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
id AA13838; Mon, 5 Sep 88 12:00:04 edt
Date: Mon, 5 Sep 88 12:00:04 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Mon, 5 Sep 88 12:00:04 edt
To: hal.2@cs.brandeis.edu
Cc: dyb.2@cs.brandeis.edu, rrrs-authors.2@cs.brandeis.edu
In-Reply-To: Hal Abelson's message of Sun, 4 Sep 88 14:16:36 edt <8809041816.AA11136@murren>
Subject: problems with named-let
Two other naming suggestions: NAMED
or (gasp)
(NAMED <symbol> LET <bindings> . <body>)
--Jim
∂05-Sep-88 1530 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu Re: problems with named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 88 15:30:23 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 5 Sep 88 18:29:00 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
To: rrrs-authors@mc.lcs.mit.edu
Path: iuvax!chaynes
From: chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Sender: chaynes@iuvax.cs.indiana.edu
Newsgroups: cs.scheme.rrrs
Subject: Re: problems with named-let
Message-Id: <12416@iuvax.cs.indiana.edu>
Date: 5 Sep 88 20:54:29 GMT
References: <33000313@iuvax> <33000314@iuvax>
Reply-To: iuvax!chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Organization: Indiana University CSCI, Bloomington
I agree with Kent that we should view iteration as a special case of
recursion, and there is a precedent for this: the REC in LETREC. This
makes RECUR especially appropriate, since it is just a sugared LETREC.
Though RECUR is my choice of all the names for named let I've heard so
far, I'm not as opposed to NAMED-LET as Kent is.
Personally, I've always found named LET natural and use it a lot in
"private" code, though I never like the syntax overloading it
involves. However, I too have had difficulty explaining it to others,
so I avoid it in code students may see. I also respect the opinions
of others who have had much more experience trying to teach it than I,
and most of them have had substantial difficulty teaching it.
I'm willing to keep the named let behavior of LET if it is a necessary
compromise to add a new name for it, but I find having both in the
language distastful. It inevitably resuls in confusion, and makes our
problems a part of our legacy. In a number of other cases where we've
allowed two names for the same thing as a compromise we've eventually
ended up flushing one of them.
∂05-Sep-88 1708 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu minutes from Utah
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 88 17:08:50 PDT
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 5 Sep 88 20:07:09 EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Mon, 5 Sep 88 17:05:34 PDT
Received: by fog.cs.uoregon.edu; Mon, 5 Sep 88 17:05:27 PDT
Date: Mon, 5 Sep 88 17:05:27 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8809060005.AA04174@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: minutes from Utah
I'm sorry I haven't yet typed up my minutes for posting to this group.
Excuses: I've moved from Hillsboro to Eugene, sold a house, taken a
vacation, and so forth. I'm getting settled now and should be able to
post the minutes within a few days, by which time I should have learned
how to use this mail system and editor.
Speaking of mail, complaints and other communications should be sent to
my new electronic mail address:
will@cs.uoregon.edu
Electronic mail sent to my old address at Tektronix will probably get to
me eventually, but everyone will be happier if you use the new address.
Peace, William Clinger
∂06-Sep-88 1402 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@buacca.BITNET Seminar announcement
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 14:01:57 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 6 Sep 88 16:41:44 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3432; Tue, 06 Sep 88 16:39:24 EDT
Received: from BUACCA.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id
3431; Tue, 06 Sep 88 16:39:23 EDT
Received: by BUACCA (Mailer X1.25) id 6261; Tue, 06 Sep 88 16:40:01 EDT
Date: Tue, 06 Sep 88 16:38:54 EDT
From: "Peter Mager" <met9i7n%BUACCA.BITNET@MITVMA.MIT.EDU>
Subject: Seminar announcement
To: scheme@mc.lcs.mit.edu,met9i7n@buacca
The following seminar may be of interest to you.
ACM GREATER BOSTON CHAPTER SICPLAN
Thursday, September 8, 1988
8 P.M.
Bolt Beranek and Newman, Newman auditorium
70 Fawcett St., Cambridge
Parallel Symbolic Computing Using Multilisp
Robert H. Halstead, Jr.
Laboratory for Computer Science
MIT
Multilisp is an extension of the Lisp dialect Scheme with
additional operators and additional semantics for parallel
execution. The principal parallelism construct in Multilisp is the
"future," which exhibits some features of both eager and lazy
evaluation. Multilisp has been implemented, and runs on the
shared-memory Concert multiprocessor, using as many as 34
processors. The implementation uses interesting techniques for task
scheduling and garbage collection. The task scheduler helps control
excessive resource utilization by means of an unfair scheduling
policy; the garbage collector uses a multiprocessor algorithm
modeled after the incremental garbage collector of Baker.
Current work focuses on making Multilisp a more humane programming
environment, on expanding the power of Multilisp to express task
scheduling policies, and on measuring the properties of Multilisp
programs with the goal of designing a parallel architecture well
tailored for efficient Multilisp execution. The talk will briefly
describe Multilisp, discuss the areas of current activity, and
outline the direction of the Multilisp project with special
attention to the areas of task scheduling and architecture design.
ACM GREATER BOSTON CHAPTER SICPLAN
Dear Colleague,
Our September speaker, Bert Halstead, is Associate Professor of
Computer Science and Engineering at MIT's Laboratory for Computer
Science. He is best known for pioneering Lisp multiprocessing and
the concept of futures.
Larry Snyder's talk last month showed us a programming
environment that supports multiprocessing and explained some
capabilites that can help make such environments more useful. Two
local conferences this month are addressing similar issues of
computer support for software engineering and parallel
programming. CASE '88 was held at the Hyatt Hotel in Cambridge
July 12-14. Contact Pam Meyer at Intek 494-8200 x1988 for
information about proceedings. PPEALS, the ACM/SIGPLAN conference
on Parallel Programming: Experience with Applications, Languages,
and Systems will be held in New Haven, Conn. July 17-19. Contact
Bill Gropp or Judy Terrell at Yale University, Dept. of Computer
Science 203-432-1200. Both are said to have outstanding technical
programs.
Other talks currently planned include:
- Tim Teitelbaum on "What's New with the Cornell Synthesizer" in
November,
- Mayer Schwartz on the use of hypertext in software development
support systems in December,
- and
- Reidar Conradi on the Trondheim programming environment in
January.
In addition, we are planning a full day PDS seminar on code
generation techniques, tentatively scheduled for Saturday, October
15. The main speaker will be Professor Robert Henry from the
University of Washington, who will give a somewhat extended version
of the tutorial he gave at the SIGPLAN '88 conference in Atlanta,
with emphasis on extending Graham Glanville techniques. In
addition, we are inviting leading compiler experts from Apollo,
DEC, U. Mass. Boston and other places to discuss alternative
techniques and current problems and issues including interaction of
register allocation and optimization with code generation and use
of dynamic programming and constraint rules to improve code
generation efficiency.
We will be meeting for dinner as usual at Joyce Chen's
restaurant, 390 Rindge Ave., Cambridge at 6:00 p.m. before the
meeting. If you wish to come, please call Karen Kelley or "Sigplan
dinner" at Intermetrics (661-1840) as early as possible so we can
make the appropriate dinner reservation.
Peter Mager
chairperson, Boston SICPLAN
∂06-Sep-88 1937 @MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu Compromise
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Sep 88 19:37:13 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 6 Sep 88 22:05:59 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Tue, 6 Sep 88 21:03:25 EST
From: George Springer <springer@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Compromise
On Aug. 26, Gerry sent the following:
Perhaps the correct stance is that the existing named let syntax
continue to be supported for those who like it and a new special form
be allocated for those who would like an alternative that they find
more appropriate for their teaching style.
I generally don't like allocating reserved words, but sometimes I
think it is necessary to compromise on such an issue. Why not have
Kent and George choose their favorite, and we can all agree not to
argue too strongly about it.
Please pick a pretty name that is not likely to conflict with anyone's
current usage. Thank you.
After looking at all of the names suggested, I think recur is the one
that I choose. Kent strongly agrees with this proposal. Kent gave a
persuasive rationale for selecting recur and I concur with him. Can
we now go along with Gerry's suggestion for compromise?
∂07-Sep-88 0720 @MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU demur on recur
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 07:20:27 PDT
Received: from murren (TCP 2212600263) by MC.LCS.MIT.EDU 7 Sep 88 10:18:04 EDT
Received: by MURREN.AI.MIT.EDU; Wed, 7 Sep 88 10:14:09 edt
Date: Wed, 7 Sep 88 10:14:09 edt
From: hal@MURREN.AI.MIT.EDU (Hal Abelson)
Message-Id: <8809071414.AA17305@murren>
To: springer@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: George Springer's message of Tue, 6 Sep 88 21:03:25 EST
Subject: demur on recur
Reply-To: hal@zurich.ai.mit.edu
I'm sorry to be cantankerous , but I really do not like the name RECUR.
I think it is setting up a pedgogical trap.
In my experience teaching programming, one of the things I find that I
need to overcome is students' tendency to confuse control structures
with particular syntactic keywords. For example, many of then think
(possibly to due to Pascal-itis) that "iteration" means DO or WHILE.
This is a natural mistake for people to make, because general shapes
of process evolution (such as iteration or recursion) are much more
abstract than visible keywords, so it becomes easy to latch onto the
keywords and forget about the processes.
This is part of the reason why Gerry and I, in writing SICP, did not
use DO or any other iteration construct. Where Kent says that he
wants students to realize that "iteration is a special case of
recursion" I am more concerned that they realize that "both iteration
and recursion are special cases of ordinary procedure invocation",
that is, that there is no magic going on in these constructs and that
once the interpreter can handle procedure invocation, all the rest is
syntactic sugar.
My objection to RECUR is that it is setting up a trap for students to
think that recursion is something that is done with RECUR. I can
easily imagine some of them getting into a state where they believe
that there are two kinds of recursion: a "simple" one that is done
with RECUR, and a "general" one that is done with ordinary function
calling; and will somehow think that the interpreter handles these in
different ways.
So I am all in favor of getting rid of overloading the LET keyword --
as George said, puns cause confusion. But let's not replace this with
a worse confusion. Let's pick a name that does not imply any
particular control structure.
∂09-Sep-88 0204 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu Compromise
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 02:04:17 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Sep 88 03:06:21 EDT
Received: from RELAY.CS.NET by XX.LCS.MIT.EDU with TCP/SMTP; Thu 8 Sep 88 03:05:07-EDT
Received: from relay2.cs.net by RELAY.CS.NET id ab16872; 7 Sep 88 20:15 EDT
Received: from cs.brandeis.edu by csnet-relay.CS.NET id aa17053;
7 Sep 88 19:33 EDT
Received: by cs.brandeis.edu (13.1/6.0.GT)
id AA25421; Wed, 7 Sep 88 08:51:27 edt
Date: Wed, 7 Sep 88 08:51:27 edt
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Wed, 7 Sep 88 08:51:27 edt
To: springer.2@cs.brandeis.edu
Cc: rrrs-authors.2@cs.brandeis.edu
In-Reply-To: George Springer's message of Tue, 6 Sep 88 21:03:25 EST <8809070236.AA17037@zurich>
Subject: Compromise
PLEASE, NO!!! My understanding of the evolving discussion was that
named let was perceived by most participants as a binding construct,
and the proposed name does not reflect that. I point out that the
Scheme community did NOT pick the name letrec (used in an argument
favoring "recur"); it was chosen by the mathematical logic/computer
theory community long before its introduction into Scheme and has a
very specific technical meaning of which the Scheme version is a
modified instance. I, at least, agreed to that name because of its
accord with established mathematical convention. I believe that
"recur" does NOT have such a justification and leads to the
misunderstanding that the form has something to do with recursion --
in the sense of process rather than procedure -- a perception that we
should NOT reinforce.
Sorry.
--Jim
∂09-Sep-88 0204 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Intermediate Lambda Calculus --> Machine code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 02:04:32 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Sep 88 05:24:20 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 8 Sep 88 05:23:09-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA11036@BLOOM-BEACON.MIT.EDU>; Thu, 8 Sep 88 05:18:54 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Sep 88 17:53:22 GMT
From: pasteur!agate!saturn!venus.ucsc.edu!kjell@ames.arpa (Kjell Post)
Organization: University of California, Santa Cruz; CIS/CE
Subject: Intermediate Lambda Calculus --> Machine code
Message-Id: <4742@saturn.ucsc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am looking for articles, books etc that describes various ways
of compiling intermediate lambda calculus (eg, produced by a
compiler for a functional language or a denotational description
of any programming language) to real machine code. The work that
I've seen usually employs some abstract machine (SECD, G, CAM etc)
or relies on a selected set of combinators (Wand, Sethi).
Email please. Thanks.
-------------------------------------------------------------------------------
Y F = F(Y F) ! Kjell Post, Dept of Comp & Info Sciences
"This superamazing, clever thing" ! University of California, Santa Cruz
-- G.J.Sussman ! Email: kjell@saturn.ucsc.edu
∂09-Sep-88 0205 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Intermediate Lambda Calculus --> Machine code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 02:04:51 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 8 Sep 88 14:24:36 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 8 Sep 88 14:25:14-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA22048@BLOOM-BEACON.MIT.EDU>; Thu, 8 Sep 88 14:21:13 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Sep 88 17:48:37 GMT
From: jeschke@iuvax.cs.indiana.edu (Eric Jeschke)
Organization: Indiana University CSCI, Bloomington
Subject: Re: Intermediate Lambda Calculus --> Machine code
Message-Id: <12502@iuvax.cs.indiana.edu>
References: <4742@saturn.ucsc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
"The Implementation of Functional Programming Languages" by Simon
Peyton-Jones is a good book for this. It basically describes the
state-of-the-art in sequential implementations: pattern matching, typing,
optimization and supercombinator generation.
There is a very thorough treatment of the lambda calculus spanning several
chapters. I highly recommend it.
Eric
--
Eric
jeschke@iuvax.cs.indiana.edu
Gimme shelter.
∂09-Sep-88 0352 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Intermediate Lambda Calculus --> Machine code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 03:52:47 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Sep 88 06:38:35 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA11245@BLOOM-BEACON.MIT.EDU>; Fri, 9 Sep 88 06:25:52 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Sep 88 20:45:29 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: Re: Intermediate Lambda Calculus --> Machine code
Message-Id: <2718@uoregon.uoregon.edu>
References: <4742@saturn.ucsc.edu>, <12502@iuvax.cs.indiana.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <12502@iuvax.cs.indiana.edu> jeschke@iuvax.UUCP (Eric Jeschke) writes:
>
> "The Implementation of Functional Programming Languages" by Simon
>Peyton-Jones is a good book for this. It basically describes the
>state-of-the-art in sequential implementations: pattern matching, typing,
>optimization and supercombinator generation.
>There is a very thorough treatment of the lambda calculus spanning several
>chapters. I highly recommend it.
I was going to recommend this book as well. A MUST-HAVE for you
shelf if you are at all interested in compiling declarative
languages. More raw brainpower went into this book than you
could find in 1000 hours at a library. It is well organized (in
spite of several chapters being written by different authors)
and very thorough.
This book encouraged me to pursue a Master's thesis in the topic
of parallel implementation of functional languages based upon
the lambda calculus.
mark vandewettering
∂09-Sep-88 1444 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU "DEFLET"?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Sep 88 14:44:14 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 9 Sep 88 17:09:35 EDT
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 133680; Fri 9-Sep-88 17:09:23 EDT
Date: Fri, 9 Sep 88 17:09 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: "DEFLET"?
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8809071414.AA17305@murren>
Message-ID: <19880909210910.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
I would also like to object to the name "RECUR", and for the same reasons
given by Hal.
The "REC" in the name "LETREC" bothers me somewhat too, but in that case
the name at least suggests that it is the LETing that is recursive, rather
than any control structure.
I would prefer a name that emphasizes the naming aspect. My personal
choice would be "LABEL", since that name was onced used in Lisp for a
similar construct, but I understand the objections. Here are some naming
related word that I just pulled out of my thesaurus:
ALIAS APPELATION CALLED
DUB ENTITLE IDENTIFY
MONIKER TAG TITLE
Anybody feel inspired? You can try constructing names with these as roots.
How about "DUBBED-LET"? "LET-CALLED"? (I kind of like just "MONIKER"...)
Taking another direction, how about a name that emphasizes that the thing
is a combination of LET and DEFINE? Like "DEFLET"?
∂10-Sep-88 0231 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:adams@tekchips.crl re- named-let
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Sep 88 02:30:52 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Sep 88 05:28:26 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04362; 10 Sep 88 5:19 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa06499; 10 Sep 88 4:59 EDT
Received: by tektronix.TEK.COM (5.51/6.24)
id AA09737; Sat, 10 Sep 88 01:17:12 PDT
Received: by tekchips.CRL.TEK.COM (5.51/6.24)
id AA21652; Sat, 10 Sep 88 01:18:41 PDT
Date: Sat, 10 Sep 88 01:18:41 PDT
From: Norman Adams <adams@tekchips.crl>
Message-Id: <8809100818.AA21652@tekchips.CRL.TEK.COM>
Subject: re- named-let
To: rrrs-authors@mc.lcs.mit.edu
Maybe the important thing about NAMED-LET is self-application.
And in light of all the recent thrashing on this topic,
I like the sound of "WHY-LET", or just "WHY".
If you consider NAMED-LET as a pretty face for the simplest uses of the Y
operator, then you might like the name "Y0". (That is why-zero, but
if you mistake the zero for an oh, and you think your reading Spanish,
it still makes sense.) Squint your eyes, and you've got "WHYNOT".
-Norman
-------
∂11-Sep-88 1353 @MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU Re: "DEFLET"?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Sep 88 13:53:07 PDT
Received: from VX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 SEP 88 16:49:32 EDT
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA00716@VX.LCS.MIT.EDU>; Sun, 11 Sep 88 16:52:58 edt
Date: Sun, 11 Sep 88 16:52:58 edt
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: Alan@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: "DEFLET"?
I like something like CALLED-LET, as Alan suggested. This has the distinct
advantage of having a double meaning: it means both that the LETed construct
is named (CALLED something) and that it is invoked (CALLED, as APPLIED).
A more concise naming cannot be imagined. <<Vive le double entendre!>>
~Ziggy
∂12-Sep-88 0523 @MC.LCS.MIT.EDU,@RELAY.CS.NET:SEB1525@draper.com Lambda Calculus Books
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Sep 88 05:23:08 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Sep 88 08:18:00 EDT
Received: from relay2.cs.net by RELAY.CS.NET id aa23449; 12 Sep 88 8:12 EDT
Received: from draper.com by RELAY.CS.NET id ad14648; 12 Sep 88 8:06 EDT
Date: Mon, 12 Sep 88 07:20 EDT
From: "Steve Bacher (Batchman)" <SEB1525%draper.com@RELAY.CS.NET>
Subject: Lambda Calculus Books
To: scheme@mc.lcs.mit.edu
X-VMS-To: SCHEME
From: CCFVX3::SEB1525 "Steve Bacher (Batchman)" 12-SEP-1988 07:12
To: IN%"jeschke@iuvax.cs.indiana.EDU",SEB1525
Subj: RE: Re: Intermediate Lambda Calculus --> Machine code
Would you say that Alonzo Church's book on lambda calculus is a
prerequisite to the Peyton-Jones book? Or is it reasonable to dig in
without a thorough background in lambda calculus?
(John McCarthy once admitted that he had understood only a small part of
Church's lambda calculus prior to inventing Lisp - he didn't read the
whole book.)
∂12-Sep-88 0744 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Lambda Calculus Books
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Sep 88 07:44:21 PDT
Received: from zohar (TCP 2206400256) by MC.LCS.MIT.EDU 12 Sep 88 10:39:25 EDT
Received: by ZOHAR.AI.MIT.EDU; Mon, 12 Sep 88 10:46:13 edt
Date: Mon, 12 Sep 88 10:46:13 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8809121446.AA07392@zohar>
To: SEB1525%draper.com@RELAY.CS.NET
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: "Steve Bacher (Batchman)"'s message of Mon, 12 Sep 88 07:20 EDT <8809121227.AA28967@zurich>
Subject: Lambda Calculus Books
Church's book is pretty irrelevent and unnecessary these days. If you
want something theoretical about Lambda Calculus read Stoy. You
certainly don't need anything more hairy than SICP to read
Peyton-Jones.
∂12-Sep-88 0852 @MC.LCS.MIT.EDU:windley@cheetah.ucdavis.edu Re: Lambda Calculus Books
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Sep 88 08:52:24 PDT
Received: from clover.ucdavis.edu (TCP 20036034401) by MC.LCS.MIT.EDU 12 Sep 88 11:47:17 EDT
Received: from cheetah.ucdavis.edu by clover.ucdavis.edu (5.59/4.7)
id AA09313; Mon, 12 Sep 88 08:41:26 PDT
Received: by cheetah.ucdavis.edu (AIX 2.2/3.14)
id AA01198; Mon, 12 Sep 88 08:45:06 PDT
Message-Id: <8809121545.AA01198@cheetah.ucdavis.edu>
To: scheme@mc.lcs.mit.edu
Subject: Re: Lambda Calculus Books
In-Reply-To: Your message of Mon, 12 Sep 88 10:46:13 -0500.
<8809121446.AA07392@zohar>
Date: Mon, 12 Sep 88 08:45:04 -0800
From: Phil Windley <windley@cheetah.ucdavis.edu>
I've seen a book by Barendregt (I think the spelling's right) on lambda
calculus. Is it any good?
Phil Windley | windley@iris.ucdavis.edu
Division of Computer Science | ucbvax!ucdavis!iris!windley
College of Engineering | (916) 752-7324 (or 3168)
University of California, Davis | Davis, CA 95616
∂12-Sep-88 1809 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Question on Combinator Reduction
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Sep 88 18:09:51 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Sep 88 20:54:39 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA09992@BLOOM-BEACON.MIT.EDU>; Mon, 12 Sep 88 20:51:53 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Sep 88 17:32:59 GMT
From: linus!watro@husc6.harvard.edu (Ronald J. Watro)
Organization: The MITRE Corp., Bedford, MA
Subject: Question on Combinator Reduction
Message-Id: <39820@linus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is there anywhere in the literature a correctness proof for
combinator reduction using the cyclic Y-rule, as described,
for example, in Peyton-Jones' book on implementing functional
languages? I have looked at several papers on Graph Rewriting,
including one by Barendregt et. al. in the 87 PARLE conference,
but I cannot find this result.
--
Dr. Ronald J. Watro The MITRE Corporation, MS A040, Burlington RD,
Bedford, MA 01730 USA 617-271-8390
ARPA: watro%linus@mitre-bedford.ARPA
UUCP: ...{decvax,utzoo,philabs,security,allegra,genrad}!linus!watro
∂13-Sep-88 0215 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Proceedings on Lisp and Functional Programming
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 02:15:11 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Sep 88 05:09:35 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA18098@BLOOM-BEACON.MIT.EDU>; Tue, 13 Sep 88 04:55:58 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Sep 88 17:35:08 GMT
From: agate!saturn!venus.ucsc.edu!kjell@presto.ig.com (Kjell Post,,,4238760)
Organization: University of California, Santa Cruz; CIS/CE
Subject: Proceedings on Lisp and Functional Programming
Message-Id: <4808@saturn.ucsc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
What is the procedure for obtaining the "Lisp and functional
Programming" proceedings from ACM?
Has there been four or five so far?
-------------------------------------------------------------------------------
Y F = F(Y F) ! Kjell Post, Dept of Comp & Info Sciences
"This superamazing, clever thing" ! University of California, Santa Cruz
-- G.J.Sussman ! Email: kjell@saturn.ucsc.edu
∂13-Sep-88 1332 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lambda Calculus Books
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 13:30:21 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Sep 88 15:54:48 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA00400@BLOOM-BEACON.MIT.EDU>; Tue, 13 Sep 88 15:44:46 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Sep 88 23:21:16 GMT
From: mailrus!umich!kfr@ohio-state.arpa (Karl F. Ruehr)
Organization: University of Michigan EECS Dept. Ann Arbor
Subject: Re: Lambda Calculus Books
Message-Id: <1147@zippy.eecs.umich.edu>
References: <8809121446.AA07392@zohar>, <8809121545.AA01198@cheetah.ucdavis.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
"The Lambda Calculus: its Syntax and Semantics", Henk Barendregt.
North-Holland (first edition, 1981; revised edition, 1984). Approx.
$35.00 in paperback (look in a library first).
This is the modern encyclopedic reference work on the lambda calculus
and combinatory logic. It is probably not of much use to anyone who
isn't really committed to deep study: the first 70 pages (of 611
total) are probably more than sufficient introduction for most needs,
and it does not generally address computer science-related issues.
A wonder of modern typography. Photographs of several famous
theorists. At least one fun exercise (6.8.14 on page 149.
"Introduction to Combinators and Lambda Calculus", Roger Hindley and
Jonathan Seldin. London Mathematical Society Student Texts #1,
Cambridge U. Press, 1986. Price unknown, but probably < $35.00.
This is a shorter, more relaxed introduction to the subject (not much
model theory, for example, though see Chapter 12). More suitable for
curiosity-seekers, but still not exactly oriented toward the computer
scientist specifically. Produced from typewriter proofs. Cute
Appendix # 3.
"The Calculi of Lambda Conversion", Alonzo Church. Princeton
University Press, 1941.
The original work (or very close to it) on lambda calculus (for
combinatory logic, see Curry & Feys' "Combinatory Logic" or
Schoenfinkel's work of 1924 (reprinted in "The Sourcebook for
Mathematical Logic" (title?))). Of mostly historical interest,
though not to be dismissed. Not much relevance to programming.
The only books/works I can think of that would be helpful for
functional language implementers, etc. would be:
-- the Peyton-Jones book mentioned in the original article;
-- perhaps a recent book by Glaser, Tinkin and Hill (the names are only
approximate); I haven't read the book, but I recall that it has a chapter
on lambda calculus. "Functional Programming" probably in title.
-- "Functional Programming" by Peter Henderson. Prentice-Hall,
"red-and-white binding series". Perhaps the best bet besides
Peyton-Jones.
-- "Recursive Programming Techniques" by Burge (a bit out of date, but
a real gold-mine of techniques, etc.
∂13-Sep-88 1605 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Implementation of functional languages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 16:04:47 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Sep 88 18:53:13 EDT
Date: Tue 13 Sep 88 18:35:03-EDT
From: Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>
Subject: Implementation of functional languages
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12430328726.19.NIKHIL@XX.LCS.MIT.EDU>
Here is a ``must read'' bibliography for those interested in modern implementations
of functional languages. Apologies for any omissions.
Nikhil
-------- CUT HERE ------------------
@inProceedings{
Appel87a,
key = "Appel, Andrew",
author = "Appel, Andrew and MacQueen, David B.",
title = "A Standard ML Compiler",
booktitle = "Proceedings of the Conference on Functional Programming
and Computer Architecture, Portland, Oregon",
year = 1987,
month = "September",
note = "Springer-Verlag LNCS 274",
annote = "Functional languages"
}
@inProceedings{
Argo88a,
key = "Argo, Guy",
author = "Argo, Guy",
title = "The G-TIM: a refined Three Instruction Machine",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)",
month = "September 5-8",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Augustsson84,
key = "Augustsson, Lennart",
author = "Augustsson, Lennart",
title = "A Compiler for Lazy ML",
booktitle = "Proc. 1984 ACM Conf. on Lisp and Functional Programming,
Austin, Texas",
organization = ACM,
year = 1984,
month = "August",
pages = "218-227",
annote = "Lambda-lifting, Super-Combinators"
}
@inProceedings{
Augustsson85,
key = "Augustsson, Lennart",
author = "Augustsson, Lennart",
title = "Compiling Pattern Matching",
booktitle = "Proc. 1985 Workshop on Implementations of
Functional Languages, Goteborg, Sweden",
organization = "Chalmers University of Technology",
year = 1985,
month = "February",
annote = "Lambda-lifting, Super-Combinators, ML"
}
@PhDThesis{
Augustsson87a,
key = "Augustsson, Lennart",
author = "Augustsson, Lennart",
title = "Compiling Lazy Functional Languages, Part II",
school = "Department of Computer Sciences,
Chalmers University of Technology",
address = "Goteborg, Sweden",
year = 1987,
annote = "LML, G-Machine, graph reduction"
}
@inProceedings{
Augustsson88a,
key = "Augustsson, Lennart",
author = "Augustsson, Lennart",
title = "The nu G-machine",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)",
month = "September 5-8",
year = 1988,
annote = "Parallel Graph Reduction, Lambda Calculus"
}
@inProceedings{
Bloss88a,
key = "Bloss, Adrienne",
author = "Bloss, Adrienne and Hudak, Paul and Young, Jonathan",
title = "Code Optimizations for Lazy Evaluation",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)",
month = "September 5-8",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Burn88a,
key = "Burn, Geoffrey L.",
author = "Burn, Geoffrey L.",
title = "{A Shared Memory Parallel G-machine Based on the Evaluation
Transformer Model of Computation}",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)",
month = "September 5-8",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Burn88b,
key = "Burn, Geoffrey L.",
author = "Burn, Geoffrey L.",
title = "{Developing a Distributed Memory Architecture for Parallel Graph Reduction}",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)",
month = "September 5-8",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Burn88c,
key = "Burn, Geoffrey L.",
author = "Burn, Geoffrey L., {Peyton Jones}, Simon L. and Robson, J.D.",
title = "{The Spineless G-Machine",
booktitle = "Proceedings of the ACM Conference on Lisp and Functional Programming,
Snowbird, Utah",
month = "July 25-27",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Cardelli84d,
key = "Cardelli, Luca",
author = "Cardelli, Luca",
title = "Compiling a Functional Language",
booktitle = "Proceedings of the ACM Conference on Lisp and Functional
Programming, Austin, Texas",
year = "1984",
month = "August 6-8",
pages = "208-217",
annote = "ML"
}
@inProceedings{
Clack86a,
key = "Clack, Chris",
author = "Clack, Chris and Peyton-Jones, Simon L.",
title = "The Four-Stroke Reduction Engine",
booktitle = "Proceedings of the 1986 ACM Conference on Lisp and Functional
Programming, Cambridge, Mass.",
year = 1986,
month = "August 4-6",
pages = "220-232",
annote = "parallel graph reduction"
}
@article{
Cousineau87,
key = "Cousineau, G and Curien, Pierre-Louis and Mauny, Michel",
author = "Cousineau, G and Curien, Pierre-Louis and Mauny, Michel",
title = "The Categorical Abstract Machine",
journal = "Science of Computer Programming",
volume = 8,
year = "1987",
pages = "173-202",
annote = "ML, CAM, Categorical Combinators"
}
@inProceedings{
Fairbairn85,
key = "Fairbairn, Jon",
author = "Fairbairn, Jon",
title = "Removing Redundant Laziness from Supercombinators",
booktitle = "Proc. 1985 Workshop on Implementations of
Functional Languages, Goteborg, Sweden",
organization = "Chalmers University of Technology",
year = 1985,
month = "February",
annote = "Ponder, strictness, lazy evaluation"
}
@inProceedings{
Fairbairn87a,
key = "Fairbairn87, Jon",
author = "Fairbairn, Jon and Wray, Stuart C.",
title = "TIM: A Simple, Lazy Abstract Machine to Execute Supercombinators",
booktitle = "Proceedings of the 1987 Functional Programming and
Computer Architecture Conference, Portland, Oregon",
year = 1987,
month = "September",
pages = "34-45",
annote = "non-strictness, continuations"
}
@inProceedings{
Goldberg86,
key = "Goldberg86, Benjamin and Hudak, Paul",
author = "Goldberg, Benjamin and Hudak, Paul",
title = "Alfalfa: Distributed Graph Reduction on a Hypercube Multiprocessor",
booktitle = "{Proceedings of the Workshop on Graph Reduction,
Santa Fe, New Mexico, USA,
(Springer-Verlag LNCS 279).}",
year = 1986,
month = "September/October",
pages = "94-113"
}
@inProceedings{
Goldberg88a,
key = "Goldberg, Benjamin",
author = "Goldberg, Benjamin",
title = "Buckwheat: Graph Reduction on a Shared Memory Multiprocessor",
booktitle = "{Proceedings of the 1988 ACM Conference on Lisp and Functional Programming,
Snowbird, Utah}",
year = 1988,
month = "July 25-27",
pages = "40-51"
}
@PhDThesis{
Goldberg88a,
key = "Goldberg, Benjamin",
author = "Goldberg, Benjamin",
title = "Multiprocessor Execution of Functional Programs",
school = "Department of Computer Science,
Yale University",
year = 1988,
annote = "Scheme, T"
}
@inProceedings{
Halstead84a,
key = "Halstead, Robert H.",
author = "Halstead, Robert H.",
title = "Implementation of Multilisp: Lisp on a Multiprocessor",
booktitle = "Proceedings of the ACM Conference on Lisp and Functional
Programming, Austin, Texas",
year = "1984",
month = "August 6-8",
pages = "9-17",
annote = "Scheme"
}
@inProceedings{
Hughes82,
key = "Hughes,R.J.M.",
author = "Hughes,R.J.M.",
title = "Super-Combinators",
booktitle = "Proc. 1982 ACM Symp. on Lisp and Functional Programming,
Pittsburgh, PA",
organization = "ACM",
year = 1982,
month = "August",
pages = "1-10",
annote = "Graph Reduction, functional languages"
}
@article{
Johnsson84,
key = "Johnsson,T.",
author = "Johnsson,T.",
title = "Efficient Compilation of Lazy Evaluation",
journal = "ACM SIGPLAN Notices",
volume = 19,
number = 6,
year = 1984,
month = "June",
pages = "58-69",
note = "Proc. ACM SIGPLAN '84 Symposium on Compiler Construction",
annote = "ML, lambda-lifting, super-combinators, G-machine"
}
@inProceedings{
Johnsson85,
key = "Johnsson, Thomas",
author = "Johnsson, Thomas",
title = "Lambda Lifting: Transforming Programs to Recursive Equations",
booktitle = "Springer-Verlag LNCS 201 (Proc. Functional Programming
Languages and Computer Architecture, Nancy, France)",
year = "1985",
month = "September",
annote = "ML, super-combinators, G-machine"
}
@inProceedings{
Johnsson86a,
key = "Johnsson86, Thomas",
author = "Johnsson, Thomas",
title = "Target Code Generation from G-Machine Code",
booktitle = "Proceedings of the Workshop on Graph Reduction,
Santa Fe, New Mexico, USA,
(Springer-Verlag LNCS 279).",
note = "(also Programming Methodology Group Report 39,
Department of Computer Science,
Chalmers University of Technology and University of Goteborg,
S-421 96 Goteborg, Sweden)",
year = "1986",
month = "September/October",
annote = "LML, functional languages"
}
@PhDThesis{
Johnsson88a,
key = "Johnsson, Thomas",
author = "Johnsson, Thomas",
title = "Compiling Lazy Functional Languages",
school = "Department of Computer Sciences,
Chalmers University of Technology",
address = "Goteborg, Sweden",
year = 1987,
annote = "LML, G-Machine, graph reduction"
}
@article{
Kranz86a,
key = "Kranz86, David",
author = "Kranz, David and Kelsey, R. and Rees, Jonathan
and Hudak, Paul and Philbin, J. and Adams, N.",
title = "{ORBIT: An Optimizing Compiler for Scheme}",
journal = "ACM SIGPLAN Notices",
year = 1986,
volume = 21,
number = 7,
pages = "219-233",
month = "July",
note= "(Proceedings of the {SIGPLAN} 86 Symposium on Compiler Construction)",
annote = "Lisp, functional languages"
}
@PhDThesis{
Kranz88a,
key = "Kranz, David",
author = "Kranz, David",
title = "ORBIT: An Optimizing Compiler for Scheme",
school = "Department of Computer Science,
Yale University",
year = 1988,
annote = "Scheme, T"
}
@article{
Landin64,
key = "Landin, Peter J.",
author = "Landin, Peter J.",
title = "The Mechanical Evaluation of Languages",
journal = "Computer Journal",
volume = 6,
number = 4,
year = 1964,
month = "January",
pages = "308-320",
annote = "ISWIM, applicative languages, SECD machines"
}
@inProceedings{
Peyton-Jones85,
key = "Peyton Jones, Simon L.",
author = "{Peyton Jones}, Simon L. and Clack,C. and Harris,N.",
title = "GRIP - a Parallel Graph Reduction Machine",
booktitle = "Proc. 1985 Workshop on Implementations of
Functional Languages, Goteborg, Sweden",
organization = "Chalmers University of Technology",
year = 1985,
month = "February",
annote = "Combinators"
}
@Book{
Peyton-Jones87a,
key = "Peyton Jones87, Simon L.",
author = "{Peyton Jones}, Simon L."
title = "The Implementation of Functional Programming Languages",
publisher = "Prentice Hall",
year = 1987,
annote = "Combinators, G-Machine"
}
@inProceedings{
Peyton-Jones87b,
key = "Peyton Jones87, Simon L. and Clack, Chris and Salkild, Jon and Hardie, Mark ",
author = "{Peyton Jones}, Simon L. and Clack, Chris and Salkild, Jon and Hardie, Mark ",
title = "{GRIP -- A High Performance Architecture for Parallel Graph Reduction}",
booktitle = "{Proceedings of the 3rd. International Conference on
Functional Programming and Computer Architecture, Portland, Oregon}",
year = "1987",
month = "September",
annote = "Combinators, G-Machine"
}
@misc{
Peyton-Jones87c,
key = "Peyton Jones, Simon L.",
author = "{Peyton Jones}, Simon L.",
title = "{The tag is dead -- long live the packet}",
month = "October 22",
year = 1987,
note = "Note to FP e-mailing list",
annote = "Graph Reduction, Lambda Calculus"
}
@article{
Peyton-Jones88a,
key = "Peyton Jones, Simon L.",
author = "{Peyton Jones}, Simon L.",
title = "{FLIC --- a Functional Language Intermediate Code}",
journal = "ACM SIGPLAN Notices",
volume = 23,
number = 8,
year = 1988,
month = "August",
pages = "30-48",
note = "Also: Internal Note 2048,
Department of Computer Science, University College London,
Gower St., London WC1E 6BT",
annote = "Graph Reduction, Lambda Calculus"
}
@inProceedings{
Peyton-Jones88b,
key = "Peyton Jones, Simon L.",
author = "{Peyton Jones}, Simon L.",
title = "{The Spineless Tagless G-machine}",
booktitle = "Proceedings of the Workshop on Implementation of Lazy
Functional Languages, Aspenas, Sweden (to appear)"
month = "September 5-8",
year = 1988,
annote = "Graph Reduction, Lambda Calculus"
}
@techreport{
Steele78c,
key = "{Steele Jr.}, Guy Lewis",
author = "{Steele Jr.}, Guy Lewis",
title = "{RABBIT: A Compiler for SCHEME}",
institution = "Massachusetts Institute of Technology Artificial Intelligence Laboratory",
year = 1978,
month = "May",
number = "AI-TR-474",
address = "Cambridge, MA",
annote = "Lisp, functional languages"
}
@techReport{
Traub86,
key = "Traub86, Kenneth R.",
author = "Traub, Kenneth R.",
title = "A Compiler for the MIT Tagged-Token Dataflow Architecture",
institution = "MIT Laboratory for Computer Science,
545 Technology Square,
Cambridge, MA 02139",
number = "LCS TR-370",
year = "1986",
month = "August",
school = "(Master's Thesis, Dept. of Electrical Engineering and Computer
Science, MIT)",
annote = "Functional Languages, Id"
}
@PhdThesis{
Traub88a,
key = "Traub88, Kenneth R.",
author = "Traub, Kenneth R.",
title = "Sequential Implementation of Lenient
Programming Languages",
school = "Massachusetts Institute of Technology",
year = "1988",
month = "May",
note = "Also: TR-417,
MIT Laboratory for Computer Science,
545 Technology Square,
Cambridge, MA 02139",
annote = "Functional Languages, Id"
}
-------
∂14-Sep-88 1334 @MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu "DEFLET"?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 13:34:35 PDT
Received: from helios.northeastern.edu (TCP 20102400402) by MC.LCS.MIT.EDU 14 Sep 88 16:32:09 EDT
Received: by helios.northeastern.edu id aa06569; 14 Sep 88 16:31 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa06552; 14 Sep 88 16:27 EDT
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.5)
id AA28938; Wed, 14 Sep 88 16:27:37 EDT
Date: Wed, 14 Sep 88 16:27:37 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8809142027.AA28938@corwin.CCS.Northeastern.EDU>
To: Alan@mc.lcs.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Fri, 9 Sep 88 17:09 EDT <19880909210910.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: "DEFLET"?
Maybe the reason we're having such problems picking a name for this thing is
that it was a bad abstraction in the first place. While it is syntactically
like LET, the binding it does is very different. In
(LET ((id1 val1) (id2 val2) ...) body)
the id's are bound, whereas in
(LET name ((id1 val1) (id2 val2) ...) body)
name is the variable which is bound. The id's are bound momentarily to the
val's when name is invoked, but that is temporary.
In anonymous LET, the binding is an efficiency hack which implements the
textual substitution
body[vals/ids]
[mod side-effects, etc, which are surely irrelevant. Another irrelevant aside
is that the typing rules in ML treat LET as if it did the substitution.]
In named LET, no such textual interpretation seems possible. The name seems
to have arisen purely from the syntactic similarities of
((LAMBDA (id1 ...) body) val1 ...)
and
((REC name (LAMBDA (id1 ...) body)) val1 ...)
The abstraction seems to be: create a local procedure (recursion, iteration,
recurrence, whatever), and invoke it on some values.
Maybe we should redesign the syntax to more properly represent what's going
on:
(INVOKE-LOCAL (name ((id1 &INITIALLY val1) (id2 &INITIALLY val2) ...))
body)
:-) --Mitch
∂14-Sep-88 1516 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Implementation of functional languages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 15:16:02 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Sep 88 18:10:09 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA28476@BLOOM-BEACON.MIT.EDU>; Wed, 14 Sep 88 18:06:43 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Sep 88 22:06:06 GMT
From: mcharity@athena.mit.edu (Mitchell N Charity)
Organization: Massachusetts Institute of Technology
Subject: Re: Implementation of functional languages
Message-Id: <7066@bloom-beacon.MIT.EDU>
References: <12430328726.19.NIKHIL@XX.LCS.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
There were some typos in the functional language bibliography.
mcharity@athena.mit.edu
...!mit-eddie!mit-athena!mcharity
*** old Wed Sep 14 17:37:59 1988
--- new Wed Sep 14 17:48:56 1988
***************
*** 33 ****
! organization = ACM,
--- 33 ----
! organization = "ACM",
***************
*** 117,118 ****
! author = "Burn, Geoffrey L., {Peyton Jones}, Simon L. and Robson, J.D.",
! title = "{The Spineless G-Machine",
--- 117,118 ----
! author = "Burn, Geoffrey L. and {Peyton Jones}, Simon L. and Robson, J.D.",
! title = "{The Spineless G-Machine}",
***************
*** 216 ****
! Goldberg88a,
--- 216 ----
! Goldberg88b,
***************
*** 366 ****
! author = "{Peyton Jones}, Simon L."
--- 366 ----
! author = "{Peyton Jones}, Simon L.",
***************
*** 419 ****
! Functional Languages, Aspenas, Sweden (to appear)"
--- 419 ----
! Functional Languages, Aspenas, Sweden (to appear)",
∂14-Sep-88 1800 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Lambda Calculus Books
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 18:00:34 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Sep 88 20:55:09 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA01867@BLOOM-BEACON.MIT.EDU>; Wed, 14 Sep 88 20:50:15 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Sep 88 15:11:24 GMT
From: otter!psa@hplabs.hp.com (Patrick Arnold)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Subject: Re: Lambda Calculus Books
Message-Id: <1510013@otter.hple.hp.com>
References: <8809121253.AA25062@BLOOM-BEACON.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
The book is
Principles of Functional Programming
by
Glaser, Hankin and Till.
It's so long since I read it it must be introductory!!
∂14-Sep-88 1840 @MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU "DEFLET"?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 18:40:03 PDT
Received: from kleph (TCP 2212600254) by MC.LCS.MIT.EDU 14 Sep 88 21:11:45 EDT
Received: by kleph.AI.MIT.EDU; Wed, 14 Sep 88 21:13:20 edt
Date: Wed, 14 Sep 88 21:13:20 edt
From: cph@kleph.AI.MIT.EDU (Chris Hanson)
Message-Id: <8809150113.AA07343@kleph>
To: wand@corwin.ccs.northeastern.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Wed, 14 Sep 88 16:27:37 EDT <8809142027.AA28938@corwin.CCS.Northeastern.EDU>
Subject: "DEFLET"?
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 14 Sep 88 16:27:37 EDT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Maybe the reason we're having such problems picking a name for this thing is
that it was a bad abstraction in the first place. While it is syntactically
like LET, the binding it does is very different.
The name seems to have arisen purely from the syntactic similarities of
((LAMBDA (id1 ...) body) val1 ...)
and
((REC name (LAMBDA (id1 ...) body)) val1 ...)
Just a short hysterical note: it arose because of the similarities of
((NAMED-LAMBDA (<let-tag> id1 ...) body) val1 ...)
and
((NAMED-LAMBDA (name id1 ...) body) val1 ...)
where NAMED-LAMBDA had (at that time) the REC semantics, and <let-tag>
was a special name which could not be produced by the MIT Scheme
reader. As you can see, these two differed only in their name, thus
it seemed like a natural extension to LET.
While I won't argue for this syntax based on semantic similarities to
anonymous LET, I will argue that for terseness and readability it is
very good. The initialization forms appear right up front, followed
by the body, and there are no extraneous keywords.
∂14-Sep-88 2014 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Functional Programming Implementation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Sep 88 20:14:03 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Sep 88 22:10:12 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA03126@BLOOM-BEACON.MIT.EDU>; Wed, 14 Sep 88 21:54:21 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Sep 88 15:41:25 GMT
From: tektronix!tekcrl!tekchips!kend@bloom-beacon.mit.edu (Ken Dickey;629-1046;92-726;LP=A;)
Organization: Tektronix, Inc., Beaverton, OR.
Subject: Re: Functional Programming Implementation
Message-Id: <3060@tekcrl.CRL.TEK.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
One interesting text I have not yet seen referenced is:
"Functional Programming", by A. Field & P. Harrison,
Addison-Wesley, 1988 ISBN 0-201-19249-7.
It is heavy into Hope, conbinators, and graph reduction and has
chapters on Memoization, Garbage Collection {one of the few good
gc write-ups I have seen in a text}, abstract interpretation, etc.
-Ken Dickey
∂15-Sep-88 1238 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu dynamic compilation for scheme, with inlining, etc?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Sep 88 12:38:35 PDT
Received: from uicbert.eecs.uic.edu (TCP 20076123031) by MC.LCS.MIT.EDU 15 Sep 88 09:29:16 EDT
Received: by uicbert.eecs.uic.edu (UIUC-5.52/9.7)
id AA28551; Wed, 14 Sep 88 15:59:11 CST
Date: Wed, 14 Sep 88 15:59:11 CST
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Message-Id: <8809142159.AA28551@uicbert.eecs.uic.edu>
To: scheme-request@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Subject: dynamic compilation for scheme, with inlining, etc?
Cc: wilson@uicbert.eecs.uic.edu
I've been thinking about using dynamic compilation for Scheme,
and wondering if anybody else is. Have people abandoned the idea
of dynamic compilation, and if so, was it premature?
Some of the advantages might be:
1) portability images could still run fast
2) an optimizer could be called in to optimize those chunks of
code that are ACTUALLY executed a bunch of times.
(rather than just optimizing the time/space tradeoff between
interpreted and compiled code, it could be used to adjust
compile time/run time tradeoffs.)
3) Transparent, automatic compilation and optimization.
In particular, I'm thinking about a scheme in which inlining would
be done automatically, but dependencies would be recorded. If somebody
changed the value of an inlined procedure or constant, the code
depending on those values would be invalidated and dynamically
recompiled at runtime.
(The mechanism for this depends on near-lexical-scoping. Procedures
that are never redefined in a lexically apparent way could be inlined.
Primitives that can modify things (like first-class environments) in
non-lexically-apparent ways would have to check for dependencies.)
Anybody care to comment on this idea? In particular, is there some
irreducible cost of dynamic compilation that I don't know about? Any
advantages?
(It seems to me that you might dynamically determine what types of
arguments frequently-executed procedures were frequently called with.
You could then compile special versions for the common combinations.
A large-grained check would dispatch to the proper version, within
which most type checking could be eliminated using type inference.
Would this be workable/worthwhile?)
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
∂15-Sep-88 1715 @MC.LCS.MIT.EDU:larus%paris.Berkeley.EDU@ginger.Berkeley.EDU Plea for Scheme Code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Sep 88 17:15:19 PDT
Received: from paris.Berkeley.EDU (TCP 20010113056) by MC.LCS.MIT.EDU 15 Sep 88 19:26:20 EDT
Received: by paris.Berkeley.EDU (5.57/1.25)
id AA03895; Thu, 15 Sep 88 16:14:50 PDT
From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus)
Message-Id: <8809152314.AA03895@paris.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu, comp-lang-scheme@ucbvax.Berkeley.EDU
Subject: Plea for Scheme Code
Reply-To: larus@ginger.Berkeley.EDU
Date: Thu, 15 Sep 88 16:14:43 PDT
I am looking for some small-to-medium sized Scheme programs as test
cases for my dissertation research. These programs should have
side-effect producing operations and should do something "real" (i.e.,
fib, tak, etc. need not apply).
My research is studying how to restructure Lisp programs for
concurrent execution. For more details, see [1]. Your program
doesn't need to be inherently parallel, though if you have a copy in a
parallel dialect, I'd also be interested in it.
All I offer in exchange for your code is immortality in a footnote
(they do keep dissertations forever, don't they?).
/Jim
ARPA: larus@ginger.Berkeley.EDU
uucp: ucbvax!larus
larus@berkeley
[1] James R. Larus and Paul N. Hilfinger,
"Restructuring {Lisp} Programs for Concurrent Execution",
in "ACM SIGPLAN Symposium on Parallel Programming", July, 1988.
∂15-Sep-88 1902 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Plea for Scheme Code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Sep 88 19:01:19 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Sep 88 20:11:31 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA01720@BLOOM-BEACON.MIT.EDU>; Thu, 15 Sep 88 19:58:46 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Sep 88 23:14:43 GMT
From: PARIS.BERKELEY.EDU!larus@ucbvax.berkeley.edu (James Larus)
Subject: Plea for Scheme Code
Message-Id: <8809152314.AA03895@paris.Berkeley.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am looking for some small-to-medium sized Scheme programs as test
cases for my dissertation research. These programs should have
side-effect producing operations and should do something "real" (i.e.,
fib, tak, etc. need not apply).
My research is studying how to restructure Lisp programs for
concurrent execution. For more details, see [1]. Your program
doesn't need to be inherently parallel, though if you have a copy in a
parallel dialect, I'd also be interested in it.
All I offer in exchange for your code is immortality in a footnote
(they do keep dissertations forever, don't they?).
/Jim
ARPA: larus@ginger.Berkeley.EDU
uucp: ucbvax!larus
larus@berkeley
[1] James R. Larus and Paul N. Hilfinger,
"Restructuring {Lisp} Programs for Concurrent Execution",
in "ACM SIGPLAN Symposium on Parallel Programming", July, 1988.
∂16-Sep-88 0902 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: "DEFLET"?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 09:02:37 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 16 Sep 88 11:23:20 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Fri, 16 Sep 88 10:21:27 EST
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: cph@kleph.ai.mit.edu
Subject: Re: "DEFLET"?
Cc: rrrs-authors@mc.lcs.mit.edu
Just a short hysterical note: it arose because of the similarities of
((NAMED-LAMBDA (<let-tag> id1 ...) body) val1 ...)
and
((NAMED-LAMBDA (name id1 ...) body) val1 ...)
...
The named form of "let" was also in Chez Scheme for a while, and in a
version of Scheme I wrote before Chez Scheme, called C-Scheme (the C was
for "curry", though C-Scheme was written partly in C.) It made sense
there because
(lambda <name> (id ...) exp ...)
was an abbreviation for
(rec <name> (lambda (id ...) exp ...))
and yes, I called the former the "named form of 'lambda'", and the named
form of "let" was a natural extension.
The named form of "lambda" was shot down by the dot interface, which is
one reason why I moaned and groaned about the dot interface.
Kent
∂16-Sep-88 1542 @MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU Errata for Simon Peyton Jones' book
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Sep 88 15:42:41 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 16 Sep 88 18:06:54 EDT
Date: Fri 16 Sep 88 18:02:38-EDT
From: Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>
Subject: Errata for Simon Peyton Jones' book
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12431109258.44.NIKHIL@XX.LCS.MIT.EDU>
Simon Peyton Jones recently sent me the following errata list for his
book.
Nikhil
-------------------------------------------------------
The Implementation of Functional Programming Languages
Simon L Peyton Jones
Prentice Hall, 1987
E R R A T A E R R A T A
PLEASE TELL ME OF ANY OTHER ERRORS OR TYPOS YOU FIND IN THE BOOK!
simonpj@uk.ac.ucl.cs
(Line references are given counting only inhabited lines.)
(** for new ones since 15 March 88)
p48, line -6 (in box). Replace "(3*5)" with "(3+5)"
*p52, line -9. The line should begin with an open parenthesis "(".
*p56, line -8. Omit the word "a" at the end of the line.
*p60, middle of bottom line. Replace "f" with "fst".
*p63, line 5. Replace second "that" with "what".
p68, line 2 of Fig 4.4. Replace SECOND equivalence sign with "=".
*p72, line -14. Replace "As" with "All".
p74, line 21, 22. Replace the sentence "Furthermore, it uses less store
to hold the temporary applications of SEL-PAIR." with "Furthermore it uses
less store, since no temporary applications of SEL-PAIR are constructed."
(This one is just a clarification.)
p79, line -13. "NODUPS" should be "nodups".
*p88, line -4; and
*p89, line 8. Replace "(C u1 x y xs ys)" with "(C u1 x xs y ys)".
(The "u1" should remain subscripted as it currently appears.)
p91, line 1. "...is represented by (CONS ..."
should be "...is represented by (CON ..."
p91, last line. "_ul" should be "_u1".
*p93, line -17 (count carefully!). Replace "CONS" with "CON".
*p97, line 17. Replace "...FAIL definitely occurs on the right" with
"...FAIL definitely occurs on the right or left".
*p97, line 18. Add " and FAIL || E #=# E" to the end of the
line. The symbol "||" means the fatbar symbol, and "#=#"
means the 3-line equivalence symbol, both of which occur
earlier on the same line (I just don't have the relevant
symbols in the system I'm using for this errata list).
The spacing is important. There
should be plenty of space between the "E" at the end of the
present line 18 and the "and", and an equal space before
the "FAIL..." which is added. The "and" is in normal text font
and the rest is in the usual sans-serif font.
*p97, line 19. Replace "this rule" with "these rules".
*p116, line -17. Replace "reply" with "rely".
*p116, line -17. Replace "previous section" with "Section 6.2.5".
p126, last line. Dijkstra's initials are "EW" not "EJW".
*p127, line -3. Replace "into" with "in".
*p137, line 7. Add another "]" at the end of the line.
(With similar spacing to the current final "]".)
*p142, line 7. Replace "v1*" with "v1".
(The "v1" remains subscripted as before.)
*p145, line 18. Replace "lists" with "list".
*p145, line -10. Replace "as" with "of".
*p146, line 2. Replace "I" with "id". (In sans-serif font as on the previous
line.)
*p163, line -2. Replace "light" with "list".
p179, line 12. Replace "= tclambda tvn (tc gamma' ns' e)"
with "= tclambda1 tvn (tc gamma' ns' e)"
p202, Fig 11.1. Missing @ sign after $ in left-hand diagram.
p205, line -6; also p265, last line of 16.1.3. Replace "[Richards, 1985]"
with "[Scheevel, 1986]"
p206, lines 20,21; also p280, lines 16,17. Replace Richards reference with:
Scheevel M, 1986. Norma: a graph reduction processor.
Proceedings of the ACM Conference on Lisp and
Functional Programming, Cambridge Mass, pp212-219, August.
p206, line 12. "Ixlop" should be "Klop"
p289, line 2. "Aertes" should be "Aerts".
p299, line 3 of Fig 18.3. Replace "<let> <E>" with "<E> <E>"
p315, lines 9-11. First three lines of code segment should read:
PUSH 1; Get second argument
EVAL; Evaluate it
PUSH 1; Get first argument
p317, line -20. Change "PUSH 2" to "PUSH 0"
p317, line -14. Change "PUSH 0" to "PUSH 2"
p338, line -5,-6. Replace sentence with "In contrast, a stack is a
much less flexible allocation mechanism, but the store it allocates
is recovered immediately when it becomes unused, and this recovery is
very cheap (decrementing the stack pointer)."
(This is just a rewording of a bad sentence.)
p343, last line of Fig. 20.3. Replace "The cases for i,j,x,..."
with "The cases for i,f,x,...".
p405, line -12. "19!" should be "2 to the 19:th power" and
line -10. "O(N!)" should be "O(2 to-the-Nth)".
*p432, line 23. Omit the words "squares of the"
p435, line -7. Line should read "queens 0 = [[]]"
-------
∂17-Sep-88 1517 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Functional Programming Implementation
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Sep 88 15:17:18 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 17 Sep 88 17:34:47 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA03677@BLOOM-BEACON.MIT.EDU>; Sat, 17 Sep 88 17:29:23 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Sep 88 11:48:03 GMT
From: mcvax!ukc!etive!aiva!jeff@uunet.uu.net (Jeff Dalton)
Organization: Dept. of AI, Univ. of Edinburgh, UK
Subject: Re: Functional Programming Implementation
Message-Id: <586@aiva.ed.ac.uk>
References: <3060@tekcrl.CRL.TEK.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <3060@tekcrl.CRL.TEK.COM> kend@tekchips.CRL.TEK.COM (Ken Dickey)
writes:
>One interesting text I have not yet seen referenced is:
>
> "Functional Programming", by A. Field & P. Harrison,
> Addison-Wesley, 1988 ISBN 0-201-19249-7.
>
>It is heavy into Hope, [...]
True, but it has rather strange coverage of Lisp. For some reason,
many logic programming and functional programming texts are perfectly
willing to present Pascal, Algol, etc. as they are actually used but
then take an approach to Lisp that has little to do with current
practice. Often Lisp procedures, but no others, are written entirely
in upper case, and we are told that "everything is a list", etc.
This notion of Lisp is better suited to making certain points, but
tends to leave the impression that Lisp is not a very good language.
This book uses Peter Henderson's Lispkit but without (as far as I can
recall) any indication that Lisp might be significantly different.
∂19-Sep-88 1413 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu IEEE Scheme Standardization Meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:12:56 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 19 Sep 88 16:23:00 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Mon, 19 Sep 88 15:19:51 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: scheme@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: IEEE Scheme Standardization Meeting
IEEE Scheme Standardization Working Group
SUMMARY OF FIRST MEETING
The Working Group on Scheme (IEEE/MSC/P1178) met on July 27, 1988,
following the Lisp conference at Snowbird, Utah. There were 30
attendees, including several who are also members of X3J13 and
ISO/SC22/WG16.
The chair's introductory remarks included the main entries in the PAR
and the main features of the IEEE standardization process. Will
Clinger reported on the Scheme Report Workshop of July 24th, including
proposed differences between the the ``Revised↑3 Report on the
Algorithmic Language Scheme'', or R3RS for short, and the forthcoming
R4RS.
There was concern that a Scheme standard not disrupt ongoing research
on Scheme, with general agreement on the following points: (1) The
Scheme standard should encourage evolution of the language, including
alternate programming styles. (2) The standard is incomplete, so
implementations are expected to extended the standard. (3) Early
standardization of features should be avoided, so that research on
improved features is not curtailed.
David Bartley, Chris Hanson, and Jim Miller were elected to edit
the standard.
The main part of the meeting was general discussion, for the benefit
of the editors, of anticipated differences between the Scheme standard
and the R4RS.
An electronic newsgroup, based at MIT, will be established for
technical and administrative communication of the working group.
When it is established, its presence will be advertised on the
scheme newsgroup with information on how to join the new newsgroup.
Transcripts of activity in this group will be periodically mailed to
interested parties, upon request to the chair, for the benefit of
those without network connections. Full minutes of the meeting
will be posted to this newsgroup when it is created.
It was concluded that the next meeting should be in January or
February at a location and time to be determined by the chair, most
likely in Cambridge.
The working group anticipates the following time schedule: 6 months --
review of first draft of standard, 12 months -- send approved draft of
standard to MSC.
-- Chris Haynes (chaynes@iuvax.cs.indiana.edu)
∂21-Sep-88 0109 @MC.LCS.MIT.EDU:tyan@gwusun.gwu.edu scheme ATT 5
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Sep 88 01:09:39 PDT
Received: from gwusun (TCP 20051001001) by MC.LCS.MIT.EDU 21 Sep 88 00:16:24 EDT
Received: by gwusun (4.0/25-eef)
id AA04027; Mon, 22 Aug 88 00:14:27 EDT
Date: Mon, 22 Aug 88 00:14:27 EDT
From: tyan@gwusun.gwu.edu (Tyan Sheng)
Message-Id: <8808220414.AA04027@gwusun>
To: scheme@mc.lcs.mit.edu
Subject: scheme ATT 5
Would you please send us some instructions about how to install
scheme into our ATT system 5, and if there were other institutes who had
successed in doing so, please give us their mail address, so we can ask
for their experiences.
Thanks for your help!
School of engineering and applied science
George Washington University
∂21-Sep-88 1010 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: dynamic compilation for scheme, with inlining, etc?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:10:14 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 21 Sep 88 13:05:38 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA10016@BLOOM-BEACON.MIT.EDU>; Wed, 21 Sep 88 13:03:30 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Sep 88 20:36:51 GMT
From: mcvax!ukc!cam-cl!adg@uunet.uu.net (Andy Gordon)
Organization: U of Cambridge Comp Lab, UK
Subject: Re: dynamic compilation for scheme, with inlining, etc?
Message-Id: <327@scaup.cl.cam.ac.uk>
References: <8809142159.AA28551@uicbert.eecs.uic.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8809142159.AA28551@uicbert.eecs.uic.edu> wilson@uicbert.eecs.uic.EDU (Paul Wilson) writes:
>I've been thinking about using dynamic compilation for Scheme,
>and wondering if anybody else is. Have people abandoned the idea
>of dynamic compilation, and if so, was it premature?
Firstly, by "dynamic compilation" I understand a system that
represents a programme to start with as a syntax tree or some other form
suitable for interpretation, but compiles parts of it into native code
as execution proceeds. Interpreted code is generally smaller than compiled
code so less space is needed than compiling the whole thing.
I worked on a related problem for my honours thesis---how to interface
compiled and interpreted code in the Edinburgh Standard ML compiler. In the
system I built the programmer indicated by annotations for each function
whether it was to be compiled or interpreted, but I did have in mind a scheme
that would do the annotations automatically, based on data from previous runs,
or even dynamically converting interpreted functions into native code if they
were frequently executed. I found on small benchmarks that native code
was between four and six times bigger than interpreted byte codes, and
ran between one and seven times faster.
Let's call a system that mixes compiled and interpreted code a "hybrid"
system, and then distinguish between "static" and "dynamic" hybrids, i.e.,
between those in which the mode of each function declaration is determined at
compile time and those in which it can change at run time. So I built a
static hybrid system, and I think you plan to build a dynamic hybrid system.
There appear to be two reasons for hybrid systems: (1) to give a variable
time/space tradeoff, i.e., between fast/bulky native code and slow/lean
interpreted code; (2) to allow fancy interpretive debuggers and tracers
in the presence of native code.
I don't think reason (1) is very compelling these days, because the size of
compiled code is not an issue with today's computers---certainly, big ML
programmes that are compiled to native code by one of the production compilers
don't take up inordinate space. However, reason (2) is still attractive,
because interpreted code will always be easier to debug than compiled code. A
dynamic hybrid system is all the work of a static one, and more, so for it to
be worthwhile it must make debugging much easier. One can imagine a debugger
threading through a programme, seeking to use interpreted versions of compiled
functions as it finds them---maybe you could keep a pointer in each compiled
function to an interpreted version or the source. I'd be interested to hear
how you get on.
Here are some references you might find useful when implementing your scheme.
I published a technical report [1] that has a comprehensive literature survey
on hybrid compilation/interpretation, and presents a taxonomy of ways to
switch between compiled and interpreted modes. I have a few copies of it that
I could post to anyone who is interested (email me). Other papers that might
be of interest: Brown on "throw away compiling" [2], Low on automatically
selecting an appropriate representation of an abstract data type depending on
usage statistics [3] and Dakin and Dawson on a text editor that mixes
compilation and interpretation, together with performance graphs [4].
[1] A. D. Gordon, "How to Breed Hybrid Compiler/Interpreters",
Technical report ECS--LFCS--88--50, Laboratory for the Foundations of
Computer Science, Computer Science Dept., University of Edinburgh,
Edinburgh, EH9 3JZ, Scotland. April, 1988.
[2] P. J. Brown, "Throw-away compiling", SWPE, 6, pages 423--434, 1976.
[3] J.R. Low, "Automatic data structure selection: an example and overview",
CACM, 21(5), pages 376--385, May 1978.
[4] R. J. Dakin and P. C. Poole, "A mixed code approach", The Computer Journal,
16(3), pages 219--222, 1973.
∂21-Sep-88 1354 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu request for info on scheme (or subset) for MVS (or portable)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:53:58 PDT
Received: from uicbert.eecs.uic.edu (TCP 20076123031) by MC.LCS.MIT.EDU 21 Sep 88 16:46:46 EDT
Received: by uicbert.eecs.uic.edu (UIUC-5.52/9.7)
id AA03336; Wed, 21 Sep 88 14:46:18 CST
Date: Wed, 21 Sep 88 14:46:18 CST
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Message-Id: <8809212046.AA03336@uicbert.eecs.uic.edu>
To: scheme-request@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Subject: request for info on scheme (or subset) for MVS (or portable)
Cc: wilson@uicbert.eecs.uic.edu
Someone has asked me how to get a Scheme or a subset to run on an
IBM 370. A subset would do, and debugging facilities are not a
necessity. They're struggling along with an unfriendly Lisp as
it is.
Anybody out there know of a Scheme that runs on a 370 or is very
portable? Failing that, does anybody want to make recommendations
about how and what to port to minimize headaches?
Thanks prematurely,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
∂21-Sep-88 1433 @MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu Status of XScheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:33:48 PDT
Received: from uicbert.eecs.uic.edu (TCP 20076123031) by MC.LCS.MIT.EDU 21 Sep 88 16:55:42 EDT
Received: by uicbert.eecs.uic.edu (UIUC-5.52/9.7)
id AA03387; Wed, 21 Sep 88 14:55:15 CST
Date: Wed, 21 Sep 88 14:55:15 CST
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Message-Id: <8809212055.AA03387@uicbert.eecs.uic.edu>
To: scheme-request@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Subject: Status of XScheme
Cc: wilson@uicbert.eecs.uic.edu
A while back I heard something about Dave Betz doing a Scheme.
They called it XScheme 0.3. Does anybody know what the status
of this project is, or any details about the actual code?
(Is it portable? What machines does it run on?, etc.)
Thanks,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
∂22-Sep-88 0755 @MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM Re: dynamic compilation for scheme, with inlining, etc?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 07:55:27 PDT
Received: from IVORY.S4CC.Symbolics.COM (TCP 20024231401) by MC.LCS.MIT.EDU 22 Sep 88 10:51:08 EDT
Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 192375; Thu 22-Sep-88 10:45:57 EDT
Date: Thu, 22 Sep 88 10:46 EDT
From: Allan C. Wechsler <ACW@IVORY.S4CC.Symbolics.COM>
Subject: Re: dynamic compilation for scheme, with inlining, etc?
To: mcvax!ukc!cam-cl!adg@uunet.uu.net, scheme@mc.lcs.mit.edu
In-Reply-To: <327@scaup.cl.cam.ac.uk>
Message-ID: <19880922144647.6.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
Date: 19 Sep 88 20:36:51 GMT
From: mcvax!ukc!cam-cl!adg@uunet.uu.net (Andy Gordon)
[...]
Interpreted code is generally smaller than compiled
code so less space is needed than compiling the whole thing.
This guy's whole approach is based on this premise. Does anyone want to
disabuse him. For a simple recursive factorial, for example, I get
about 25 words interpreted, and about ten compiled. I don't know what
happens with large programs, but I suspect they show about the same
ratio.
∂22-Sep-88 0838 @MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM Re: dynamic compilation for scheme, with inlining, etc?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 08:38:03 PDT
Received: from IVORY.S4CC.Symbolics.COM (TCP 20024231401) by MC.LCS.MIT.EDU 22 Sep 88 10:51:49 EDT
Received: from ROCKY-MOUNTAINS.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 192376; Thu 22-Sep-88 10:47:03 EDT
Date: Thu, 22 Sep 88 10:47 EDT
From: Allan C. Wechsler <ACW@IVORY.S4CC.Symbolics.COM>
Subject: Re: dynamic compilation for scheme, with inlining, etc?
To: mcvax!ukc!cam-cl!adg@uunet.uu.net, scheme@mc.lcs.mit.edu
In-Reply-To: <327@scaup.cl.cam.ac.uk>
Supersedes: <19880922144647.6.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
Message-ID: <19880922144752.7.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
∂22-Sep-88 1209 @MC.LCS.MIT.EDU:hbs@lucid.com dynamic compilation for scheme, with inlining, etc?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 12:09:33 PDT
Received: from lucid.com (TCP 30006414401) by MC.LCS.MIT.EDU 22 Sep 88 14:59:03 EDT
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA06623g; Thu, 22 Sep 88 10:56:07 PST
Received: by kent-state id AA17374g; Thu, 22 Sep 88 11:54:50 PDT
Date: Thu, 22 Sep 88 11:54:50 PDT
From: Harlan Sexton <hbs@lucid.com>
Message-Id: <8809221854.AA17374@kent-state>
To: ACW@IVORY.S4CC.Symbolics.COM
Cc: mcvax!ukc!cam-cl!adg@uunet.uu.net, scheme@mc.lcs.mit.edu
In-Reply-To: Allan C. Wechsler's message of Thu, 22 Sep 88 10:46 EDT <19880922144647.6.ACW@ROCKY-MOUNTAINS.S4CC.Symbolics.COM>
Subject: dynamic compilation for scheme, with inlining, etc?
I wouldn't be surprised to find interpreted representations bigger than
machine-code. However, you can usually get byte-code to be smaller than
machine-code by factors of about 4 to 10 (higher for RISC machines, in my
limited experience), so compiling to byte-codes can win. Also, in spite of
what someone said, memory is NOT so cheap that it doesn't matter how big
the code for an application is, and I can imagine that it will never be so
for certain classes of applications.
--Harlan
∂24-Sep-88 0353 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu space/time in byte code/native code (was dynamic compilation)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Sep 88 03:53:19 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Sep 88 06:48:36 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA26964@BLOOM-BEACON.MIT.EDU>; Sat, 24 Sep 88 06:42:38 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Sep 88 23:15:53 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: space/time in byte code/native code (was dynamic compilation)
Message-Id: <2850@uoregon.uoregon.edu>
References: <8809142159.AA28551@uicbert.eecs.uic.edu>, <327@scaup.cl.cam.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <327@scaup.cl.cam.ac.uk> adg@cl.cam.ac.uk (Andy Gordon) writes:
> I found on small benchmarks that native code
>was between four and six times bigger than interpreted byte codes, and
>ran between one and seven times faster.
Another data point: In MacScheme, native code is also four to six times
as large as interpreted byte code, but is two to ten times as fast, with
a factor of four or five being typical.
>There appear to be two reasons for hybrid systems: (1) to give a variable
>time/space tradeoff, i.e., between fast/bulky native code and slow/lean
>interpreted code; (2) to allow fancy interpretive debuggers and tracers
>in the presence of native code.
>
>I don't think reason (1) is very compelling these days, because the size of
>compiled code is not an issue with today's computers...
Here I have to disagree. On a Macintosh, a factor of five in program size
can easily be the difference between fitting or not fitting on a floppy
disk. The space required by a program is also a big issue under MultiFinder,
since it determines how many simultaneous applications you can run. RAM
accounts for about a quarter of the typical Macintosh II system cost, so
five times as much RAM would double the cost. Similarly for disk space.
I understand why some people don't count Macintoshes and IBM PCs and PS/2s
and their ilk as "today's computers", but I don't think that's realistic.
Peace, Will
∂24-Sep-88 0622 @MC.LCS.MIT.EDU:bard@THEORY.lcs.mit.edu space/time in byte code/native code (was dynamic compilation)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Sep 88 06:22:28 PDT
Received: from toucan.LCS.MIT.EDU (TCP 2206400272) by MC.LCS.MIT.EDU 24 Sep 88 09:18:04 EDT
Received: by toucan.LCS.MIT.EDU
id AA02581; Sat, 24 Sep 88 09:16:41 EDT
Date: Sat, 24 Sep 88 09:16:41 EDT
From: bard@THEORY.lcs.mit.edu
Message-Id: <8809241316.AA02581@toucan.LCS.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: space/time in byte code/native code (was dynamic compilation)
>I don't think reason (1) is very compelling these days, because the size of
>compiled code is not an issue with today's computers...
I disagree, in some contexts. It certainly matters a lot on my home
computer; some programs won't fit on a floppy.
Loading time also matters. If a program like `more' takes a few seconds to
load, it is very annoying.
-- Bard
∂01-Oct-88 1803 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Re: Status of XScheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 18:02:58 PDT
Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 25 Sep 88 15:08:56 EDT
Received: from NORUNIT.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 2911; Sun, 25 Sep 88 15:06:19 EDT
Date: Sun, 25 Sep 88 21:07:02 ECT
To: scheme@mc.lcs.mit.edu
From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Re: Status of XScheme
Date: 25 September 1988, 21:05:26 ECT
From: Harald Hanche-Olsen +47-7-593525 HANCHE at NORUNIT
To: scheme@mc.lcs.mit.edu
Recently, Paul Wilson <wilson@UICBERT.EECS.UIC.EDU> asked the following
question:
> A while back I heard something about Dave Betz doing a Scheme.
> They called it XScheme 0.3. Does anybody know what the status
> of this project is, or any details about the actual code?
> (Is it portable? What machines does it run on?, etc.)
The code is written in reasonably portable C. I know for sure it runs
on IBM PClones, Macs, and Amigas. The code is posted and occasionally
being discussed on BIX (Byte Information eXchange). The latest version
(as far as I know) is *very* preliminary, my copy is version 0.07. A
handful of bugs and lack of reasonable error messages makes it rather
unsuitable for real work at the moment, but a new and improved version
is rumoured to be in the works (though David Betz has been curiously
silent about it lately).
XScheme is based on a bytecode compiler. Apart from that, its
distinguishing feature is its object oriented extensions, similar to
those of XLisp.
- Harald Hanche-Olsen Division of Mathematical Sciences
hanche@norunit.bitnet The Norwegian Institute of Technology
∂01-Oct-88 2153 NET-ORIGIN@MC.LCS.MIT.EDU Scheme for a Sun 4/280 OS 4.0
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 21:53:00 PDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 OCT 88 00:33:05 EDT
Received: from uunet.UU.NET by XX.LCS.MIT.EDU with TCP/SMTP; Fri 30 Sep 88 18:21:55-EDT
Received: from mnetor.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA08955; Fri, 30 Sep 88 18:08:30 EDT
Received: by mnetor.UUCP (smail2.3)
id AA23994; 30 Sep 88 17:42:28 EDT (Fri)
Received: by maccs.mcmaster.ca (5.51/SMI-3.2)
id AA20027; Fri, 30 Sep 88 13:10:39 EDT
Date: Fri, 30 Sep 88 13:10:39 EDT
From: Charlie Root <maccs!root@uunet.UU.NET>
Message-Id: <8809301710.AA20027@maccs.mcmaster.ca>
To: scheme@MC.LCS.MIT.EDU
Subject: Scheme for a Sun 4/280 OS 4.0
Cc: chris@uunet.UU.NET
Is there such a beast? I have compiled mit-scheme on our Sun 4 and it
works to a certain extent. It has trouble creating the fastload modules
and thus doesn't have a lot of the builtin functions. like (date).
We have a file called rrrs.ytex.13 but don't have ytex. What is ytex and
where can we find it. The key is to get a good copy of the scheme documents
but at the moment that is impossible.
Thanks for any help you can provide
---
Dan Trottier dan@maccs.McMaster.CA
Dept of Computer Science ...!uunet!utai!utgpu!maccs!dan
McMaster University (416) 525-9140 x3444
∂01-Oct-88 2319 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mjk@jupiter.risc.com Plea for Scheme Code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Oct 88 23:19:00 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Oct 88 01:56:36 EDT
Received: from risc.com by XX.LCS.MIT.EDU with TCP/SMTP; Wed 28 Sep 88 16:36:55-EDT
Received: from planets.risc.com (jupiter.risc.com) by risc.com (4.0/SMI-DDN)
id AA06488; Wed, 28 Sep 88 13:35:09 PDT
Received: by planets.risc.com (3.2/SMI-3.2)
id AA18434; Wed, 28 Sep 88 13:33:02 PDT
Date: Wed, 28 Sep 88 13:33:02 PDT
From: mjk@planets.risc.com (Morry Katz)
Message-Id: <8809282033.AA18434@planets.risc.com>
To: larus@ginger.Berkeley.EDU
Cc: scheme@mc.lcs.mit.edu, comp-lang-scheme@ucbvax.Berkeley.EDU
In-Reply-To: James Larus's message of Thu, 15 Sep 88 16:14:43 PDT <8809152314.AA03895@paris.Berkeley.EDU>
Subject: Plea for Scheme Code
From: larus%paris.Berkeley.EDU@ginger.Berkeley.EDU (James Larus)
Reply-To: larus@ginger.Berkeley.EDU
Date: Thu, 15 Sep 88 16:14:43 PDT
I am looking for some small-to-medium sized Scheme programs as test
cases for my dissertation research. These programs should have
side-effect producing operations and should do something "real" (i.e.,
fib, tak, etc. need not apply).
My research is studying how to restructure Lisp programs for
concurrent execution. For more details, see [1]. Your program
doesn't need to be inherently parallel, though if you have a copy in a
parallel dialect, I'd also be interested in it.
All I offer in exchange for your code is immortality in a footnote
(they do keep dissertations forever, don't they?).
I have been looking for the same sorts of programs to test my system, with
little sucess. I would be most appreciative if you would forward any replies
you get to me as well.
Morry Katz
∂02-Oct-88 0736 @MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.bu.edu Plea for Scheme Code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Oct 88 07:36:08 PDT
Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 2 Oct 88 10:02:03 EDT
Received: from BUCSF.BU.EDU by bu-it.BU.EDU (5.58/4.7)
id AA02487; Sun, 2 Oct 88 10:01:09 EDT
Return-Path: <gjc@bucsf.bu.edu>
Received: by bucsf (4.12/4.7)
id AA13715; Sun, 2 Oct 88 10:00:39 edt
Date: Sun, 2 Oct 88 10:00:39 edt
From: gjc%bucsf.BU.EDU@bu-it.bu.edu (George J. Carrette)
Message-Id: <8810021400.AA13715@bucsf>
To: mjk@planets.risc.com
Cc: scheme@mc.lcs.mit.edu
Subject: Plea for Scheme Code
The mit cscheme implementation comes with quite a bit of scheme code
you can try to run in parallel. There must be a lot of dispatching and
data conversion in the arithmetic/bignum code, there must be sorting code,
syntax conversion routines etc.
You could also look at using the compiler from the yale T system. It has
all sorts of passes that do interesting things with list structure.
-gjc
∂02-Oct-88 1645 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu example of dynamic optimization
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Oct 88 16:45:07 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Oct 88 19:40:03 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA27483@BLOOM-BEACON.MIT.EDU>; Sun, 2 Oct 88 19:36:54 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Oct 88 17:27:00 GMT
From: uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: example of dynamic optimization
Message-Id: <82000002@uicbert.eecs.uic.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
To motivate the discussion of dynamic optimization, here's a simple
example of why I think it might be worthwhile.
Suppose you have a language in which you can have homogeneous collections
like array-of-integer. (Or an implementation that lets you declare them.)
Suppose also that the language is basically dynamically typed, and that
the declared types are attached to the objects at runtime. So an array
of integer would have a header saying so.
Now suppose we define a routine that processes collections, looping to
apply some operation to its elements. A dynamic optimizing system
would generate a generic version of the code that checks the types
of the arguments and then dispatches to an optimized version for those
types. If it has never seen that combination of types before, a new
version is created on the fly.
So the first time this generic code sees an array-of-integer, it compiles
a version of the looping routine that assumes each element is an integer,
omitting tag checks, unrolling the loop, etc.
The generic code must always check the collection's type when it is
executed, but the compiled code it dispatches to needn't. (If it's
not a homogeneous collection, it simply dispatches to a normal
version with type checking.)
The nice thing about this is that the code is still generic from the
programmer's point of view, and type checking is not abandoned. (Unlike
systems in which declarations tell the compiler to make assumptions
at a particular point in the code.)
My guess is that for most programs, most routines are only ever given
one kind of argument, so there wouldn't be an explosion of versions.
(You can always use a cache and throw away disused versions.)
At least for this example, the optimization would be transparent and
safe. If somebody changes (at another point in the code) the type
of some object that is passed to the optimized routine, the dynamic
check will ensure that an appropriate version is generated.
Now the question is how general this system could be, using more
sophisticated type inference than recognizing homogeneous collections.
And can it be combined with nifty trace-scheduling techniques to
precompute paths through often-executed chunks of code and seriously
optimize them?
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
∂02-Oct-88 1708 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu dynamic compilation/optimization II
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Oct 88 17:08:43 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Oct 88 19:40:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA27450@BLOOM-BEACON.MIT.EDU>; Sun, 2 Oct 88 19:36:03 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Oct 88 17:05:00 GMT
From: uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: dynamic compilation/optimization II
Message-Id: <82000001@uicbert.eecs.uic.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
(Please excuse if this redunds; I tried to post it before, but it didn't
appear to make it.)
There seems to be some interest out there, so here's a bit more detail
on those dynamic compilation ideas:
* When a chunk of code is dynamically compiled (not optimized yet), it
is given a little prologue that increments a count every time it is
executed. When the count exceeds a threshold, the code is recompiled
with a much higher level of optimization. The most optimized code
would not have this prologue to slow it down, since it wouldn't
need it anymore. Highly optimized code might be less subject
to being discarded as well.
* The business about noticing common types of arguments and compiling
specially optimized versions could be handled similarly. A little
prologue would check every nth execution for types, rather than
every execution. Most times, it would just increment a counter.
Very highly optimized code could forego the checking and counting
entirely, assuming it had already learned all of the likely argument
type combinations. (Actually, every nth time it would change n
a little to avoid rhythmic problems.)
* Something like this might also be useful for trace scheduling.
Every now and then you execute an "instrumented" version of the
code that collects data on common execution patterns.
Any comments? Does anybody know of any systems that use dynamic
compilation? I know a couple of Smalltalks do it, and now
I'm told that MIT Scheme has a somewhat similar cache-with-
dependencies mechanism for variable lookups.
Does anybody have any opinions on the expected efficiency of such a system?
It seems to me that it could be quite good. It could also be advantageous
in that it would not optimize a lot of the code. In particular, it could
keep things in a more debuggable form than something that optimizes
more stupidly, without much performance penalty. (Especially since
frequently modified things will never get heaviliy optimized.)
I only have a few references on dynamic compilation, none of which go into
anything advanced. If you have others, please send them to me and I'll
pass them on to interested parties.
(Besides the ones in Andy Gordon's posting, there was "An Evaluation
of Throw-away Compiling" in Software Practice and Experience, vol. 13
(1983), pp. 241-249.)
I have not gotten any responses indicating that dynamic compilation has
been used to control levels of optimization or to recompile when
optimizer assumptions are violated.
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
∂03-Oct-88 0127 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu unwind-protect
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Oct 88 01:26:53 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Oct 88 02:53:46 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA00683@BLOOM-BEACON.MIT.EDU>; Mon, 3 Oct 88 02:42:00 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Oct 88 03:41:57 GMT
From: fenchurch.mit.edu!jbs@eddie.mit.edu (Jeff Siegal)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Subject: unwind-protect
Message-Id: <10180@eddie.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
How can one do something like UNWIND-PROTECT in Scheme? Is the
concept completely ill-defined in the presence of first-class
continuations, or is there an idiom which "sometimes works?"
Jeff Siegal
∂03-Oct-88 0230 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re : unwind-protect
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Oct 88 02:30:44 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Oct 88 04:23:44 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA02296@BLOOM-BEACON.MIT.EDU>; Mon, 3 Oct 88 04:18:51 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Oct 88 07:08:04 GMT
From: pierce@locus.ucla.edu
Organization: UCLA Computer Science Department
Subject: Re : unwind-protect
Message-Id: <16407@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
** Subject: unwind-protect
** Message-ID: <10180@eddie.MIT.EDU>
** Date: 3 Oct 88 03:41:57 GMT
** Sender: uucp@eddie.MIT.EDU
** Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal)
** Organization: MIT EE/CS Computer Facilities, Cambridge, MA
** Lines: 5
**
** How can one do something like UNWIND-PROTECT in Scheme? Is the
** concept completely ill-defined in the presence of first-class
** continuations, or is there an idiom which "sometimes works?"
**
** Jeff Siegal
Kent Dybvig's Chez Scheme has what seems to be a much more powerful construct
called "dynamic-wind". A brief sketch of its uses is given in Dybvig's
"The Scheme Programming Language".
-- Brad Pierce
∂03-Oct-88 0456 @MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM Re : unwind-protect
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Oct 88 04:56:02 PDT
Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 3 Oct 88 07:20:12 EDT
Received: from PELE.ACA.MCC.COM (PELE.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Mon 3 Oct 88 06:18:57-CDT
Date: Mon, 3 Oct 88 06:18 CDT
From: Christopher Maeda <maeda@MCC.COM>
Subject: Re : unwind-protect
To: pierce@locus.ucla.edu
cc: scheme@mc.lcs.mit.edu
In-Reply-To: <16407@shemp.CS.UCLA.EDU>
Message-ID: <19881003111852.6.MAEDA@PELE.ACA.MCC.COM>
Date: 3 Oct 88 07:08:04 GMT
From: pierce@locus.ucla.edu
** Subject: unwind-protect
** Message-ID: <10180@eddie.MIT.EDU>
** Date: 3 Oct 88 03:41:57 GMT
** Sender: uucp@eddie.MIT.EDU
** Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal)
** Organization: MIT EE/CS Computer Facilities, Cambridge, MA
** Lines: 5
**
** How can one do something like UNWIND-PROTECT in Scheme? Is the
** concept completely ill-defined in the presence of first-class
** continuations, or is there an idiom which "sometimes works?"
**
** Jeff Siegal
Kent Dybvig's Chez Scheme has what seems to be a much more powerful construct
called "dynamic-wind". A brief sketch of its uses is given in Dybvig's
"The Scheme Programming Language".
-- Brad Pierce
Hmm. How would unwind-protect be expressed with just call/cc?
∂04-Oct-88 0322 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Re : unwind-protect
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Oct 88 03:22:40 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Oct 88 06:09:07 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA01661@BLOOM-BEACON.MIT.EDU>; Tue, 4 Oct 88 06:07:31 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Oct 88 22:20:36 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: Re: Re : unwind-protect
Message-Id: <2917@uoregon.uoregon.edu>
References: <16407@shemp.CS.UCLA.EDU>, <19881003111852.6.MAEDA@PELE.ACA.MCC.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
>Hmm. How would unwind-protect be expressed with just call/cc?
UNWIND-PROTECT is trivial to implement in terms of DYNAMIC-WIND, which can
be implemented in terms of CALL-WITH-CURRENT-CONTINUATION provided the
Scheme system permits CALL-WITH-CURRENT-CONTINUATION to be redefined,
uses close-coded calls to CALL-WITH-CURRENT-CONTINUATION for all captures
of a continuation, and contains no pre-captured continuations.
An implementation appears in Haynes and Friedman, Embedding Continuations
in Procedural Objects, TOPLAS 9, 4 (October 1987), pages 582-598.
Peace,
William Clinger
∂04-Oct-88 1530 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu scheme-standard mailing list
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Oct 88 15:29:41 PDT
Received: from iuvax.cs.indiana.edu (TCP 30003147300) by MC.LCS.MIT.EDU 4 Oct 88 18:22:58 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Tue, 4 Oct 88 17:21:02 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu
Subject: scheme-standard mailing list
The mailing list
scheme-standard@wheaties.ai.mit.edu
has been created for technical and administrative communication
within the IEEE Scheme standardization Working Group, which is
open to all interested parties. Administrative communication related
to this list, including requests for membership, should be addressed to
scheme-standard-request@wheaties.ai.mit.edu
-- Chris Haynes (chaynes@iuvax.cs.indiana.edu)
∂07-Oct-88 1237 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 12:37:02 PDT
Received: from cs.utah.edu (TCP 20033402025) by MC.LCS.MIT.EDU 7 Oct 88 15:32:25 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA05469; Fri, 7 Oct 88 13:30:43 MDT
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25143; Fri, 7 Oct 88 13:30:30 MDT
Date: Fri, 7 Oct 88 13:30:30 MDT
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8810071930.AA25143@car.utah.edu>
To: pass@cs.utah.edu
Cc: scheme@mc.lcs.mit.edu, shebs@apple.apple.com, mohammad%hpcllz2@sde.hp.com
Subject: self reproducing code
A couple of years ago I found an example of self reproducing code.
It looked something like:
((lambda (lambda) (list (quote (lambda ....
It was an anonymous lambda application which, when evaluated in Common
Lisp, would return the exact same for, which could then be evaluated
again, always returning the same anonymous application.
If anyone has this code please send it to me.
Thanks, Harold
∂07-Oct-88 1411 @MC.LCS.MIT.EDU:stoller%morgan@cs.utah.edu Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 14:11:41 PDT
Received: from cs.utah.edu (TCP 20033402025) by MC.LCS.MIT.EDU 7 Oct 88 15:59:48 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA06715; Fri, 7 Oct 88 13:56:00 MDT
Received: by morgan.utah.edu (5.54/utah-2.0-leaf)
id AA04067; Fri, 7 Oct 88 13:55:56 MDT
Date: Fri, 7 Oct 88 13:55:56 MDT
From: stoller%morgan@cs.utah.edu (Leigh B. Stoller)
Message-Id: <8810071955.AA04067@morgan.utah.edu>
To: carr%car@cs.utah.edu
Cc: pass@cs.utah.edu, scheme@mc.lcs.mit.edu, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 13:30:30 MDT <8810071930.AA25143@car.utah.edu>
Subject: Re: self reproducing code
Date: Tue, 19 May 87 15:39:42 MDT
From: carr@orion.utah.edu (Harold Carr)
To: kessler@orion.utah.edu
Subject: Fun stuff
Cc: pass@orion.utah.edu
Here's one everyone has already probably seen, but I forgot about it.
What does the following evaluate to?
((lambda (x) (list x (list (quote quote) x)))
(quote (lambda (x) (list x (list (quote quote) x)))))
Great problem for Bob's Lisp class.
Harold
∂07-Oct-88 1445 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 14:45:14 PDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 7 Oct 88 16:01:33 EDT
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141482; Fri 7-Oct-88 16:00:51 EDT
Date: Fri, 7 Oct 88 16:00 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: self reproducing code
To: carr%car@cs.utah.edu
cc: pass@cs.utah.edu, scheme@MC.LCS.MIT.EDU, shebs@apple.apple.com, mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Message-ID: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Date: Fri, 7 Oct 88 13:30:30 MDT
From: carr%car@cs.utah.edu (Harold Carr)
A couple of years ago I found an example of self reproducing code....
in Common Lisp, ...
My favorite example:
(let ((let '`(let ((let ',let))
,let)))
`(let ((let ',let))
,let))
I believe that Mike McMahon is the author of this variant. It is
unfortunate that this isn't standard Scheme because of the use of
LET as an identifier...
∂07-Oct-88 1529 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:29:01 PDT
Received: from cs.utah.edu (TCP 20033402025) by MC.LCS.MIT.EDU 7 Oct 88 16:23:24 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA07777; Fri, 7 Oct 88 14:19:30 MDT
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25193; Fri, 7 Oct 88 14:19:26 MDT
Date: Fri, 7 Oct 88 14:19:26 MDT
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8810072019.AA25193@car.utah.edu>
To: Alan@ai.ai.mit.edu
Cc: carr%car@cs.utah.edu, pass@cs.utah.edu, scheme@mc.lcs.mit.edu,
shebs@apple.apple.com, mohammad%hpcllz2@sde.hp.com
In-Reply-To: Alan Bawden's message of Fri, 7 Oct 88 16:00 EDT <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: Re: self reproducing code
Thanks for the self-reproducing code. Since yours is different from
what I was looking for it prompts me to ask of everyone: send me any
examples you have of self-reproducing code. I'd like to make a
collection of them. If possible, cite the author as Alan has done.
Thanks, Harold
ps: I don't care whether the code is interlisp, cl, psl, scheme, not
quite legal - just so it does (or has) run on some system that does
(or has) exists.
∂07-Oct-88 1650 @MC.LCS.MIT.EDU,@IVORY.S4CC.Symbolics.COM:Zippy@QUABBIN.SCRC.Symbolics.COM self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:50:15 PDT
Received: from IVORY.S4CC.Symbolics.COM (TCP 20024231401) by MC.LCS.MIT.EDU 7 Oct 88 17:09:37 EDT
Received: from HALEAKALA.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194006; Fri 7-Oct-88 17:04:11 EDT
Date: Fri, 7 Oct 88 17:04 EDT
From: stever@Riverside.SCRC.Symbolics.COM
Sender: Zippy@QUABBIN.SCRC.Symbolics.COM
Subject: self reproducing code
To: Harold Carr <carr%car@cs.utah.edu>
cc: pass@cs.utah.edu, scheme@mc.lcs.mit.edu, shebs@apple.apple.com, mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Message-ID: <19881007210401.2.LISP-MACHINE@HALEAKALA.S4CC.Symbolics.COM>
Date: Fri, 7 Oct 88 13:30:30 MDT
From: carr%car@cs.utah.edu (Harold Carr)
It was an anonymous lambda application which, when evaluated in Common
Lisp, would return the exact same for, which could then be evaluated
again, always returning the same anonymous application.
((LAMBDA (TEMPLATE)
(SETF (SECOND (SECOND TEMPLATE)) (COPY-TREE TEMPLATE))
TEMPLATE)
'((LAMBDA (TEMPLATE)
(SETF (SECOND (SECOND TEMPLATE)) (COPY-TREE TEMPLATE))
TEMPLATE)
(QUOTE *PLACEHOLDER*)))
This will work. I'm pretty sure there's a more elegant way to do it.
If anyone send you one, I'd appreciate a copy.
Thanks,
Stephen
∂08-Oct-88 0042 NET-ORIGIN@MC.LCS.MIT.EDU re: Unwind-Protect and Continuations
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 00:42:16 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 OCT 88 03:20:18 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09860@EDDIE.MIT.EDU>; Sat, 8 Oct 88 03:18:58 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA21642@BLOOM-BEACON.MIT.EDU>; Sat, 8 Oct 88 02:58:14 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Oct 88 14:02:14 GMT
From: mcvax!ukc!cam-cl!pmcy@uunet.uu.net (Phillip Yelland on jenny)
Organization: U of Cambridge Comp Lab, UK
Subject: re: Unwind-Protect and Continuations
Message-Id: <344@scaup.cl.cam.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
There's a paper from Indiana U. entitled "Constraining Control", by Wand and
Friedman (I think), which shows how unwind-protect and similar facilities may
be coded using 'first-class' continuations.
If there's interest, I can go away and look it up in greater detail.
--Phil
∂08-Oct-88 0429 NET-ORIGIN@MC.LCS.MIT.EDU Scheme for 386/ix?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 04:29:34 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 OCT 88 21:45:57 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA04531@EDDIE.MIT.EDU>; Fri, 7 Oct 88 21:44:39 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA15419@BLOOM-BEACON.MIT.EDU>; Fri, 7 Oct 88 21:30:00 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Oct 88 00:00:04 GMT
From: spdcc!ima!johnl@bloom-beacon.mit.edu (John R. Levine)
Organization: Not much
Subject: Scheme for 386/ix?
Message-Id: <2752@ima.ima.isc.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can anybody point me at an implementation of Scheme that runs or could be
made to run on an 80386 box running 386/ix (System V Unix) ?
TIA,
--
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ bbn | think | decvax | harvard | yale }!ima!johnl, Levine@YALE.something
Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
∂08-Oct-88 0430 @MC.LCS.MIT.EDU:hal@murren.ai.mit.edu 1989 Conference on Lisp and History of Lisp -- Advance Notice
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 04:29:51 PDT
Received: from murren.ai.mit.edu (TCP 2212600263) by MC.LCS.MIT.EDU 7 Oct 88 21:50:20 EDT
Received: by murren.ai.mit.edu (5.59/1.5)
id AA14603; Fri, 7 Oct 88 21:27:27 EDT
Date: Fri, 7 Oct 88 21:27:27 EDT
From: hal@murren.ai.mit.edu (Hal Abelson)
Message-Id: <8810080127.AA14603@murren.ai.mit.edu>
To: arpanet-bboard@mc.lcs.mit.edu, lisp-forum@mc.lcs.mit.edu,
scheme@mc.lcs.mit.edu
Subject: 1989 Conference on Lisp and History of Lisp -- Advance Notice
Reply-To: hal@zurich.ai.mit.edu
HAPPY 30TH BIRTHDAY FOR LISP CONFERENCE
In recognition of the 30th birthday of the Lisp programming language,
the ACM is sponsoring a special conference on Lisp and the history of
Lisp, to be held at MIT, November 28 through December 1 1989.
Part of the conference will deal with technical issues of current
interest to the Lisp community (similar to Lisp presentations at the
Lisp and Functional Programming conferences). There also be sessions
devoted to historical papers, evolution of Lisp implementation
technology, perspectives on the past and future of Lisp, and so on.
A formal call for abstracts (which will be due next May) will appear
in a few months.
In the meantime, we would like to solicit your advice about
appropriate special events for this conference. For example, people
have suggested presenting awards for "distinguished contributions to
Lisp." Are there particular panel discussions you would like to see?
Or other events you think would be appropriate for a birthday
celebration?
Please mail us your suggestions.
For the program committee:
Dick Gabriel
Guy Steele
Jan Zubkoff
Hal Abelson
send suggestions to
Hal Abelson
MIT
545 Technology Square
Cambridge, MA 02129
hal@zurich.ai.mit.edu
∂08-Oct-88 1500 @MC.LCS.MIT.EDU:mcvax!diku.dk!danvy@uunet.UU.NET Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 15:00:04 PDT
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Oct 88 17:54:32 EDT
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA22266; Sat, 8 Oct 88 17:53:02 EDT
Received: by mcvax.cwi.nl; Sat, 8 Oct 88 22:23:48 +0100 (MET)
Received: from diku.dk
by dkuug.dk (3.2/smail2.5/ease)
id AA07492; Sat, 8 Oct 88 17:15:36 +0100
Received: by diku.dk (5.51/smail2.5/ease)
id AA14951; Sat, 8 Oct 88 17:15:22 +0100
Date: Sat, 8 Oct 88 17:15:22 +0100
From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy)
Message-Id: <8810081615.AA14951@diku.dk>
To: Alan@ai.ai.mit.edu, carr%car@cs.utah.edu
Subject: Re: self reproducing code
Cc: carr%car@cs.utah.edu, mohammad%hpcllz2@sde.hp.com, pass@cs.utah.edu,
scheme@mc.lcs.mit.edu, shebs@apple.apple.com
Chez Scheme Version 2.0.3 Copyright (c) 1987 R. Kent Dybvig
> ()
()
>
This one is pretty small :-)
It is illegal according to the r3rs's BNF for Scheme, though.
Olivier
∂08-Oct-88 2020 @MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Oct 88 20:20:43 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 8 Oct 88 22:55:06 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473424; Sat 8-Oct-88 22:51:52 EDT
Date: Sat, 8 Oct 88 22:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: self reproducing code
To: mcvax!diku.dk!danvy@uunet.UU.NET
cc: Alan@ai.ai.mit.edu, carr%car@cs.utah.edu,
mohammad%hpcllz2@sde.hp.com, pass@cs.utah.edu, scheme@mc.lcs.mit.edu,
shebs@apple.apple.com
In-Reply-To: <8810081615.AA14951@diku.dk>
Message-ID: <881008225128.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
() by itself is certainly cute, but I don't think it counts.
It's not -constructing- a program, it's just -returning- one.
All self-evaluating forms have the same property, after all.
{{1, 2, 3, ...}, {#t, #f}, ...}
Another borderline case, that comes up in Common Lisp, is:
#1='#1#
But depending on your model of what QUOTE does, that's just
self-evaluating, too, and doesn't count either. Btw, don't
try to look at the result without setting *print-circle* or
*print-level* appropriately.
∂09-Oct-88 0739 NET-ORIGIN@MC.LCS.MIT.EDU Re: Unwind-Protect and Continuations (Ref)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Oct 88 07:39:36 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 OCT 88 10:34:22 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA03068@EDDIE.MIT.EDU>; Sun, 9 Oct 88 10:33:01 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA26343@BLOOM-BEACON.MIT.EDU>; Sun, 9 Oct 88 10:13:32 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Oct 88 18:59:05 GMT
From: att!chinet!mcdchg!clyde!watmath!utgpu!utzoo!yunexus!oz@bloom-beacon.mit.edu (Ozan Yigit)
Organization: York U. Computing Services - Magic Group
Subject: Re: Unwind-Protect and Continuations (Ref)
Message-Id: <867@yunexus.UUCP>
References: <344@scaup.cl.cam.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <344@scaup.cl.cam.ac.uk> pmcy@cl.cam.ac.uk (Phillip Yelland) writes:
>There's a paper from Indiana U. entitled "Constraining Control", by Wand and
>Friedman (I think)...
[from the scheme bibliography (latest will be out real soon)]
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Constraining Control
%J Proceedings of the Twelfth Annual Symposium on Principles of
Programming Languages
%C New Orleans, LA.
%P 245-254
%I ACM
%D January 1985
oz
--
Reflections are | Usenet: ...!utzoo!yunexus!oz
images of tarnished aspirations. | ...uunet!mnetor!yunexus!oz
RACTER | Bitnet: oz@[yulibra|yuyetti]
[an Artifically Insane program.] | Phonet: +1 416 736-5257x3976
∂09-Oct-88 1330 @MC.LCS.MIT.EDU:cti@mimsy.umd.edu Scheme mailing list
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Oct 88 13:30:11 PDT
Received: from mimsy.umd.edu (TCP 20002100010) by MC.LCS.MIT.EDU 9 Oct 88 16:25:46 EDT
Received: by mimsy.umd.edu (5.58/4.7)
id AA11729; Sun, 9 Oct 88 16:23:19 EDT
Date: Sun, 9 Oct 88 16:23:19 EDT
From: C. Terry Ireland <cti@mimsy.umd.edu>
Message-Id: <8810092023.AA11729@mimsy.umd.edu>
To: scheme@mc.lcs.mit.edu
Subject: Scheme mailing list
Cc: cti@mimsy.umd.edu, norm@mimsy.umd.edu
Please add my name to the scheme mailing address. If paper mail is
ever used, my address is:
Terry Ireland
10023 Menlo Avenue
Silver Spring, MD 20910
Thank you.
T
∂10-Oct-88 0629 @MC.LCS.MIT.EDU:ALBERGA@IBM.COM Self replicating code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88 06:28:55 PDT
Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 10 Oct 88 09:24:42 EDT
Date: 10 Oct 88 09:06:52 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: scheme@mc.lcs.mit.edu
Message-Id: <101088.090653.alberga@ibm.com>
Subject: Self replicating code
Here is a brute-force expression which prints itself. This was in LISP370,
circa 1978.
(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) )
(COPY
"(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) ) (COPY "NIL) "NIL ) ) )
"(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) ) (COPY "NIL) "NIL ) ) ) )
The uses of copy were to keep it from modifying itself.
Obviously, shared sub-structure could be used to shorten the
representation.
Cyril N. Alberga
∂10-Oct-88 0711 @MC.LCS.MIT.EDU:cti@mimsy.umd.edu Scheme Mailing List
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88 07:11:30 PDT
Received: from mimsy.umd.edu (TCP 20002100010) by MC.LCS.MIT.EDU 10 Oct 88 10:07:02 EDT
Received: by mimsy.umd.edu (5.58/4.7)
id AA23432; Mon, 10 Oct 88 10:04:25 EDT
Date: Mon, 10 Oct 88 10:04:25 EDT
From: C. Terry Ireland <cti@mimsy.umd.edu>
Message-Id: <8810101404.AA23432@mimsy.umd.edu>
To: Scheme@mc.lcs.mit.edu
Subject: Scheme Mailing List
Please add my name to the Scheme mailing list. If paper mail is ever
used, my address is
Terry Ireland
10023 Menlo Avenue
Silver Spring, MD 20910
Thank you.
T
∂11-Oct-88 0425 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE self-replicating code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 04:24:52 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 Oct 88 07:15:39 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1995; Tue, 11 Oct 88 07:13:31 EDT
Received: from IRUCCIBM by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1994;
Tue, 11 Oct 88 07:13:29 EDT
Received: from IRUCCVAX.UCC.IE by IRUCCIBM (Mailer X1.25) with BSMTP id 0193;
Mon, 10 Oct 88 15:45:35 IST
Date: Mon, 10 Oct 88 15:48 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: self-replicating code
To: SCHEME@MC.LCS.MIT.EDU
X-VMS-To: SCHEME
Various respondents to the question of self-replicating anonymous lambda
expressions have given us solutions, but no derivations. I hope therefore
that the following contribution might be of interest.
If one has a normal-order evaluator in Scheme rather than an applicative
order one then the simplest self-replicating lambda expression is
((lambda (x) (x x)) (lambda (x) (x x)))
since the argument expression is substituted without being evaluated, but
loops forever with applicative order.
Any approach to generating self-replication in applicative order evaluators
must therefore include emulation of normal-order evaluation. Consider as a
first attempt:
(define f (lambda (x) (list 'f x)))
This doesn't quite work because the x in the list will be replaced by its
value. So a better attempt is:
(define f (lambda (x) (list 'f <reconstruction-of-x>)))
As a first step towards eliminating the recursive use of f, it makes sense
to pass f an argument that will evaluate to the lambda expression for f at
the 'f position, but will not itself (the argument that is) be evaluated to
f. The insight for this comes by recognizing that ((lambda () <body>))
evaluates to <body>. This suggests that f be recast to the form:
(define f (lambda (x) (list (x) <reconstruction-of-x>)))
and that it be passed the argument: (lambda () 'f). (This is where the
normal-order evaluation is emulated.)
The reconstruction of x can now be accomplished to give for f:
(define f (lambda (x) (list (x) (list 'lambda '() 'f))))
followed again by the elimination of 'f to yield:
(define f
(lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x))))))
It can be verified that:
> (f (lambda () 'f)
(f (lambda () 'f)
>
Elimination of the define statement is now straightforward, to yield the
required anonymous self-replicating expression:
((lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x)))))
(lambda ()
'(lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x)))))))
Any comments?
Gordon Oulsnam
∂11-Oct-88 0807 @MC.LCS.MIT.EDU:jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 08:07:41 PDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 11 Oct 88 10:53:58 EDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03181; 10 Oct 88 15:39 BST
Date: Mon, 10 Oct 88 15:39:36 BST
Message-Id: <10500.8810101439@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: self reproducing code
To: scheme@mc.lcs.mit.edu
Here's one I wrote a while ago using the fairly standard technique
of having some data that looks pretty much like the code that uses
the data to reconstruct the data and the code.
;;; Self-reproducing function
(defun v ()
(let ((m '(subst m
'**
'(defun v () (let ((m '**)) **)))))
(subst m
'**
'(defun v () (let ((m '**)) **)))))
-- Jeff
∂11-Oct-88 2055 NET-ORIGIN@MC.LCS.MIT.EDU Re: self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 20:55:19 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 OCT 88 19:19:13 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA20412@EDDIE.MIT.EDU>; Tue, 11 Oct 88 19:18:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA29975@BLOOM-BEACON.MIT.EDU>; Tue, 11 Oct 88 18:55:18 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Oct 88 22:24:52 GMT
From: sun.soe!sun.soe.clarkson.edu!gary@tcgould.tn.cornell.edu (Gary Levin)
Organization: Clarkson University
Subject: Re: self reproducing code
Message-Id: <GARY.88Oct11182452@milo.mcs.clarkson.edu>
References: <10500.8810101439@subnode.aiai.ed.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
A non-trivial expression must be a list of at least 2 elements, so
let's guess that our solution looks like:
( ____________ ___________ )
The first blank must be a lambda expression if we are to avoid the
necessity of defining a function outside of our solution. (Which
would violate the self-reproducing aspect to some extent.)
( (lambda (x) ________ ) ____________ )
The choice of the name ``x'' was arbitrary. The choice of one
argument followed from the assumption of a two element list. The body
of the lambda expression must return a two element list, if we are to
re-produce the original input. There are different choices possible;
I'll choose
( (lambda (x) (list _____ _____ )) ___________ )
The argument might as well be quoted, otherwise we need to delve
deeper into the expression. This then determines some of the second
argument to ``list''.
( (lambda (x) (list _1_ (list (quote quote) _2_ ))) (quote _3_ ) )
Now comes the ``magic'' part. Notice that whatever is written in _3_,
we can make the second element of our result match by replacing _2_ by x.
( (lambda (x) (list _1_ (list (quote quote) x ))) (quote _3_ ) )
yields ( value_of_1_ (quote _3_ ) )
We can now use ``x'' for _1_, which let's us determine the value_of_1_
by our choice of _3_. The solution follows immediately.
( (lambda (x) (list x (list (quote quote) x )))
(quote (lambda (x) (list x (list (quote quote) x ))) ) )
The logic of the derivation makes this easy to remember/reconstruct.
--
-----
Gary Levin/Dept of Math & CS/Clarkson Univ/Potsdam, NY 13676/(315) 268-2384
BitNet: gary@clutx Internet: gary@clutx.clarkson.edu
∂11-Oct-88 2055 NET-ORIGIN@MC.LCS.MIT.EDU Re: Scheme mailing list
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 20:55:36 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 OCT 88 20:19:35 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA21477@EDDIE.MIT.EDU>; Tue, 11 Oct 88 20:19:04 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA01322@BLOOM-BEACON.MIT.EDU>; Tue, 11 Oct 88 19:56:16 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Oct 88 16:44:00 GMT
From: uicsrd.csrd.uiuc.edu!kwang@uxc.cso.uiuc.edu
Subject: Re: Scheme mailing list
Message-Id: <16800009@uicsrd.csrd.uiuc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
What is the "scheme mailing adress" for?
It seems there is an address directory used when a new paper/report on scheme
is to be sent to.
Then, would you include my name and address too?
email: kwang@uicsrd.uiuc.edu
address: Kwangkeun Yi
Center for Supercomputing Research & Development
305 Talbot Lab. 104 S.Wright st.
Urbana, IL 61801-2932
Thankyou very much, -Kwangkeun
∂11-Oct-88 2056 NET-ORIGIN@MC.LCS.MIT.EDU Re: self-replicating code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Oct 88 20:55:54 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 OCT 88 22:20:34 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA24121@EDDIE.MIT.EDU>; Tue, 11 Oct 88 22:19:59 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA04466@BLOOM-BEACON.MIT.EDU>; Tue, 11 Oct 88 21:59:27 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Oct 88 21:58:29 GMT
From: killer!pollux!ti-csl!mips!gateley@eddie.mit.edu (John Gateley)
Organization: TI Computer Science Center, Dallas
Subject: Re: self-replicating code
Message-Id: <60753@ti-csl.CSNET>
References: <8810111207.AA15692@BLOOM-BEACON.MIT.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8810111207.AA15692@BLOOM-BEACON.MIT.EDU> STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU ("G.OULSNAM") writes:
>If one has a normal-order evaluator in Scheme rather than an applicative
>order one then the simplest self-replicating lambda expression is
>
> ((lambda (x) (x x)) (lambda (x) (x x)))
>
>since the argument expression is substituted without being evaluated, but
>loops forever with applicative order.
[rest of derivation]
>Any comments?
>Gordon Oulsnam
I did not try to follow the rest of the derivation. Your first statement
is incorrect. The expression is an infinite loop in both normal and
applicative order evaluation. Also, the problem is even more complex
than normal order/applicative order. Scheme is a by-value system, which means
that
(lambda (x) (infinite-loop))
terminates in Scheme, but not in a by name system (such as the lambda calc).
I could not think of the smallest normal-order self-replicating code off
the top of my head.
John
gateley@mips.csc.ti.com
∂12-Oct-88 0224 @MC.LCS.MIT.EDU:gyro@kestrel.arpa self reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 02:24:15 PDT
Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 12 Oct 88 04:08:34 EDT
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA16036; Wed, 12 Oct 88 01:07:26 PDT
Date: Wed, 12 Oct 88 01:07:26 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8810120807.AA16036@kestrel.arpa>
To: carr%car@cs.utah.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
Here's a fun variation: write a Lisp function which returns its own
defining form (that is, a form EQUAL to the one you typed in to define
the function in the first place).
My solution to follow. No doubt there are many.
-- Scott
∂12-Oct-88 0917 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE Self-reproducing code (correction)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 09:17:17 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 12 Oct 88 12:11:03 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9799; Wed, 12 Oct 88 12:07:43 EDT
Received: from IRUCCIBM by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 9798;
Wed, 12 Oct 88 12:06:34 EDT
Received: from IRUCCVAX.UCC.IE by IRUCCIBM (Mailer X1.25) with BSMTP id 1372;
Wed, 12 Oct 88 16:34:38 IST
Date: Wed, 12 Oct 88 16:35 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: Self-reproducing code (correction)
To: SCHEME@MC.LCS.MIT.EDU
X-VMS-To: SCHEME
My thanks to John Gateley for pointing out the erroneous claim regarding
the normal order/applicative order evaluation of ((lambda (x) (x x) (lambda
(x) (x x)). I'm sorry he chose not to examine the rest of the derivation,
as it did not rely on the erroneous claim. For the record, what I now
consider I should have written was:
"Consider
((lambda (x) (x x)) (lambda (x) (x x))).
With normal order evaluation this reproduces itself, but loops forever on
attempting to evaluate the result. However, in Scheme the
argument is evaluated to an internal procedure, say #<procedure>, which
then loops forever trying to evaluate the first (x x) in the above
expression, without reproducing the original form directly."
The remark about Scheme applies to TI Scheme (v2), and can be checked by
depositing extra code to see what is being passed around. My point was, and
remains, that both normal order and applicative order (by-value in Scheme)
cause the above to loop, but for different reasons. Normal order provided
the idea for self-reproducing code, if one could first find a way to
emulate normal order evaluation, and then find a way to stop evaluation of
the result. The remainder of the article showed how.
Gordon Oulsnam.
∂12-Oct-88 1002 @MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU self reproducing messages.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 10:02:00 PDT
Received: from mojave.Stanford.EDU (TCP 4405400170) by MC.LCS.MIT.EDU 12 Oct 88 12:22:07 EDT
Received: by mojave.Stanford.EDU (5.59/inc-1.0)
id AA02612; Wed, 12 Oct 88 09:22:17 PDT
Date: Wed, 12 Oct 88 09:22:17 PDT
From: daniel@mojave.Stanford.EDU (Daniel Weise)
Message-Id: <8810121622.AA02612@mojave.Stanford.EDU>
To: scheme@mc.lcs.mit.edu
Subject: self reproducing messages.
The entropy on this list is increasing. Please stop sending messages
on self reproducing code.
Daniel
∂12-Oct-88 1042 NET-ORIGIN@MC.LCS.MIT.EDU Re: Self-reproduction
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Oct 88 10:42:12 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 OCT 88 12:36:11 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07031@EDDIE.MIT.EDU>; Wed, 12 Oct 88 12:35:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA19237@BLOOM-BEACON.MIT.EDU>; Wed, 12 Oct 88 12:09:38 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Oct 88 22:58:15 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Subject: Re: Self-reproduction
Message-Id: <26381@ucbvax.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
A cute trick, not quite a self-reproducing program, but an interesting
example of a string that produces itself, is to take an arbitrary error
message, and hand it back to the interpreter as input. On many systems if
you repeat this 4-8 times, you reach a fixed point at which no further
change occurs. This is also fun with a C compiler.
∂13-Oct-88 1256 @MC.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing messages.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 12:56:00 PDT
Received: from cs.utah.edu (TCP 20033402025) by MC.LCS.MIT.EDU 12 Oct 88 13:25:57 EDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA09477; Wed, 12 Oct 88 11:25:17 MDT
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29636; Wed, 12 Oct 88 11:25:13 MDT
Date: Wed, 12 Oct 88 11:25:13 MDT
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8810121725.AA29636@car.utah.edu>
To: daniel@mojave.stanford.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Daniel Weise's message of Wed, 12 Oct 88 09:22:17 PDT <8810121622.AA02612@mojave.Stanford.EDU>
Subject: Re: self reproducing messages.
On the contrary, I want to receive as many replies as possible on
self-reproducing code, so please do send more if it doesn't duplicate
any previous submissions.
Thank you, Harold
∂13-Oct-88 1327 @MC.LCS.MIT.EDU:hoey@aic.nrl.navy.mil Automatic programming
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 13:27:21 PDT
Received: from aic.nrl.navy.mil (TCP 3200200010) by MC.LCS.MIT.EDU 12 Oct 88 13:45:38 EDT
Return-Path: <hoey@aic.nrl.navy.mil>
Received: Wed, 12 Oct 88 13:43:58 EDT by aic.nrl.navy.mil id AA19260
Date: Wed, 12 Oct 88 13:43:58 EDT
From: Dan Hoey <hoey@aic.nrl.navy.mil>
Message-Id: <8810121743.AA19260@aic.nrl.navy.mil>
To: scheme@mc.lcs.mit.edu
Subject: Automatic programming
My favorite version of the LAMBDA self-reproducer is
((LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA))
'(LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA)))
though SCHEMErs will have to forgo the pun. There is also
(format t "~A~:*~S)" "(format t \"~A~:*~S)\" ")
Dan
∂13-Oct-88 1819 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 18:19:23 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 20:55:30 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:57:52-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:19:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.
∂13-Oct-88 1903 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 18:19:23 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 20:55:30 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:57:52-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:19:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.
∂13-Oct-88 1934 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 19:33:18 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 22:27:16 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:57:05-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:10:21 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.
∂13-Oct-88 1946 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 19:46:12 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 22:28:21 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:59:15-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 14:19:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.
∂13-Oct-88 2044 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu self reproducing messages.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 20:44:30 PDT
Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU 13 Oct 88 21:06:40 EDT
Received: by kleph.ai.mit.edu (5.59/1.5)
id AA05926; Thu, 13 Oct 88 19:02:33 EDT
Date: Thu, 13 Oct 88 19:02:33 EDT
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8810132302.AA05926@kleph.ai.mit.edu>
To: carr%car@cs.utah.edu
Cc: daniel@mojave.stanford.edu, scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Wed, 12 Oct 88 11:25:13 MDT <8810121725.AA29636@car.utah.edu>
Subject: self reproducing messages.
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 12 Oct 88 11:25:13 MDT
From: carr%car@cs.utah.edu (Harold Carr)
On the contrary, I want to receive as many replies as possible on
self-reproducing code, so please do send more if it doesn't duplicate
any previous submissions.
Thank you, Harold
I agree with Daniel. If you want to talk about self reproducing code,
make your own mailing list. This stuff has little or nothing to do
with Scheme.
Please remember that this is an ENORMOUS mailing list (hundreds of
people). The subscribers to this list are expecting topics pertaining
to Scheme. They have a right to be annoyed when a digression exceeds
a few messages (this one is already in the tens).
∂13-Oct-88 2126 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu report on Snowbird authors' meeting
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Oct 88 21:25:49 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 19:54:10 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Wed 12 Oct 88 21:58:29-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 12 Oct 88 13:49:36 PDT
Received: by fog.cs.uoregon.edu; Wed, 12 Oct 88 13:10:08 PDT
Date: Wed, 12 Oct 88 13:10:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810122010.AA16313@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: report on Snowbird authors' meeting
At long last, this is my report on what happened at the Scheme
authors' meeting on 24 July 1988 at Snowbird. The report has
three parts:
1. a summary of changes to the R3RS that will be made in the R4RS
2. a review of the things that still need to be done for R4RS
3. the action taken on each agenda proposal, with a summary of the debate
Hal Abelson chaired the meeting and did a very fine job. About fifty people
attended.
--------------------------------------------------------------------------------
PART 1. Changes that will appear in the R4RS.
These changes are numbered as in the list of proposals as compiled, and edited
capriciously, by J Rees on 13 July 1988. Changes that did not appear in that
list are identified by letters rather than numbers.
1.1. Implementations must provide some way for programmers to work in a
syntactic environment that preempts no lexical conventions of the Report
and reserves no words other than those used in the Report.
1.2. The sets defined by the following predicates will be required to be
disjoint: boolean?, pair?, symbol?, number?, char?, string?, vector?,
procedure?.
1.3. The variables NIL and T will be removed from the Report.
1.5, 1.6, 1.7, 1.8. Certain sentences will be clarified.
1.10, 1.11, 1.12. The syntax of numbers will be changed, becoming closer to
the syntax used in Common Lisp. Changes include:
The radix prefix will precede the sign, eg #x-ab.
The exactness prefix will precede the sign, eg #i-3.
Exponents will be illegal in rational syntax.
Exponents will be illegal unless the radix is 10.
The precision prefix is to be replaced by exponent markers as in Common Lisp,
eg 1S3, 1F3, 1D3, 1L3, 1E3.
Any constant with an imaginary part will be required to have an explicit sign
in front of the imaginary part. The formal syntax, to be written by
Clinger, will be along the lines of [ [ + | - ] a ] (+ | -) [ b ] i.
1.13. A numeric constant will be considered exact unless it contains one of
the following:
#i explicit inexactness prefix
@ polar notation
. an explicit decimal point
# imprecise digits
e exponent marker
s exponent marker
f exponent marker
d exponent marker
l exponent marker
1.14. The list of formal variables in LAMBDA, LET, LETREC, and DO expressions
must not contain duplications.
1.15. RATIONALIZE is to be made exactness-preserving and its ambiguous
specification fixed.
A. The branch cuts for ATAN will be corrected to be whatever Steele says.
B. INTEGER->CHAR will require an exact integer argument.
C. APPROXIMATE will disappear. The one-argument form of RATIONALIZE will
either disappear or be defined so it makes sense without assuming any
particular internal representations. The behavior of various procedures when
given inexact arguments will be clarified: ZERO?, POSITIVE?, NEGATIVE?, EVEN?,
ODD?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=. The semantics of NUMBER->STRING
and STRING->NUMBER will be clarified or changed.
2.1. The following syntaxes and procedures become essential:
CASE, AND, OR, QUASIQUOTE
APPEND with zero or more arguments
REVERSE
MAX, MIN, MODULO, GCD, LCM, FLOOR, CEILING, TRUNCATE, ROUND
+ and * with zero or more arguments
- and / with one argument
some yet-to-be-determined form of NUMBER->STRING, STRING->NUMBER
CHAR-CI?, CHAR-CI<?, CHAR-CI>?, CHAR-CI<=?, CHAR-CI>=? (two arguments only)
CHAR-ALPHABETIC?, CHAR-NUMERIC?, CHAR-WHITESPACE?
CHAR-LOWER-CASE?, CHAR-UPPER-CASE?, CHAR-UPCASE, CHAR-DOWNCASE
MAKE-STRING (with one or two arguments)
STRING-SET!
STRING-CI?, STRING-CI<?, STRING-CI>?, STRING-CI<=?, STRING-CI>=?
(two arguments only)
STRING-APPEND
MAP and FOR-EACH with two or more arguments
OPEN-INPUT-FILE, OPEN-OUTPUT-FILE, CLOSE-INPUT-PORT, CLOSE-OUTPUT-PORT
LAST-PAIR will disappear from the report.
[Note: the following syntaxes and procedures will be the only features
from R3RS that remain inessential in R4RS:
(if E0 E1)
(let* ...)
(do ...)
named let
internal definitions
delay
list-tail
list-ref
- and / with more than two arguments
string-copy, string-fill!
vector-fill!
apply with more than two arguments
force
with-input-from-file, with-output-to-file
char-ready?
transcript-on, transcript-off
The first five will probably appear in the first draft of the IEEE standard
without being qualified as inessential.]
D. A section on immutable structures will be added. Immutable structures
will be defined as pairs, vectors, strings, or other structures for which
it is an error to attempt to assign a new value to an element of the
structure. Data structures that appear as constants will be immutable.
[Note: This is merely a clarification. See the last sentence of section
4.1.2 in R3RS.]
E. Something resembling EXTEND-SYNTAX without WITH and based on
syntactic closures will be added to the Report as an inessential feature,
provided the macro committee delivers something reasonable in time.
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
--------------------------------------------------------------------------------
PART 2. Things that still need to be done for R4RS.
1.10, 1.11, 1.12. Formal syntax of numeric constants: Clinger.
1.15. Clarify semantics of RATIONALIZE, ZERO?, EVEN?, ODD?, POSITIVE?,
NEGATIVE?, NUMERATOR, DENOMINATOR, =, <, >, <=, >=, NUMBER->STRING,
STRING->NUMBER: Dybvig, Bawden, Sussman.
A. Decide on branch cuts for ATAN: Steele.
3.1. Propose macro facility: Bawden, Rees, Dybvig, Heib.
If the macro committee gets stuck, R4RS will go forward without macros.
Although the following proposals were not adopted at Snowbird, there seemed
to be consensus on the general issue but a problem with details. New
proposals were solicited. If a timely and detailed proposal on one of these
issues can survive discussion on RRRS-AUTHORS, then it will go into R4RS.
1.4. Propose major rewrite of section on equivalence predicates:
Miller, Rees, Clinger.
2.2. Propose regularization of procedures: Katz.
4.4. Propose a better name for named let: anyone.
--------------------------------------------------------------------------------
PART 3. Action taken on each agenda proposal.
1.1. Reserved words and portable code. Adopted by acclamation. Noted:
lexical extensions are ok so long as they don't conflict with the lexical
conventions of the Report.
1.2. Disjointness of types. Adopted by acclamation. Two people objected
to requiring (NOT (EQ? #F '())). Promises and ports were considered but were
not added to the list of disjoint types.
1.3. Eliminate NIL, T. Adopted by acclamation.
1.4. EQV? Not adopted. Reasons: The body of the Report should not refer to
the formal semantics. If the body is not precise enough to stand on its own,
it should be made more precise. Locations should therefore be discussed in
the sections on pairs, vectors, strings, and procedures. Sentences should be
collapsed wherever possible. The disjointness of types creates some changes
and should simplify the discussion.
1.5. Change wording of LETREC restriction. Adopted by acclamation after
improving the proposed wording to "One restriction on LETREC is very important:
it must be possible to evaluate each <init> without assigning or referring to
the value of any <variable>. If this restriction is violated, then it is an
error."
1.6. Clarify wording of LETREC. Adopted by acclamation without debate.
1.7. Clarify status of CI. Adopted by acclamation without debate.
1.8. Clarify the specification of TRUNCATE. Adopted by acclamation without
debate.
1.9. Improve the discussion of exactness and inexactness. Not debated per se.
See C.
1.10. Change the syntax of numbers. The syntax of complex numbers occasioned
much debate, with the result summarized in part 1. The discussion of 1.11 and
1.12 was combined with the debate on 1.10, and my notes make it appear that no
separate vote was taken for 1.11 or 1.12. Below I say that 1.11 and 1.12 were
adopted by acclamation because complex numbers were the only source of
controversy.
1.11. Clarify the status of exponents. Adopted by acclamation. It was noted
that the grammar would be clearer if <digit> were <digit 10>.
1.12. Exponents illegal in fractions. Adopted by acclamation.
1.13. Exactness and inexactness of constants. Modified by adding exponent
markers to the list of things that indicate inexactness, and then adopted by
acclamation.
1.14. Make duplicated formals illegal. Adopted by acclamation. Debate
clarified that "illegal" should mean "is an error".
1.15. Clarify semantics of RATIONALIZE. Adopted by acclamation. Note:
the proposal was to change "smallest denominator" to "simplest denominator"
and to make RATIONALIZE exactness-preserving. [Private discussion following
the IEEE meeting raised further issues that need to be addressed.]
A. Branch cuts for ATAN. Adopted by acclamation. The R3RS got the branch
cuts wrong because I copied Steele and Common Lisp, who copied Penrose (?) and
APL. Penrose now says he got them wrong, and Steele says he got them wrong and
wants to change Common Lisp.
B. Require exact argument for INTEGER->CHAR. Adopted by acclamation.
C. Clarify semantics of arithmetic procedures on inexact arguments, and fix
NUMBER->STRING and STRING->NUMBER. Questions about the semantics of these
procedures persist. By acclamation Dybvig, Bawden, and Sussman were given
the task of fixing them. Noted: STRING->NUMBER would be more useful if it
returned false when it failed to parse the string.
2.1. Flush inessential features. For every inessential feature in R3RS, the
chair asked whether anyone objected to flushing it and whether anyone objected
to making it essential. The unanimous decisions were listed in part 1. The
only inessential feature that everyone wanted to flush was LAST-PAIR.
D. Add section on immutable structures. Adopted by acclamation. This
issue arose during debate on making STRING-SET! essential.
2.2. Make procedures more regular. Not debated very much. Katz volunteered
to develop a concrete proposal.
2.3. Underspecification. The value returned by SET! was discussed as an
example. There are at least two distinct useful values that might be
returned, as well as the conservative #!unspecified. No consensus but
probably a useful debate.
3.1. Macros. Pre-adopted by acclamation. That is, we voted to trust a
committee composed of Bawden, Rees, Dybvig, and Hieb. Everyone seems to
want macros, and impatience is beginning to win out over contrary desires
that one's favorite approach to macros be chosen.
3.2. Modules. Not adopted.
3.3. Replace LOAD with INCLUDE. Not adopted.
3.4. First class environments. Not adopted.
3.5. Add EVAL. Not adopted.
3.6. Add second argument to LOAD. Not adopted.
F. Flatten BEGIN forms containing definitions. Adopted by acclamation.
My notes are not clear on how this issue arose, but it may have been part
of the debate on INCLUDE. It was noted that a form of INCLUDE could be
implemented as a macro if we had macros and BEGIN forms were flattened.
3.7. Add LAMBDA*. Not adopted. The main objection seemed to be that
this proposal requires a new kind of stored value (multiple values) that
either is not an expressed value or does not behave like other expressed
values.
3.8. Multiple return values. Not adopted. Debate centered on whether
returning a single "multiple value" should be equivalent to returning
that value normally. A secondary issue concerned whether extra return
values should be ignored or an error. We approached consensus on this.
After much debate it was decided to go on to other issues and let
Dybvig and Hanson discuss the matter in private. Their discussion
later that night led to a conclusion that we don't understand the
issues well enough to charge ahead with either proposal 3.7 or 3.8
or a variation.
3.9. Optional arguments. Not considered, as it was felt that this
would be a more controversial issue than proposal 3.8 on which we had
just spent a great deal of time.
3.10. Record types. Not adopted. Rozas opposes opaqueness, but might
be willing to accept disjointness of new types.
At this point we were nearly out of time, so the chair decided to go
around the room, letting each person state the one change that he or
she would like to make. There was not much time for debate.
3.11. Add TYPE-OF. Not adopted. Noted: a predicate TYPE? would be
more in the spirit of Scheme.
4.20. Change the specification of AND. Not adopted. This proposal
was incorrect in the list of proposals that was sent out. [My fault
-- Clinger] It should have been: "AND will return a true value or
a false value" and does not have to return the value of the last
expression it evaluates.
4.4 Eliminate named let. Most people seemed willing to change the
name of named let. RECUR was suggested but objected to. It was
agreed that we would go away, nominate and agree on a better name,
and use it in R4RS. [So far a number of names have been nominated
but none have been agreed upon.]
4.24. Rename CHAR-READY? to READ-CHAR-READY? Not adopted.
4.5. Eliminate =>. Not adopted.
∂14-Oct-88 0056 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Self-reproducing code
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Oct 88 00:56:36 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Oct 88 03:44:02 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA07904@BLOOM-BEACON.MIT.EDU>; Thu, 13 Oct 88 23:46:04 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Oct 88 09:58:03 GMT
From: mcvax!enea!kth!draken!Urd!newsuser@uunet.uu.net (LTH network news server)
Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden
Subject: Self-reproducing code
Message-Id: <1988Oct12.105804.3747@LTH.Se>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Several examples of self-reproducing code has been given in this group
lately. While running a definite risc of reminding people of what may
be already generally known, I would like to submit the shortest solution
of all. And not only the shortest, it will work in almost any language!
The solution is:
The only problem with this solution, the empty program, is that someone
might argue that it is not a program at all. Still, I think it has a
certain elegance to it.
"Real Programmers aren't afraid of RISC architectures."
--
Jan Eric Larsson janeric@Control.LTH.Se +46 46 108795
Department of Automatic Control
Lund Institute of Technology "We watched the thermocouples dance to the
Box 118, S-221 00 LUND, Sweden spirited tunes of a high frequency band."
∂14-Oct-88 0126 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Help!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Oct 88 01:26:32 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Oct 88 03:44:41 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA07620@BLOOM-BEACON.MIT.EDU>; Thu, 13 Oct 88 23:34:15 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Oct 88 02:53:20 GMT
From: apple!bionet!agate!web-2h.berkeley.edu!c60a-2ce@bloom-beacon.mit.edu (Mikey)
Organization: University of California, Berkeley
Subject: Help!
Message-Id: <15438@agate.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Can someone please explain to me the differences and relative benefits of the following:
using manifest types, data-directed programming, message-passing.
---------------------------------------------------------------------
Please reply via e-mail; I just don't have enough time to go thru
the entire newsgroup. Thanks a lot!
"A little coitus, neva hoit us!"
c60a-2ce@web.berkeley.edu@ucbvax.berkeley.edu................Mike Kao
∂17-Oct-88 1725 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:carr%car@cs.utah.edu Re: self reproducing messages.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 17:25:44 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Oct 88 18:59:50 EDT
Received: from cs.utah.edu by XX.LCS.MIT.EDU with TCP/SMTP; Mon 17 Oct 88 14:58:38-EDT
Received: from car.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
id AA00275; Mon, 17 Oct 88 10:45:12 MDT
Received: by car.utah.edu (5.59/utah-2.0-leaf)
id AA02636; Mon, 17 Oct 88 10:39:28 MDT
Date: Mon, 17 Oct 88 10:39:28 MDT
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8810171639.AA02636@car.utah.edu>
To: cph@zurich.ai.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Oct 88 19:02:33 EDT <8810132302.AA05926@kleph.ai.mit.edu>
Subject: Re: self reproducing messages.
OK, even though this list is pretty quiet most of the time, it looks
as if Chris and Daniel would like it to remain that way. But please,
feel free to continue sending examples of self reproducing code
directly to me (I never said cc to scheme@mc.lcs.mit.edu in the first
place).
Thanks for the replies so far, and sorry for "annoying" anyone else.
Harold Carr
∂17-Oct-88 1805 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu Regularization of Procedures in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Oct 88 18:05:00 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Oct 88 19:30:40 EDT
Received: from sesame.stanford.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 14 Oct 88 17:59:25-EDT
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
id AA06921; Fri, 14 Oct 88 14:57:24 PDT
Date: Fri, 14 Oct 88 14:57:24 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8810142157.AA06921@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Regularization of Procedures in Scheme
For those of you who don't remember, I was assigned the task at L&FP to
regularize the procedures involving lists, strings, and vectors for R4RS.
Initially, this looked like a trivial, Noncontroversial task; but, it turns out
that there are actually some important semantic issues to be discussed. I have
therefore decided to pass my ideas before the entire community, rather than
just sending them straight to the editors.
I will begin this discussion with what I believe are the Noncontroversial
changes and then proceed to the Controversial ones. In order to better
understand the issues I have included the chart below which enumerates the
relevant procedures currently in R3RS.
LIST STRING VECTOR
---- ------ ------
list vector
make-string make-vector
string-fill vector-fill
list-ref string-ref vector-ref
string-set! vector-set!
string-copy
length string-length vector-length
append string-append
append!
list->string string->list vector->list
list->vector
reverse
substring
string=?
string? vector?
apply
map, foreach
memq, memv, member
assq, assv, assoc
Noncontroversial:
1) Add string, make-list, list-fill, list-set!, list-copy, vector-copy,
vector-append, string->vector, and vector->string with the obvious
semantics.
2) Create aliases list-length and list-append for length and append,
respectively.
3) Append! should NOT be generalized since most implementations (for good
reasons) represent strings and vectors in a manner that is incompatible
with append! semantics.
4) Reverse should NOT be generalized since the extensions would be pretty much
useless.
5) Sublist and subvector should be added because they are potentially useful
and the implementations in scheme are much less efficient than ones which
could be supplied by an implementor.
6) String=? is only present for symetry with string-ci=? and should NOT be
generalized to list=? and vector=? since we already have =?.
Controversial:
1) Create list? which checks for a null terminated list. This CAN be written
by a user and is only marginally useful, but I believe it is important that
it exist for symetry reasons.
2) If we keep both syntaxes for apply
(apply proc args)
(apply proc arg1 arg2 ... args)
then this can't be generalized. However, I believe that we should restrict
ourselves to the first syntax ONLY. Then args could be any of a list,
string, or vector whose elements would be spread before the actual
application was performed.
3) There are several possibilities for map and foreach:
a) Status quo
b) Introduce list-map, string-map, vector-map, list-foreach,
string-foreach, and vector-foreach. List-map and list-foreach would be
identical to the current map and foreach, respectively. The others
would have the following syntaxes and semantics
(string-map proc string1 string2 ...)
(vector-map proc vector1 vector2 ...)
(string-foreach proc string1 string2 ...)
(vector-foreach proc vector1 vector2 ...)
The string version would take strings as arguments and in the case of
string-map would return a string. The vector versions would do
similarly. It would be a type error to pass a string to list-map, a
list to vector-map, etc.
c) The same 6 procedures would be introduced as in b). In this case the
name would specify the type of the return value. The procedures would
be polymorphic over arguments of type list, string, and vector. All
that would be required would be that the arguments all have the same
length.
I am personally in favor of either b) or c). I like the semantics of c),
but realize that some implementors may find its semantics objectionable.
4) Memq, memv, and member are quite problematic. They could be extended to
allow the second argument to be a vector in the obvious way, but then what
should they return on a match. Returning a subvector is unsatisfactory
because the aliasing one gets with a sublist would undoubtedly not be
present for a subvector, and thus the original structure could not be
modified based on the result. In my experience, this is one of the most
common uses for these procedures and it would be negated. Another
alternative is just to return #t and #f. However, these seems to be
unintuitively incompatible with the original versions. Extensions for
strings are even worse, because the equivalence distinctions between eq,
eqv, and equal are not present and have instead been replaced by case
sensativity and insensitivity. MY RECOMMENDATION IS TO MAKE NO EXTENSION.
5) Any extensions to assq, assv, and assoc have similar problems to those of
memq, etc. and I therefore again RECOMMEND NO EXTENSION.
6) As a result of 5) and 6), I suggest adding two new families of procedures
which for the sake of exposition I will call member? and match. (I know
these are horrible names, but if people like the idea, we'll worry about
what to call them later.) Their syntaxes would be as follows:
(list-member? val pred list)
(string-member? val pred string)
(vector-member? val pred vector)
(list-match val pred list)
(string-match val pred string)
(vector-match val pred string)
The member procedures would return #f if (pred val (foo-ref foo i))
returned #f for all i, where foo is either list, string, or vector.
Otherwise, they would return #t. The match procedures would perform
similarly except that they would the first element for which pred returned
#t, #f otherwise. A decision would have to be made for match as to whether
each element of a vector would have to itself be a vector. Obviously, for
strings each element would have to be a character and so this version would
be somewhat useless.
As A RESULT, I propose that instead we introduce just the procedures
member? and match which are polymorphic over all the reasonable types
(i.e., strings, vectors, and lists). For match, this polymorphism would
extend to 2 levels into the data structure.
Morry Katz
katz@polya.stanford.edu
∂19-Oct-88 1407 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Self reference in objects
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 14:06:56 PDT
Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 19 Oct 88 16:46:20 EDT
Received: from NORUNIT.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6035; Wed, 19 Oct 88 12:46:35 EDT
Date: Wed, 19 Oct 88 16:59:28 ECT
To: scheme@mc.lcs.mit.edu
From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Self reference in objects
Date: 19 October 1988, 16:51:25 ECT
From: Harald Hanche-Olsen +47-7-593525 HANCHE at NORUNIT
To: scheme@mc.lcs.mit.edu
(I suppose this should be sent directly to Jonathan Dubman who asked
the question, but my mailer would not accept his monstrous address...)
To: apple!bionet!agate!e260-3b.berkeley.edu!128a-3aj@BLOOM-BEACON.MIT.EDU
Jonathan had problems with allowing his objects to refer to themselves.
His objects are defined by lambda expressions, so I can't think of any
reason why the following would not work:
(define (make-player ...)
(letrec
((self (lambda (...) <body of player>)))
self))
or something like it. In <body of player> you can use self
to denote *this* player, like in
(present-room 'move self 'north)
- Harald Hanche-Olsen
∂19-Oct-88 1516 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE Unknown host
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 15:16:00 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 19 Oct 88 16:53:39 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0247; Mon, 17 Oct 88 15:37:22 EDT
Received: from IRUCCIBM by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0246;
Mon, 17 Oct 88 12:28:25 EDT
Received: from IRUCCVAX.UCC.IE by IRUCCIBM (Mailer X1.25) with BSMTP id 3774;
Mon, 17 Oct 88 17:16:48 IST
Date: Mon, 17 Oct 88 17:20 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: Unknown host
To: SCHEME@MC.LCS.MIT.EDU
X-VMS-To: SCHEME
Attn: John Gateley@mips.csc.ti.com
I tried replying to your direct mail (for which thanks) but gateway
CUNYVM.CUNY.EDU claims that your host mips.csc.ti.com is Unknown, so my
mail was returned.
Apologies to everyone else for cluttering up your mail with this message.
Gordon Oulsnam.
∂19-Oct-88 1556 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Limitation with lambda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 15:56:37 PDT
Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 19 Oct 88 16:54:10 EDT
Received: by ZOHAR.AI.MIT.EDU; Tue, 18 Oct 88 09:43:26 edt
Date: Tue, 18 Oct 88 09:43:26 edt
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8810181343.AA00956@zohar>
To: apple!bionet!agate!e260-3b.berkeley.edu!128a-3aj@bloom-beacon.mit.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Jonathan Dubman's message of 17 Oct 88 17:00:42 GMT <15590@agate.BERKELEY.EDU>
Subject: Limitation with lambda
You ask:
For example, how would someone write a function generator that generates the
sum of all squares or cubes or fourths, etc., based on an exponent?
How 'bout:
(define sum-of-powers
(lambda (power)
(lambda (n)
(sum-of (lambda (i)
(expt i power))
n))))
(define sum-of
(lambda (termfun nterms)
(if (= nterms 0)
0
(+ (termfun nterms)
(sum-of termfun (- nterms 1))))))
;;; e.g.
((sum-of-powers 3) 5)
;Value: 225
Does this solve your problem? If not, call me on the phone and I will
try to debug you. My phone is (617) 253-5874.
∂19-Oct-88 1633 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 16:33:06 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 16:59:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 1723 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 17:23:44 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:49:32 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 1742 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 17:42:27 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:51:01 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 1805 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 18:05:13 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:51:54 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 1816 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 18:15:50 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 17:52:44 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 1958 NET-ORIGIN@MC.LCS.MIT.EDU case-lambda syntax in Chez Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 19:58:43 PDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 OCT 88 17:55:36 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA26843@EDDIE.MIT.EDU>; Tue, 18 Oct 88 19:48:26 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA01440@BLOOM-BEACON.MIT.EDU>; Tue, 18 Oct 88 18:28:36 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Oct 88 19:04:12 GMT
From: pierce@locus.ucla.edu
Organization: UCLA Computer Science Department
Subject: case-lambda syntax in Chez Scheme
Message-Id: <16934@shemp.CS.UCLA.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
-
Some good person replied to my example in Re: Limitation with Lambda.
This person pointed out that the "case-lambda" syntax is not standard
Scheme. My apologies, case-lambda is from Chez Scheme Version 2.0,
and I have found it so useful (I use it a *lot*) that I just forgot
that users of other Scheme systems might not know what it meant.
An excerpt from the Chez Scheme Version 2.0 release notes follows. It's
a simple idea that not only makes code easier to write and to understand,
but it also runs faster than the old way. Maybe Kent Dybvig could
be encouraged to post a little more info about case-lambda?
-- Brad Pierce
------------------------------------------------------------------------
(below Copyright Kent Dybvig)
Optional Arguments
Procedures with a variable number of arguments could only be defined
in earlier versions using the "lambda dot" interface, which requires
allocation of a list to hold all but the required parameters.
Version 2.0 supports a variant of "lambda", called "case-lambda",
that allows procedures with variable numbers of arguments to be
defined efficiently. "case-lambda" has the form:
(case-lambda [idspec-a exp1-a exp2-a ...]
[idspec-b exp1-b exp2-b ...] ...)
where the idspecs are normal "lambda" parameter lists. In essence,
each bracketted item (parens may be used in place of the brackets)
represents a different "lambda" expression; which one is evaluated
depends upon the number of arguments. If the number of arguments is
a correct number for the first idspec, evaluation proceeds with the
first body within the bindings implied by the first idspec. If not,
then if the number of arguments is a correct number for the second
idspec, evaluation proceeds with the second body, etc.
∂19-Oct-88 2044 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 20:43:56 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 18:11:44 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂19-Oct-88 2122 @MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET Self reference in objects
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 21:22:37 PDT
Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 19 Oct 88 19:41:55 EDT
Received: from NORUNIT.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 6035; Wed, 19 Oct 88 12:46:35 EDT
Date: Wed, 19 Oct 88 16:59:28 ECT
To: scheme@mc.lcs.mit.edu
From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Self reference in objects
Date: 19 October 1988, 16:51:25 ECT
From: Harald Hanche-Olsen +47-7-593525 HANCHE at NORUNIT
To: scheme@mc.lcs.mit.edu
(I suppose this should be sent directly to Jonathan Dubman who asked
the question, but my mailer would not accept his monstrous address...)
To: apple!bionet!agate!e260-3b.berkeley.edu!128a-3aj@BLOOM-BEACON.MIT.EDU
Jonathan had problems with allowing his objects to refer to themselves.
His objects are defined by lambda expressions, so I can't think of any
reason why the following would not work:
(define (make-player ...)
(letrec
((self (lambda (...) <body of player>)))
self))
or something like it. In <body of player> you can use self
to denote *this* player, like in
(present-room 'move self 'north)
- Harald Hanche-Olsen
∂19-Oct-88 2206 @MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM Self reference in objects (Adventure)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 22:05:57 PDT
Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 19 Oct 88 20:51:49 EDT
Received: from PELE.ACA.MCC.COM (PELE.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 19 Oct 88 16:45:19-CDT
Date: Wed, 19 Oct 88 16:45 CDT
From: Christopher Maeda <maeda@MCC.COM>
Subject: Self reference in objects (Adventure)
To: scheme@mc.lcs.mit.edu
In-Reply-To: The message from HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Message-ID: <19881019214531.1.MAEDA@PELE.ACA.MCC.COM>
From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU
Date: 19 October 1988, 16:51:25 ECT
From: Harald Hanche-Olsen +47-7-593525 HANCHE at NORUNIT
To: scheme@mc.lcs.mit.edu
(I suppose this should be sent directly to Jonathan Dubman who asked
the question, but my mailer would not accept his monstrous address...)
To: apple!bionet!agate!e260-3b.berkeley.edu!128a-3aj@BLOOM-BEACON.MIT.EDU
[...]
Wasn't there a 6.001 problem set on this? Can't we just send the
sources to this guy and be done with it?
∂19-Oct-88 2236 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Oct 88 22:36:41 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 19 Oct 88 21:01:59 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂20-Oct-88 0405 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Limitation with lambda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 04:05:00 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Oct 88 01:49:24 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 19 Oct 88 09:44:10-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA08134@BLOOM-BEACON.MIT.EDU>; Wed, 19 Oct 88 00:06:32 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Oct 88 02:31:35 GMT
From: polya!weening%Gang-of-Four.Stanford.EDU@labrea.stanford.edu (Joe Weening)
Organization: Stanford University
Subject: Re: Limitation with lambda
Message-Id: <4557@polya.Stanford.EDU>
References: <15590@agate.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <15590@agate.BERKELEY.EDU>, 128a-3aj@e260-3b (Jonathan Dubman) writes:
>
>There seems to be a gross omission in the lambda primitive. It seems like
>there is no way to create a recursive function on the fly! I'm reading
>the Abelson and Sussman book but they seem to avoid this issue.
This problem actually has quite an interesting history. From the Lisp
1.5 Programmer's Manual (J. McCarthy et al, 1963), p. 8:
"The lambda notation alone is inadequate for naming recursive
functions. Not only must the variables be bound, but the name of
the function must be bound, since it is used inside an expresion
to stand for the entire expression. ... In order to be able to
write expressions that bear their own name, we introduce the LABEL
notation."
LABEL only defines a single function in terms of itself. Scheme's
LETREC and Common Lisp's LABELS extend this to allow mutually
recursive function definitions.
I don't know if it was known in 1963, but LABEL or its equivalent is
not actually necessary in order to define recursive functions. The
trick is to use the Y combinator. In practice, though, this method
would be fairly inefficient.
--
Joe Weening Computer Science Dept.
weening@Gang-of-Four.Stanford.EDU Stanford University
∂20-Oct-88 1416 @MC.LCS.MIT.EDU:FWHITE@G.BBN.COM Re: Limitation with lambda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 14:16:25 PDT
Received: from G.BBN.COM (TCP 1000400022) by MC.LCS.MIT.EDU 20 Oct 88 14:39:38 EDT
Date: 20 Oct 1988 11:03-EDT
Sender: FWHITE@G.BBN.COM
Subject: Re: Limitation with lambda
From: FWHITE@G.BBN.COM
To: polya!weening%Gang-of-Four.Stanford.EDU@LABREA.STANFORD.EDU
Cc: scheme@MC.LCS.MIT.EDU
Message-ID: <[G.BBN.COM]20-Oct-88 11:03:02.FWHITE>
In-Reply-To: <4557@polya.Stanford.EDU>
In "A Basis for a Mathematical Theory of Computation"* by
McCarthy, which dates from the 1961 Western Joint Computer
Conference, McCarthy mentions that Y can be used to eliminate
LABEL but at the expense of giant resulting expressions.
Who did invent Y, anyways?
------------
* Reprinted in "Computer Programming and Formal Systems",
P. Braffort & D. Hirschberg eds, 1967. See pp 46-7.
∂20-Oct-88 1457 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 14:57:21 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 14:46:56 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂20-Oct-88 1557 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Lisp, Xlisp, Prolog and Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 15:57:20 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 20 Oct 88 17:46:45 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA24672@BLOOM-BEACON.MIT.EDU>; Thu, 20 Oct 88 13:10:42 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Oct 88 02:02:24 GMT
From: portal!cup.portal.com!@uunet.uu.net (Daniel B Hankins)
Organization: The Portal System (TM)
Subject: Lisp, Xlisp, Prolog and Scheme
Message-Id: <10218@cup.portal.com>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I have an application which I would like to prototype in one of the
four subject languages. Please see my posting to comp.lang.misc under the
topic 'Prolog and Lisp'. Comments are solicited.
Thanks.
Dan Hankins
∂20-Oct-88 1939 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 19:39:39 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 18:47:36 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂20-Oct-88 2005 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Oct 88 20:05:27 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 18:52:20 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂21-Oct-88 1420 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Where/how to get Scheme for Suns?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 14:20:20 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 16:45:48 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 20 Oct 88 19:58:07-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA25972@BLOOM-BEACON.MIT.EDU>; Thu, 20 Oct 88 13:56:45 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Oct 88 16:33:04 GMT
From: ccncsu!handel.CS.ColoState.EDU!olender@boulder.colorado.edu (Kurt Olender)
Organization: Colorado State University, Ft. Collins CO 80526
Subject: Where/how to get Scheme for Suns?
Message-Id: <483@ccncsu.ColoState.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I am looking for an implementation of Scheme (no particular
dialect) that will compile to native code for the Sun-3
workstation, preferable PD? Can someone tell me who/where
to contact? Thanks
- Kurt Olender
∂21-Oct-88 1502 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu case-lambda and interpreter environments
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 15:02:41 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 16:46:10 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 20 Oct 88 20:03:44-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA05703@BLOOM-BEACON.MIT.EDU>; Thu, 20 Oct 88 19:56:35 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Oct 88 23:14:22 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Organization: Rice University, Houston
Subject: case-lambda and interpreter environments
Message-Id: <2033@kalliope.rice.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Since there's been some talk of case-lambda, thought I'd say something
about a simple use of this syntax to get a nice implementation of
interpreter environments. The definition of the initial environment
(which doesn't associate any identifier with any value) goes as
follows:
(define init-env
(letrec ([extend (lambda (r x v)
(rec r1
(case-lambda
[(y) (if (eq? y x) v (r y))]
[(y w) (extend r1 y w)])))])
(rec r
(case-lambda
[(x) (error "unbound ~a" x)]
[(x v) (extend r x v)]))))
No other function is required! When called with a single argument (an
identifier), the environment yields the value of the identifier; when
called with two arguments (an identifier and a value) a new
environment is produced which is the extension of the original one
associating the new identifier with the new value.
One attraction (fatal? |-]) with this is that the use of the
environment closely mimics denotational semantics notation, viz.,
r[x] ;for looking up identifier x in environment r; and
r[x/v] ;for extending environment r to associate x with v.
--dorai
∂21-Oct-88 1655 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Where/how to get Scheme for Suns?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 16:55:05 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 19:01:02 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 20 Oct 88 15:48:34-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA29392@BLOOM-BEACON.MIT.EDU>; Thu, 20 Oct 88 15:38:34 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Oct 88 18:21:46 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
Subject: Re: Where/how to get Scheme for Suns?
Message-Id: <3007@uoregon.uoregon.edu>
References: <483@ccncsu.ColoState.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <483@ccncsu.ColoState.EDU> olender@handel.CS.ColoState.EDU (Kurt Olender) writes:
>I am looking for an implementation of Scheme (no particular
>dialect) that will compile to native code for the Sun-3
>workstation, preferable PD? Can someone tell me who/where
>to contact? Thanks
>
> - Kurt Olender
After being irritated by the slowness of C-Scheme, I decided to try
the T dialect of Scheme. It is available via anonymous from
prep.ai.mit.edu in the "t" subdirectory. Versions are available for the
Sun and the Vax. I have used the sun version extensively, and find it
very nice, and it compiles to very good native code.
There are some trivial differences between T and Scheme, but they
are both based on the R3RS, so problems should be minimal.
∂21-Oct-88 2031 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Regularization of Procedures in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 20:30:54 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 22:54:50 EDT
Received: from Xerox.COM by XX.LCS.MIT.EDU with TCP/SMTP; Thu 20 Oct 88 23:33:33-EDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 14:56:47 PDT
Date: Tue, 18 Oct 88 14:26:24 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme
In-reply-to: <8810181537.AA09016@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881018-145647-512@Xerox>
I am convinced by CPH that STRING has its uses.
I don't think that storage efficiency is a valid reason for separating
strings and vectors; Common Lisp implementations manage this just fine.
Remember, the separation could still exist at the implementation level,
invisible to the programmer. I am, however, willing to drop the issue, now
that I've seen some reasons given (by CPH) for the split.
Morry, you ask me to ``See earlier reply to same question'' in response to
my question about why the long form of APPLY has anything to do with making
it polymorphic on the final argument. I didn't see an earlier reply that
seemed applicable.
Concerning ``polymorphism at two levels'' for the MATCH procedure: Isn't
all of the polymorphism at the second level contained in the predicate and
not at all part of MATCH's contract?
Pavel
∂21-Oct-88 2043 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Regularization of Procedures in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 20:42:53 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 21 Oct 88 22:55:58 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 21 Oct 88 02:50:25-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 20 Oct 88 03:28:14 PDT
Received: by fog.cs.uoregon.edu; Wed, 19 Oct 88 17:04:35 PDT
Date: Wed, 19 Oct 88 17:04:35 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810200004.AA15397@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Regularization of Procedures in Scheme
Another response to Morry's proposal.
But first a response to Pavel:
- I prefer (string #\↑ c)
to (let ((s (make-string 2 #\↑))) (string-set! s 1 c) s).
- For reasons of efficiency, I would like to keep gratuitous polymorphism
out of the standard Scheme procedures. For example, if VECTOR-REF had
to work on both vectors and strings, it probably wouldn't be coded
in-line (as it and STRING-REF are in MacScheme). Furthermore a type/
representation inference system probably couldn't infer enough to be
useful when it saw a use of VECTOR-REF. And what's the point of giving
up this efficiency? It is very rare to know that something is either a
vector or a string but not to know which, so making VECTOR-REF work on
both vectors and strings seems gratuitous.
- A hand-coded SUBLIST might be faster (e.g. you could schedule a CAR so
that a cache miss would result in the load being overlapped with the
storage allocation for a CONS), but I don't think such arguments should
determine what goes in the report and what goes in the yellow pages
since there's nothing to stop implementations from providing custom
versions of procedures that appear in the yellow pages if they feel
the custom versions are needed for efficiency. I'd rather add Chris
Hanson's 75 or so string procedures to the yellow pages than argue
about which 5 or so are the most important to add to the report.
Maybe we should organize part of the yellow pages into auxiliary
reports for each major data type, with the code as an appendix.
Response to Morry:
- The names of the string-fill! and vector-fill! procedures should include
an exclamation point.
Non-controversial #1:
I object to make-list, list-fill!, list-set!, and list-copy on the
grounds that they are useful only for side-effect-full programming on
lists, which I claim is an unusual style that the standard should not
encourage. The corresponding procedures for strings and vectors are
less objectionable because side-effect-full programming on strings
and vectors is normal in Scheme. The procedures whose absence from
the report are most noticeable to me are string-set and vector-set
(without the exclamation marks); these are analogues of cons, used
for side-effect-free programming with strings and vectors. By the
way, string-set and vector-set show why e.g. (vector-set! v i e)
should not be required to return e. Implementations should be allowed
to return v for compatibility with vector-set, as MacScheme does.
Controversial #1:
MacScheme also supplies proper-list?, which returns #f on circular
lists as well as on lists terminated by something other than the
empty list. The syntax-checking pass of the compiler uses it a lot.
Controversial #2:
I agree with Pavel. My inclination is not to generalize apply until
we understand where we're going with optional arguments and such. The
connection is that optional arguments are now implemented using rest
arguments, which are wired in as lists, which end up being the most
common final argument to apply. This was probably a mistake, which
will be hard enough to undo even without further complications.
Controversial #3:
I oppose b) because there is no particular reason for the result of
string-map, say, to be a string rather than a vector. If we're going
to generalize, let's do it right with c). I propose, however, that
someone just post the polymorphic procedures list-map, string-map,
and vector-map to the yellow pages. They're trivial to write poorly
(just convert all the arguments to lists and call map) and probably
impossible to write efficiently except for special cases. Similarly
for the highly polymorphic version of for-each.
Controversial #6:
I agree with Pavel: these should be in the yellow pages rather than the
report. By the way, I think the predicate argument should be the first.
Peace, Will
∂21-Oct-88 2142 @MC.LCS.MIT.EDU,@RELAY.CS.NET:stumpf@cogsys.psychologie.uni-freiburg.dbp.de Re: self reproducing messages.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Oct 88 21:42:37 PDT
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 21 Oct 88 23:02:39 EDT
Received: from relay2.cs.net by RELAY.CS.NET id ba04850; 21 Oct 88 18:04 EDT
Received: from zix.gmd.dbp.de by RELAY.CS.NET id ap06834; 21 Oct 88 17:33 EDT
Received: from zix.gmd.dbp.de by .zix.gmd.dbp.de id a003549; 21 Oct 88 19:52 MET
Date: 21 Oct 88 14:37 GMT+0100
From: Michael Stumpf <stumpf%cogsys.psychologie.uni-freiburg.dbp.de@RELAY.CS.NET>
To: Harold Carr <carr%car@CS.UTAH.EDU>
Cc: scheme@MC.LCS.MIT.EDU
MMDF-Warning: Parse error in original version of preceding line at gmdzix.csnet
In-Reply-To: <<8810171639.AA02636@car.utah.edu>>
Message-ID: <282:stumpf@cogsys.psychologie.uni-freiburg.dbp.de>
Subject: Re: self reproducing messages.
Harold,
perhaps the best way to do it is to collect all examples of
self-reproducing programs or whatsoever and to distribute the
commented list through the scheme mailing list... I think that
most of the people listening to it are in fact interested in
the examples, but are not willing to step through each of the
messages.
Of course, its a problem with the cc message field...
Michael.
∂22-Oct-88 1219 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Limitation with lambda
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 12:19:33 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Oct 88 14:18:53 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA21584@BLOOM-BEACON.MIT.EDU>; Sat, 22 Oct 88 13:24:13 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Oct 88 20:24:11 GMT
From: mcvax!enea!kth!draken!chalmers!cs.chalmers.se!augustss@uunet.uu.net (Lennart Augustsson)
Organization: Dept. of CS, Chalmers, Sweden
Subject: Re: Limitation with lambda
Message-Id: <2769@fnatte.cs.chalmers.se>
References: <15590@agate.BERKELEY.EDU>, <4557@polya.Stanford.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <4557@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes:
>In article <15590@agate.BERKELEY.EDU>, 128a-3aj@e260-3b (Jonathan Dubman) writes:
>>
>>There seems to be a gross omission in the lambda primitive. It seems like
>>there is no way to create a recursive function on the fly! I'm reading
>>the Abelson and Sussman book but they seem to avoid this issue.
... [ Talk about LABEL ] ...
>
>I don't know if it was known in 1963, but LABEL or its equivalent is
>not actually necessary in order to define recursive functions. The
>trick is to use the Y combinator. In practice, though, this method
>would be fairly inefficient.
It was certainly known in 1963, the question is who knew it. The fact that
Y can be defined in terms of (nonrecursive) functions was discovered in the
30s (I think) by Haskell B. Curry. He didn't die until the -83 (or so) so
at least he knew, and assuming that people read his books others knew as well.
The problem is that probably very few computer scientist knew about it (well,
it's not really a problem since this definition(s) of Y is of theoretical
interest only).
--
Lennart Augustsson
Email: augustss@cs.chalmers.se or augustss@chalmers.csnet
∂22-Oct-88 1543 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:jar@void.ai.mit.edu Where/how to get Scheme for Suns?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 15:43:35 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Oct 88 18:27:46 EDT
Received: from void.ai.mit.edu by XX.LCS.MIT.EDU with TCP/SMTP; Sat 22 Oct 88 12:18:12-EDT
Received: by void.ai.mit.edu (5.59/1.5)
id AA02865; Sat, 22 Oct 88 12:22:10 EDT
Date: Sat, 22 Oct 88 12:22:10 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810221622.AA02865@void.ai.mit.edu>
To: uoregon!markv@beaver.cs.washington.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Mark VandeWettering's message of 20 Oct 88 18:21:46 GMT <3007@uoregon.uoregon.edu>
Subject: Where/how to get Scheme for Suns?
Reply-To: jar@zurich.ai.mit.edu
Date: 20 Oct 88 18:21:46 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
After being irritated by the slowness of C-Scheme, I decided to try
the T dialect of Scheme. It is available via anonymous from
prep.ai.mit.edu in the "t" subdirectory. Versions are available for the
Sun and the Vax. I have used the sun version extensively, and find it
very nice, and it compiles to very good native code.
Please get T version 3.1 from wheaties.ai.mit.edu. I think there's a
/pub/t3.1 directory. Prep only has T version 3.0.
∂22-Oct-88 1617 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Regularization of Procedures in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 16:16:51 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Oct 88 18:47:55 EDT
Received: from mist.math.uoregon.edu by XX.LCS.MIT.EDU with TCP/SMTP; Fri 21 Oct 88 02:50:49-EDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Thu, 20 Oct 88 11:32:04 PDT
Received: by fog.cs.uoregon.edu; Wed, 19 Oct 88 17:04:35 PDT
Date: Wed, 19 Oct 88 17:04:35 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810200004.AA15397@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re: Regularization of Procedures in Scheme
Another response to Morry's proposal.
But first a response to Pavel:
- I prefer (string #\↑ c)
to (let ((s (make-string 2 #\↑))) (string-set! s 1 c) s).
- For reasons of efficiency, I would like to keep gratuitous polymorphism
out of the standard Scheme procedures. For example, if VECTOR-REF had
to work on both vectors and strings, it probably wouldn't be coded
in-line (as it and STRING-REF are in MacScheme). Furthermore a type/
representation inference system probably couldn't infer enough to be
useful when it saw a use of VECTOR-REF. And what's the point of giving
up this efficiency? It is very rare to know that something is either a
vector or a string but not to know which, so making VECTOR-REF work on
both vectors and strings seems gratuitous.
- A hand-coded SUBLIST might be faster (e.g. you could schedule a CAR so
that a cache miss would result in the load being overlapped with the
storage allocation for a CONS), but I don't think such arguments should
determine what goes in the report and what goes in the yellow pages
since there's nothing to stop implementations from providing custom
versions of procedures that appear in the yellow pages if they feel
the custom versions are needed for efficiency. I'd rather add Chris
Hanson's 75 or so string procedures to the yellow pages than argue
about which 5 or so are the most important to add to the report.
Maybe we should organize part of the yellow pages into auxiliary
reports for each major data type, with the code as an appendix.
Response to Morry:
- The names of the string-fill! and vector-fill! procedures should include
an exclamation point.
Non-controversial #1:
I object to make-list, list-fill!, list-set!, and list-copy on the
grounds that they are useful only for side-effect-full programming on
lists, which I claim is an unusual style that the standard should not
encourage. The corresponding procedures for strings and vectors are
less objectionable because side-effect-full programming on strings
and vectors is normal in Scheme. The procedures whose absence from
the report are most noticeable to me are string-set and vector-set
(without the exclamation marks); these are analogues of cons, used
for side-effect-free programming with strings and vectors. By the
way, string-set and vector-set show why e.g. (vector-set! v i e)
should not be required to return e. Implementations should be allowed
to return v for compatibility with vector-set, as MacScheme does.
Controversial #1:
MacScheme also supplies proper-list?, which returns #f on circular
lists as well as on lists terminated by something other than the
empty list. The syntax-checking pass of the compiler uses it a lot.
Controversial #2:
I agree with Pavel. My inclination is not to generalize apply until
we understand where we're going with optional arguments and such. The
connection is that optional arguments are now implemented using rest
arguments, which are wired in as lists, which end up being the most
common final argument to apply. This was probably a mistake, which
will be hard enough to undo even without further complications.
Controversial #3:
I oppose b) because there is no particular reason for the result of
string-map, say, to be a string rather than a vector. If we're going
to generalize, let's do it right with c). I propose, however, that
someone just post the polymorphic procedures list-map, string-map,
and vector-map to the yellow pages. They're trivial to write poorly
(just convert all the arguments to lists and call map) and probably
impossible to write efficiently except for special cases. Similarly
for the highly polymorphic version of for-each.
Controversial #6:
I agree with Pavel: these should be in the yellow pages rather than the
report. By the way, I think the predicate argument should be the first.
Peace, Will
∂22-Oct-88 1959 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Peek-char for R4RS?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Oct 88 19:59:17 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 20 Oct 88 22:47:41 EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA12310; Tue, 18 Oct 88 14:55:53 EDT
Posted-Date: Tue, 18 Oct 88 14:59:20 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA23302; Tue, 18 Oct 88 14:59:20 EDT
Date: Tue, 18 Oct 88 14:59:20 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810181859.AA23302@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Wed, 12 Oct 88 13:10:08 PDT <8810122010.AA16313@fog.cs.uoregon.edu>
Subject: Peek-char for R4RS?
I forgot to propose the addition of peek-char for R4RS before
Snowbird. Is it possible to consider the proposal now?
John
∂24-Oct-88 1546 @ZERMATT.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU previously failed mail
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Oct 88 15:45:54 PDT
Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 204996; Mon 24-Oct-88 18:44:53 EDT
Date: Mon, 24 Oct 88 18:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: previously failed mail
To: "#COMSCH.MSG[SCH,LSP]"@SAIL.STANFORD.EDU
Message-ID: <19881024224502.1.JAR@MICKEY-MOUSE.LCS.MIT.EDU>
NET-MAIL-FROM-HOST:40700003131
RETURN-PATH:@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:Pavel.pa@Xerox.COM
TO:"#COMSCH.MSG[SCH,LSP]@SAIL.STANFORD.EDU
TO:"RPG@SAIL.STANFORD.EDU
TEXT;-1
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Oct 88 03:07:55 EDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Oct 88 02:57:07 EDT
Received: from Xerox.COM by XX.LCS.MIT.EDU with TCP/SMTP; Tue 18 Oct 88 01:04:04-EDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 OCT 88 18:51:01 PDT
Date: Mon, 17 Oct 88 18:50:54 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme
In-reply-to: <8810142157.AA06921@sesame.stanford.edu>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881017-185101-3852@Xerox>
Some notes and responses to Morry's proposal.
- APPEND! is not in R3RS; it was removed after R2RS.
- I'm not sure that I can imagine a reasonable use for STRING.
- Is there some reason why we are trying to keep strings and vectors
separate? I guess that it makes sense since "foo" would answer #t to
VECTOR? but VECTOR-SET! could not be used to stuff any old Scheme value
into it. Sigh. It just seems a bit of a pity. Perhaps we could make some
(most) of the string/vector operations polymorphic? That is, strings would
answer #f to VECTOR? but the same procedure could be used to reference
elements of both strings and vectors. Hmmm. Comments?
- I guess that I can see why an implementation could make a faster version
of SUBVECTOR that could be written in Scheme (by using a block-transfer
instruction), but I don't see that argument for SUBLIST. Can someone point
out to me the obviously-faster implementation I'm not seeing?
- The name ``=?'' in Morry's noncontroversial #6 should be ``equal?''.
- Controversial#1: Cedar Scheme has a predicate ``proper-list?'' that does
what Morry's ``list?'' would do. It's there because I've found it useful
at times, for example in the parsing of lambda-lists.
- Controversial #2: I don't see why the existence of the second form of
APPLY has any bearing on the question of whether or not vectors and strings
can be passed as the final argument.
- Controversial #3: For option (c), I think it's probably too expensive to
have to make a first pass down a list passed as an argument in order to
know how big a string/vector to allocate for the result. Maybe I'm just a
worry-wart, though. Option (c) is certainly more flexible. On the other
hand, these can be easily written in Scheme (I think as efficiently as in
some lower-level language), so I don't perceive a burning need for them.
- Controversials #4, 5, and 6: Since I don't think that EQUAL? is a
particularly natural predicate to have in the language (that is, it doesn't
seem as natural a predicate as EQ? and EQV?, it's just an arbitrary choice
out of the space of equivalence relations that happens to find some use),
I've never felt that MEMBER and ASSOC were particularly worthy of special
treatment. I would perhaps prefer that these names be used for more
general operations that took an equivalence predicate as an argument. This
aside, though, I agree with Morry that no extension is desirable here. As
for #6, I don't understand why Morry says that ``For match, this
polymorphism would extend to 2 levels into the data structure'' since MATCH
doesn't seem to care about a second level. More useful than MEMBER? and
MATCH might be the Common Lisp sequence functions POSITION and FIND which
take a value, a predicate, and a sequence and return, respectively, the
index and the value of the first element of the sequence on which (pred
value element) returns true. The function POSITION can be used as a
predicate, just like MEMBER?. Again, though, as in #3, I don't see why
these functions should be in the report at all, since they're so easy to
write. Put them in the yellow pages...
Pavel
∂25-Oct-88 0824 @MC.LCS.MIT.EDU:kranz@WHEATIES.AI.MIT.EDU Where/how to get Scheme for Suns?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:24:16 PDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 OCT 88 10:13:16 EDT
Received: from shredded-wheat.ai.mit.edu by XX.LCS.MIT.EDU with TCP/SMTP; Mon 24 Oct 88 10:12:47-EDT
Received: by shredded-wheat.ai.mit.edu; Mon, 24 Oct 88 10:13:10 EDT
Date: Mon, 24 Oct 88 10:13:10 EDT
From: kranz@wheaties.ai.mit.edu (David Kranz)
Message-Id: <8810241413.AA04159@shredded-wheat.ai.mit.edu>
To: uoregon!markv@beaver.cs.washington.edu
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: (Mark VandeWettering's message of 20 Oct 88 18:21:46 GMT <3007@uoregon.uoregon.edu>
Subject: Where/how to get Scheme for Suns?
Date: 20 Oct 88 18:21:46 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Organization: University of Oregon, Computer Science, Eugene OR
References: <483@ccncsu.ColoState.EDU>
Sender: scheme-request@mc.lcs.mit.edu
After being irritated by the slowness of C-Scheme, I decided to try
the T dialect of Scheme. It is available via anonymous from
prep.ai.mit.edu in the "t" subdirectory. Versions are available for the
Sun and the Vax. I have used the sun version extensively, and find it
very nice, and it compiles to very good native code.
There are some trivial differences between T and Scheme, but they
are both based on the R3RS, so problems should be minimal.
The latest version of T is on wheaties.ai.mit.edu in the pub/t3.1 directory
via anonymous FTP. Note that typing (scheme-reset) to the top level prompt
will put you in a R3RS environment. Versions are available for Sun, Vax, Hp,
Apollo, Mac II (Unix) and Encore Multimax.
∂25-Oct-88 0824 NET-ORIGIN@MC.LCS.MIT.EDU Re: Wanted: most recent xscheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:24:40 PDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 OCT 88 10:14:34 EDT
Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sun 23 Oct 88 07:34:02-EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA12546@BLOOM-BEACON.MIT.EDU>; Sun, 23 Oct 88 07:22:12 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Oct 88 08:36:55 GMT
From: helios.ee.lbl.gov!pasteur!agate!e260-2c.berkeley.edu!c60a-2ce@nosc.mil (Mikey)
Organization: University of California, Berkeley
Subject: Re: Wanted: most recent xscheme
Message-Id: <15901@agate.BERKELEY.EDU>
References: <30901@bbn.COM>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Is there xscheme for the Mac? I know there is Xlisp. If so, will someone
please email me a copy or post it to comp.binaries.mac? I would greatly
appreciate it!!!!!
---------------------------------------------------------------------
Please reply via e-mail; I just don't have enough time to go thru
the entire newsgroup. Thanks a lot!
c60a-2ce@web.berkeley.edu@ucbvax.berkeley.edu...................Mikey
*** Call Tanelorn III! (415) 540-1180. The Apple/Mac BBS of Berkeley.
∂25-Oct-88 0825 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu Regularization of Procedures in Scheme
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:25:01 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 24 Oct 88 11:40:39 EDT
Received: from sesame.stanford.edu by XX.LCS.MIT.EDU with TCP/SMTP; Mon 24 Oct 88 11:33:43-EDT
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
id AA14880; Mon, 24 Oct 88 08:32:33 PDT
Date: Mon, 24 Oct 88 08:32:33 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8810241532.AA14880@sesame.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 18 Oct 88 14:26:24 PDT <881018-145647-512@Xerox>
Subject: Regularization of Procedures in Scheme
Date: Tue, 18 Oct 88 14:26:24 PDT
From: Pavel.pa@Xerox.COM
Morry, you ask me to ``See earlier reply to same question'' in response to
my question about why the long form of APPLY has anything to do with making
it polymorphic on the final argument. I didn't see an earlier reply that
seemed applicable.
Suffice it to say that I misread the documentation on the second form of apply,
whic I never use and the problems are insignificant.
Concerning ``polymorphism at two levels'' for the MATCH procedure: Isn't
all of the polymorphism at the second level contained in the predicate and
not at all part of MATCH's contract?
I believe that match must step down the elements of its argument comparing the
given value to the first element of each element. Therefore match is
polymorphic both in the type of the backbone and in the types of the elements
of the backbone. This is because I was assuming that the predicate would
operate on the given value and the first element of each element of the
backbopne. I guess an alternative which would only require match to be
polymorphic in the type of the backbone would be for it to take the entire
elements of the backbone as the second argument. This could actually add an
additional form of flexibility in that match could be specified to return the
value returned by the predicate, when it wasn't #f. (I actually like this idea
quite a bit.)
Morry Katz
katz@polya.stanford.edu
∂25-Oct-88 0846 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu null begin forms
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 08:46:42 PDT
Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 25 Oct 88 11:44:27 EDT
Received: by iuvax.cs.indiana.edu (5.54/1.16)
Date: Tue, 25 Oct 88 10:44:18 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: null begin forms
From Will's minutes:
F. Nested begin expressions containing DEFINE forms will be flattened and
treated as consecutive DEFINE forms, both at top level and at the head of
lambda bodies. Macros will be permitted to expand into definitions and
BEGIN forms containing definitions.
Does this mean that `(begin)' must be, may be, or may not be, allowed?
It would be very nice, say for debugging statement macros that may not
want to generate anything. That is, I wish a null begin would compile
nothing if it appeared in any but the last place within another
(implicit or explicit) begin.
-- Chris Haynes
∂25-Oct-88 1541 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET Re: self-replicating-code, self-replicating-messages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Oct 88 15:41:11 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 24 Oct 88 14:56:59 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3598; Mon, 24 Oct 88 09:37:18 EDT
Received: from DB0TUI6.BITNET (ZTUBTFAL) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 3597; Mon, 24 Oct 88 09:22:50 EDT
Received: by tub.UUCP; Mon, 24 Oct 88 13:38:39 +0200; AA06867
Received: by tub-tfs.uucp (4.0/SMI-3.0DEV3)
id AA20497; Mon, 24 Oct 88 13:40:34 +0100
Date: Mon, 24 Oct 88 13:40:34 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8810241240.AA20497@tub-tfs.uucp>
To: scheme%mc.lcs.mit.edu@tub.uucp
Subject: Re: self-replicating-code, self-replicating-messages
I find it more interesting to discuss things like self replicating
code than technical details of SCHEME Implementations. Perhaps I am
on the wrong mailing list. Is there one about functional-programming,
lambda-calculus, theory and application ???
The most solutions to the problem were quite tricky. The reason is
that the problem was ill defined. The most interesting contributioon
came from
"G.OULSNAM" <uunet!MITVMA.MIT.EDU!STCS8004%IRUCCVAX.UCC.IE@tub.UUCP>
((lambda (x) (x x)) (lambda (x) (x x)))
The critic was that these expression has no normal form - even worse
it is an example for an so called non solvable term, which puts even
a lazy evaluator (which does only head reductions) into an infinite
loop.
But the point is, that every solution to the proble has no normal
form, because if :
x ---> x
(---> means reduces to), than you can go on reducing x...
More interesting is another question : Is there a function, which
returns itself for every argument ?
This problem can be solved more straightforward. You just need a
solution for the equation
f x = f , for every x.
This can be done with the fixed-point-combinator Y. The solution is
f = Y K
or in lambda notation :
f = lambda f . ( lambda x . f x x ) ( lambda x . f x x )
(lambda x y . x)
The Y - Kombinator is a relative of letrec in scheme, so in scheme you
would write :
(define y-k (letrec ((h (lambda (x) h))) h))
It is also possible to define Y in terms of simple scheme expressions
without refering to letrec at all :
(define (yy y f x) ((f ((y y) f)) x))
(define y (yy yy))
So now you can just write :
(define (k x) (lambda (y) x))
(define y-k (y k))
Thorsten
∂26-Oct-88 0440 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu -------------------------- call for votes -------------------
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 04:40:41 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Oct 88 06:10:32 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA06222@BLOOM-BEACON.MIT.EDU>; Wed, 26 Oct 88 04:04:06 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 05:54:40 GMT
From: chiba!khb@sun.com (Keith Bierman - Sun Tactical Engineering)
Subject: -------------------------- call for votes -------------------
Message-Id: <74720@sun.uucp>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
----------------------------------------------------------------------------
****************************************************************************
CALL FOR VOTES
----------------------------------------------------------------------------
****************************************************************************
Comp.lang.sigplan --- a moderated newsgroup sponsored by the ACM.
SIGPLAN is the ACM's special interest group on computer languages. The
forum will focus on issues which are of "general" interest.
This is merely a pointer. The "real" call for votes is located in News.groups.
Those who wish to vote yes can skip reading news.groups and simply
send mail to sigplan@iuvax.cs.indiana.edu. The SUBJECT should be YES.
Those not in favor should read the real call for votes before casting
a vote.
Thanks for your support.
Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus
∂26-Oct-88 1020 @MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET self-replicating-code, self-replicating-messages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 88 10:20:27 PDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Oct 88 13:16:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1800; Wed, 26 Oct 88 13:13:48 EDT
Received: from DB0TUI6.BITNET (ZTUBTFAL) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 1798; Wed, 26 Oct 88 13:13:04 EDT
Received: by tub.UUCP; Wed, 26 Oct 88 18:11:43 +0200; AA12857
Received: by tub-tfs.uucp (4.0/SMI-3.0DEV3)
id AA05234; Wed, 26 Oct 88 18:13:44 +0100
Date: Wed, 26 Oct 88 18:13:44 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8810261713.AA05234@tub-tfs.uucp>
To: uunet!rice.edu!dorai@tub.UUCP
Cc: scheme%mc.lcs.mit.edu@tub.uucp
In-Reply-To: Dorai Sitaram's message of Tue, 25 Oct 88 22:46:50 CDT
<8810260346.AA26475@titan.rice.edu>
Subject: self-replicating-code, self-replicating-messages
> I think you are confusing the phenomenon of reduction to normal form
> in the lambda calculus with the process of evaluation which takes
> place in the case of a Scheme program yielding a value.
Sorry, I haven't been clear here. There is a strong analogy between
reduction and evaluation, but it's not the same thing. For me the
lambda calculus serves as a principial model of functional languages,
which can be used to understand certain aspects of these languages
without the overload of accidential properties of implementations. So
evaluation relates to reduction and values to normal forms.
There are functional languages which use reduction as evaluation.
MIRANDA is such an example, it uses a reduction machine for lazy
evaluation. See the book of Simon L. Peyton Jones ("The implementation
of functional programming languages", Prentice/Hall, 1988) for how
lazy functional languages are implemented by reduction machines.
> E.g., the result of the program (list 'list 8) is (list 8), *not* (8),
> which would have been the case in the case of continual reduction.
I think the relation between normal forms and values is, that normal
forms somehow denotate values. The point that lisp values can be lisp
programs again is - as important it is for programming practice - only
confusing here.
> >(define (yy y f x) ((f ((y y) f)) x))
> >(define y (yy yy))
> You doubtless imply currying, viz.,
> (define yy (lambda (y) (lambda (f) (lambda (x) ((f ((y y) f)) x)))))
I am sorry, somehow I copied the old version of the function into my
buffer. I imply nothing it's just a mistake - your version is the
correct one.
Thank you for your comments . . .
Until now nobody has answered my other question (mailing list for
theoretical questions of functional programming).
Thorsten
∂27-Oct-88 1318 @MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 13:18:26 PDT
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 27 Oct 88 16:11:44 EDT
Full-Name:
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA21324; Thu, 27 Oct 88 14:37:42 EDT
Posted-Date: Thu, 27 Oct 88 14:41:25 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA01506; Thu, 27 Oct 88 14:41:25 EDT
Date: Thu, 27 Oct 88 14:41:25 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271841.AA01506@huxley.sun.uucp>
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John
PS. Sorry for the multiple messages last time. There seemed to be a
mailer problem at MIT. I think it has been fixed.
∂27-Oct-88 1333 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 13:33:23 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 16:12:31 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 16:11:28-EDT
Full-Name:
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John
PS. Sorry for the multiple messages last time. There seemed to be a
mailer problem at MIT. I think by routing to xx, I can get around it.
∂27-Oct-88 1344 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 13:44:37 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 16:13:32 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 16:12:26-EDT
Full-Name:
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John
PS. Sorry for the multiple messages last time. There seemed to be a
mailer problem at MIT. I think by routing to xx, I can get around it.
∂27-Oct-88 1415 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: self-replicating-code, self-replicating-messages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 14:15:21 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Oct 88 16:16:53 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA22826@BLOOM-BEACON.MIT.EDU>; Thu, 27 Oct 88 05:47:31 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 00:58:21 GMT
From: pasteur!agate!saturn!kjell@ames.arpa (Kjell Post)
Organization: University of California, Santa Cruz
Subject: Re: self-replicating-code, self-replicating-messages
Message-Id: <5259@saturn.ucsc.edu>
References: <8810241240.AA20497@tub-tfs.uucp>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8810241240.AA20497@tub-tfs.uucp> alti@tub-tfs.UUCP (Thorsten Altenkirch) writes:
>I find it more interesting to discuss things like self replicating
>code than technical details of SCHEME Implementations. Perhaps I am
>on the wrong mailing list. Is there one about functional-programming,
>lambda-calculus, theory and application ???
I haven't seen one but I certainly wouldn't mind.
By the way, why isn't there a comp.lang.ml?
fun Y f x = f (Y f) x;
fun fac x = Y (fn f => fn x => if x = 0 then 1 else x*f(x-1)) x;
∂27-Oct-88 1513 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu MacScheme Manual!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 15:13:21 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Oct 88 16:19:41 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA16857@BLOOM-BEACON.MIT.EDU>; Wed, 26 Oct 88 21:02:05 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Oct 88 06:40:00 GMT
From: uxg.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320@uxc.cso.uiuc.edu
Subject: MacScheme Manual!
Message-Id: <222600001@uxa.cso.uiuc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Does anybody have the address/phone for Semantic Microsystems, the makers
of the MacScheme system? I got the program thru the U of I licence for CS199, and now can't find anyone with the dox.
Help!
jb10320@uxa.cso.uiuc.edu
:
∂27-Oct-88 2059 @MC.LCS.MIT.EDU:jinx@altdorf.ai.mit.edu Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 20:59:06 PDT
Received: from altdorf.ai.mit.edu (TCP 2206400366) by MC.LCS.MIT.EDU 27 Oct 88 21:29:11 EDT
Received: by altdorf.ai.mit.edu (5.59/1.5)
id AA07418; Thu, 27 Oct 88 18:55:52 EDT
Date: Thu, 27 Oct 88 18:55:52 EDT
From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8810272255.AA07418@altdorf.ai.mit.edu>
To: ramsdell%linus@mitre-bedford.ARPA
Cc: mkatz@sesame.stanford.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: ramsdell%linus@mitre-bedford.ARPA's message of Thu, 27 Oct 88 14:41:25 EDT <8810271841.AA01506@huxley.sun.uucp>
Subject: Regularization of Procedures in Scheme (pair setters)
Reply-To: jinx@zurich.ai.mit.edu
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)
∂27-Oct-88 2244 @MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 22:44:40 PDT
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 27 Oct 88 23:33:56 EDT
Received: from mitre-bedford.ARPA by XX.LCS.MIT.EDU with TCP/SMTP; Thu 27 Oct 88 14:53:14-EDT
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA21692; Thu, 27 Oct 88 14:49:17 EDT
Posted-Date: Thu, 27 Oct 88 14:52:59 EDT
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA01520; Thu, 27 Oct 88 14:52:59 EDT
Date: Thu, 27 Oct 88 14:52:59 EDT
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8810271852.AA01520@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@xx.lcs.mit.edu
In-Reply-To: Morris Katz's message of Fri, 14 Oct 88 14:57:24 PDT <8810142157.AA06921@sesame.stanford.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John
PS. Sorry for the multiple messages last time. There seemed to be a
mailer problem at MIT. I think by routing to xx, I can get around it.
∂28-Oct-88 0455 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 04:55:42 PDT
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 28 Oct 88 07:02:31 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 27 OCT 88 14:36:39 PDT
Date: Thu, 27 Oct 88 14:36:38 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Regularization of Procedures in Scheme (pair setters)
In-reply-to: <8810271841.AA01506@huxley.sun.uucp>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <881027-143639-1192@Xerox>
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!?
Because CAR is not the name of a type. The correct name would be PAIR-SET!
and for consistency, it must take three arguments: a pair, a field
designator (in this case, perhaps one of the symbols CAR or CDR), and a new
value. Ecch.
Pavel
∂28-Oct-88 0526 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MacScheme Manual!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 05:25:58 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 28 Oct 88 08:11:17 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA09270@BLOOM-BEACON.MIT.EDU>; Fri, 28 Oct 88 07:55:39 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Oct 88 11:53:22 GMT
From: verber@ohio-state.arpa (Mark A. Verber)
Organization: Ohio State University, Computer Science Department
Subject: Re: MacScheme Manual!
Message-Id: <25950@tut.cis.ohio-state.edu>
References: <222600001@uxa.cso.uiuc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
The makers of MacScheme are:
Semantic Microsystems
4470 S.W. Hall
Suite 340
Beaverton, OR 97005
503-643-4539
Cheers,
Mark Verber
∂28-Oct-88 0915 @MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 09:14:58 PDT
Received: from dumbo (TCP 2212600251) by MC.LCS.MIT.EDU 28 Oct 88 12:12:23 EDT
Received: by DUMBO.AI.MIT.EDU; Fri, 28 Oct 88 12:12:57 edt
Date: Fri, 28 Oct 88 12:12:57 edt
From: arthur@DUMBO.AI.MIT.EDU (Arthur Gleckler)
Message-Id: <8810281612.AA07834@dumbo>
To: jinx@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 27 Oct 88 18:55:52 EDT <8810272255.AA07418@altdorf.ai.mit.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
Cc: mkatz@sesame.stanford.edu, rrrs-authors@mc.lcs.mit.edu
Reply-To: arthur@zurich.ai.mit.edu
Date: Thu, 27 Oct 88 18:55:52 EDT
From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
Reply-To: jinx@zurich.ai.mit.edu
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)
In a truly uniform Scheme, there would be no pairs, only vectors! :-))
∂28-Oct-88 1517 @MC.LCS.MIT.EDU:gls@Think.COM Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 15:17:40 PDT
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 28 Oct 88 18:00:04 EDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Oct 88 17:39:35 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Oct 88 17:57:45 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Oct 88 18:01:44 PDT
Received: by joplin.think.com; Fri, 28 Oct 88 17:57:41 EDT
Date: Fri, 28 Oct 88 17:57:41 EDT
From: gls@Think.COM
Message-Id: <8810282157.AA06470@joplin.think.com>
To: jinx@zurich.ai.mit.edu
Cc: ramsdell%linus@mitre-bedford.arpa, mkatz@sesame.stanford.edu,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 27 Oct 88 18:55:52 EDT <8810272255.AA07418@altdorf.ai.mit.edu>
Subject: Regularization of Procedures in Scheme (pair setters)
Date: Thu, 27 Oct 88 18:55:52 EDT
From: jinx@altdorf.ai.mit.edu (Guillermo J. Rozas)
Reply-To: jinx@zurich.ai.mit.edu
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
To be totally uniform it should be (PAIR-SET! <pair> <index> <value>) where
index is 0 or 1, one of them meaning CAR, and the other meaning CDR. :-)
Or perhaps the index should be 'CAR or 'CDR:
(PAIR-SET! foo 'CAR 43) ;RPLACA ;-]
--Guy
∂28-Oct-88 1716 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: MacScheme Manual!
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Oct 88 17:16:22 PDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 28 Oct 88 20:11:26 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA16794@BLOOM-BEACON.MIT.EDU>; Fri, 28 Oct 88 19:56:58 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 27 Oct 88 19:58:00 GMT
From: m.cs.uiuc.edu!carr@uxc.cso.uiuc.edu
Subject: Re: MacScheme Manual!
Message-Id: <38100001@m.cs.uiuc.edu>
References: <222600001@uxa.cso.uiuc.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Semantic Microsystems
4470 S.W. Hall St.
Suite 340
Beaverton, Oregon 97005
∂31-Oct-88 0946 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu debuggers for teaching
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 09:46:39 PST
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Oct 88 12:42:16 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA21555@BLOOM-BEACON.MIT.EDU>; Mon, 31 Oct 88 12:30:54 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Oct 88 16:28:42 GMT
From: ucdavis.ucdavis.edu!windley@ucdavis.ucdavis.edu (Phil Windley)
Organization: UCD Robotics Research Lab
Subject: debuggers for teaching
Message-Id: <WINDLEY.88Oct31082928@cheetah.ucdavis.edu.cheetah.ucdavis.edu>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Has anyone written a program that demonstrates scheme evaluation in both
the substitution and environment model of evaluation (Sussman and Abelson)?
I've been contemplating such a "debugging" environment for my class. The
substitution model could be text based, but I think that the environment
model would have to be based on X or some other windowing system. I think
a tool like this would be great for teaching students about program
evaluation.
--
Phil Windley | windley@iris.ucdavis.edu
Division of Computer Science | ucbvax!ucdavis!iris!windley
College of Engineering | (916) 752-7324 (or 3168)
University of California, Davis | Davis, CA 95616
∂31-Oct-88 1812 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Internal definitions as a combination of LETREC's and LET*'s.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 18:12:27 PST
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Oct 88 20:58:58 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA27377@BLOOM-BEACON.MIT.EDU>; Mon, 31 Oct 88 20:44:37 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Oct 88 13:55:21 GMT
From: linus!ramsdell@gatech.edu (John D. Ramsdell)
Organization: The MITRE Corp., Bedford, MA
Subject: Internal definitions as a combination of LETREC's and LET*'s.
Message-Id: <41415@linus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
I would like to shift the current topic of this news group to an issue
of Scheme language design: the meaning of internal definitions. I
contrast two interpretations of internal definitions:
[1] internal definitions as LETREC's, and
[2] internal definitions as a combination of LETREC's and LET*'s.
R3RS describes internal definitions in Section 5.2.2. Some Scheme
implementations permit definitions to occur at the beginning of the
syntactic entity <body>, and are simply a syntactic variation of
LETREC. In my opinion, they are an important variation as they reduce
the number of paratheses and make programs more readable.
Let me remind readers of the definition of LETREC of Section 7.3. It
is equivalent to the following combinations of LET's and SET!'s:
(LETREC ((<var-0> <init-0>)
...
(<var-n> <init-n>))
<body>)
==>
(LET ((<var-0> <undefined>)
...
(<var-n> <undefined>))
(LET ((<temp-0> <init-0>)
...
(<temp-n> <init-n>))
(SET! <var-0> <init-0>)
...
(SET! <var-n> <init-n>)
<body>))
The second LET is there to ensure the property that the init
expressions are evaluated in an arbitrary order. That is, no init
expression can depend of the value of any other one. Thus the
following is incorrect.
(LAMBDA (X)
(DEFINE A 4)
(DEFINE B (* A A))
(+ A (* X B)))
Yet at top level, it is okay to define values in terms of other
definitions. An obvious way of making internal definitions behave
more like top level definitions, is to specify the order in which the
init bodies are evaluated. I call this interpretation internal
definitions as a combination of LETREC's and LET*'s; a definition
becomes equivalent to the following combinations of LET's and SET!'s:
(LET ()
(DEFINE <var-0> <init-0>)
...
(DEFINE <var-n> <init-n>)
<body>)
==>
(LET ((<var-0> <undefined>)
...
(<var-n> <undefined>))
(SET! <var-0> <init-0>) ; init's must be evaluated
... ; in the order presented.
(SET! <var-n> <init-n>)
<body>)
Aside from making internal definition behave more like top level
definitions, I think this meaning of internal definitions reduces the
number of parentheses, and makes programs more readable. What's your
opinion?
John
∂31-Oct-88 1946 @MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu Re: Internal definitions as a combination of LETREC's and LET*'s.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Oct 88 19:46:47 PST
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Oct 88 22:42:27 EST
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA28580@BLOOM-BEACON.MIT.EDU>; Mon, 31 Oct 88 22:27:00 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Nov 88 02:14:24 GMT
From: pierce@locus.ucla.edu (Brad Pierce)
Organization: UCLA Computer Science Department
Subject: Re: Internal definitions as a combination of LETREC's and LET*'s.
Message-Id: <17416@shemp.CS.UCLA.EDU>
References: <41415@linus.UUCP>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <41415@linus.UUCP> ramsdell@linus.UUCP (John D. Ramsdell) writes:
>Yet at top level, it is okay to define values in terms of other
>definitions. An obvious way of making internal definitions behave
>more like top level definitions, is to specify the order in which the
>init bodies are evaluated. I call this interpretation internal
>definitions as a combination of LETREC's and LET*'s; a definition
>becomes equivalent to the following combinations of LET's and SET!'s:
>
>(LET ()
> (DEFINE <var-0> <init-0>)
> ...
> (DEFINE <var-n> <init-n>)
> <body>)
> ==>
>(LET ((<var-0> <undefined>)
> ...
> (<var-n> <undefined>))
> (SET! <var-0> <init-0>) ; init's must be evaluated
> ... ; in the order presented.
> (SET! <var-n> <init-n>)
> <body>)
>
Here's one possible problem, at least with the suggested expansion:
(define x 5)
(let ()
(define y x)
(define x 'any)
y)
Then wouldn't the result be unspecified, even though the intuitive
answer is 5?
-- Brad Pierce
P.S. Something else I'm curious about...
Also, is one allowed to declare the same identifier more than once in the same
lambda closure in official Scheme? The Scheme I am currently using doesn't give
an error message when I try to do this: ((lambda (x x) x) 1 2)
And is it officially legal to "define" something more than once at top level.
The reason that I ask is that the expansion looks a little shaky in the case
that one would re"define" an identifier in such a clause.
∂01-Nov-88 0550 @MC.LCS.MIT.EDU:ramsdell%linus@MITRE-BEDFORD.ARPA Regularization of Procedures in Scheme (pair setters)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 88 05:49:55 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 1 Nov 88 08:48:13 EST
Received: from mitre-bedford.arpa by RELAY.CS.NET id aa23897; 1 Nov 88 7:44 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: from huxley.sun.uucp by linus.MENET (3.2/4.7)
id AA15587; Tue, 1 Nov 88 07:34:29 EST
Posted-Date: Tue, 1 Nov 88 07:38:27 EST
Received: by huxley.sun.uucp (3.2/SMI-3.0DEV3)
id AA05549; Tue, 1 Nov 88 07:38:27 EST
Date: Tue, 1 Nov 88 07:38:27 EST
From: ramsdell%linus@MITRE-BEDFORD.ARPA
Message-Id: <8811011238.AA05549@huxley.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@RELAY.CS.NET
In-Reply-To: ramsdell@linus's message of Thu, 27 Oct 88 14:52:59 EDT <8810271852.AA01520@huxley.sun.uucp>
Subject: Regularization of Procedures in Scheme (pair setters)
If you set a vector with VECTOR-SET! and a string with STRING-SET!,
why do you set a pair with SET-CAR! and SET-CDR! instead of CAR-SET!
and CDR-SET!.
John
My point was that a true regularization of procedure names in Scheme
would require a large number of changes I suspect we are not willing
to make. I suggest we limit the scope of the regularization effort
and only focus on the non-controversial changes.
John
PS. The multiple messages problem seems to occur only when a MITRE
mailer tries to directly contact the PSN that is connected to MC, XX,
and Zurich. MITRE gurus now acknowledge that MITRE machines are
likely involved with the bug, but no one knows why it only occurs with
MIT's PSN. Thanks to Jonathan help, we are debugging the problem off
line, so this mailing list should see no further multiples messages
from MITRE.
∂02-Nov-88 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #1
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Nov 88 21:14:24 PST
Date: 3 NOV 88 00:05:59 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #1
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #1 3 NOV 88 00:05:59 EST
Today's Topics:
Digest test, ignore
Administrivia:
To ease the load on the MC mailer, the Internet Scheme mailing list is
now a digest. Please report any problems to
SCHEME-REQUEST@MC.LCS.MIT.EDU.
----------------------------------------------------------------------
Date: Wed, 2 Nov 88 15:47 EST
From: Scheme Requestee <SCHREQ@MC.LCS.MIT.EDU>
Subject: Digest test, ignore
Message-ID: <"19881102204700.6.schreq@MC"@NULLSTELLENSATZ.AI.MIT.EDU>
This is a test of the automatic digester. Please ignore it.
------------------------------
End of Scheme Digest
********************
∂03-Nov-88 2157 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #2
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Nov 88 21:57:10 PST
Date: 4 NOV 88 00:06:20 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #2
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #2 4 NOV 88 00:06:20 EST
Today's Topics:
TRAPPING ERRORS IN TI'S PC-SCHEME
Declaring variables more than once
----------------------------------------------------------------------
Date: 2 Nov 88 16:19:08 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: TRAPPING ERRORS IN TI'S PC-SCHEME
Message-Id: <1768@randvax.UUCP>
Deep in the bowels of a hunk of TI's PC-Scheme code, I'm running what
amounts to a read-eval-print loop of my own (where the user is using
the ROSS simulation language defined in Scheme, rather than Scheme itself).
What I'd like to do is trap all errors, _including errors that would
normally be trapped by Scheme_, and handle them in my own way. Problem
is that any time Scheme sees a glitch it dumps the user into the Scheme
break package, and the user has to manually extricate himself/herself.
In LISP implementations of ROSS we've done some magic with catches and
throws to shelter the user from the tender mercies of the break package.
Is there some TI PC-Scheme magic, using continuations or whatever, that
would allow ROSS to evaluate a user-input expression, return the value of
the expression if it evaluated successfully, or return a flag _without
invoking the break package_ if the expression causes a Scheme error?
Tnx for advice... -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Date: 3 Nov 88 19:28:34 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Subject: Declaring variables more than once
Message-Id: <3084@uoregon.uoregon.edu>
In article <17416@shemp.CS.UCLA.EDU> pierce@cs.ucla.edu (Brad Pierce) writes:
>Also, is one allowed to declare the same identifier more than once in the same
>lambda closure in official Scheme?...((lambda (x x) x) 1 2)
There's no prohibition in R3RS, but that's an oversight. R4RS will say that
(lambda (x x) ...) is an error. Implementations will still not be required
to detect the error.
>And is it officially legal to "define" something more than once at top level.
There is nothing that says you can't. Many people think that a <program>
should not contain multiple top level definitions for the same variable,
but that an interactive programming environment must allow re-definitions
as a debugging feature. This is my view.
Peace, William Clinger
------------------------------
End of Scheme Digest
********************
∂04-Nov-88 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #3
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Nov 88 21:15:06 PST
Date: 5 NOV 88 00:06:21 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #3
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #3 5 NOV 88 00:06:21 EST
Today's Topics:
T manual
----------------------------------------------------------------------
Date: 3 Nov 88 16:18:58 GMT
From: mcvax!hp4nl!botter!star.cs.vu.nl!roelw%cs.vu.nl@uunet.uu.net
Subject: T manual
Message-Id: <1617@star.cs.vu.nl>
Can anyone tell me how to obtain a copy of
J. Rees et al., "The T Manual"?
Thanx,
Roel Wieringa
Dept. of Math. and Comp. Science
Vrije Universiteit
De Boelelaan 1081
1081 HV Amsterdam
Holland
uucp: roelw@cs.vu.nl
------------------------------
End of Scheme Digest
********************
∂06-Nov-88 1500 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu R4RS number syntax
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Nov 88 15:00:06 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 6 Nov 88 17:56:59 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Sun, 6 Nov 88 14:56:31 PDT
Received: by fog.cs.uoregon.edu; Sun, 6 Nov 88 14:56:24 PDT
Date: Sun, 6 Nov 88 14:56:24 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8811062256.AA00951@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: R4RS number syntax
Here is the new number syntax for R4RS. I wrote a reference
parser for it and found one minor glitch, which I don't want
to try to fix. It seems to take about three hundred lines
of commented Scheme code to parse numbers while building the
correct value and exactness.
Some examples of numbers:
#E#o-1234
#X#I-50
#e#x-00abc/34
#e#d-1###.###L-06@-.4##f+0000003
4+5i
+45i
+i
-i
00## (this is the glitch I found; see below)
Some examples of non-numbers:
-#x1 (sign must follow radix and exactness prefixes)
1/2e4 (exponents not allowed with ratio syntax)
#b101e3 (exponents illegal if radix is not decimal)
#x3.4 (decimal point illegal if radix is not decimal)
45i (sign required in front of imaginary part)
i (sign required)
3#.4 (insouciant digits can't be followed by souciant)
## (an insouciant digit can't be the first)
Some examples of semantics:
1e6 is equivalent to 1000000.0 and should be inexact
#e1e6 is equivalent to 1000000
#i3/4 is equivalent to .75
3/4 is equivalent to (/ 3 4)
4+0i is equivalent to 4
4-6.3i is equivalent to (make-rectangular 4 -6.3)
123@.41 is equivalent to (make-polar 123 .41)
1### is equivalent to 1000.0
00## is equivalent to 0.0
5. is equivalent to 5.0
Peace, Will
Number syntax for R4RS
<number> --> <num 2> | <num 8> | <num 10> | <num 16>
The following rules for <num R>, <complex R>, <real R>, <ureal R>,
<uinteger R>, and <prefix R> should be replicated for R = 2, 8, 10,
and 16. There are no rules for <decimal 2>, <decimal 8>, and
<decimal 16>, which means that numbers containing decimal points
or exponents must be in decimal radix.
<num R> --> <prefix R> <complex R>
<complex R> --> <real R>
| <real R> @ <real R>
| <real R> + <ureal R> i
| <real R> - <ureal R> i
| <real R> + i
| <real R> - i
| + <ureal R> i
| - <ureal R> i
| + i
| - i
<real R> --> <sign> <ureal R>
<ureal R> --> <uinteger R>
| <uinteger R> / <uinteger R>
| <decimal R>
<decimal 10> --> <uinteger 10> <suffix>
| . <digit 10>+ #* <suffix>
| <digit 10>+ . <digit 10>* #* <suffix>
| <digit 10>+ #* . #* <suffix>
<uinteger R> --> <digit R>+ #*
<prefix R> --> <radix R> <exactness>
| <exactness> <radix R>
<suffix> --> <empty>
| <exponent marker> <sign> <digit>+
<exponent marker> --> e | s | f | d | l
<sign> --> <empty> | + | -
<exactness> --> <empty> | #i | #e
<radix 2> --> #b
<radix 8> --> #o
<radix 10> --> <empty> | #d
<radix 16> --> #x
<digit 2> --> 0 | 1
<digit 8> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
<digit 10> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<digit 16> --> <digit 10> | a | b | c | d | e | f
∂08-Nov-88 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #4
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Nov 88 21:30:50 PST
Date: 9 NOV 88 00:09:13 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #4
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #4 9 NOV 88 00:09:13 EST
Today's Topics:
(Still) searching for latest XScheme
Wanted: extend-syntax for T
----------------------------------------------------------------------
Date: 8 Nov 88 18:17:24 GMT
From: bbn.com!jgrace@bbn.com (Joe Grace)
Subject: (Still) searching for latest XScheme
Message-Id: <32005@bbn.COM>
A few weeks ago, I posted a request for XScheme. Many others
requested copies from me via e-mail --- but the only tip I received
involved getting it from a bboard in Colorado (long distance calls to
a bboard. I would prefer someone send me sources via e-mail.
So, could someone who has sources (preferably, for both PC
and Mac) for XScheme, contact me?
I will then forward the sources to the others who are interested.
Thanks,
= Joe =
Joe Grace
ARPA: jgrace@bbn.com
UUCP: {harvard,husc6,decvax,etc.}!bbn!jgrace
------------------------------
Date: 8 Nov 88 20:30:45 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Subject: Wanted: extend-syntax for T
Message-Id: <3111@uoregon.uoregon.edu>
I am currently involved in hacking some T code as part of my thesis
work. It dawns on me that Kohlbecker's "extend-syntax" macros would
simplify both the look and the coding of elements of this.
Problem: I only have "extend-syntax" for MacScheme, and my brain
isn't working very well right now. If anyone has done the
probably trivial modifications to make these work under
T, can you please send them to me?
Alternatively, you could give me a T macro which converts MacScheme
(macro ...) calls into T's (define-syntax ...) form.
Thanks once again..
Mark VandeWettering
---
markv@cs.uoregon.edu \ Mark Terrence VandeWettering
University of Oregon \ ..!tektronix!uoregon!markv
Computer Science Dept. \
------------------------------
End of Scheme Digest
********************
∂09-Nov-88 2158 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #5
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Nov 88 21:58:13 PST
Date: 10 NOV 88 00:09:38 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #5
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #5 10 NOV 88 00:09:38 EST
Today's Topics:
PC Scheme Error Handlers
----------------------------------------------------------------------
Date: Wed, 9 Nov 88 16:24:27 CST
From: Clyde Camp <camp@mips.csc.ti.com>
Message-Id: <8811092224.AA03675@mips>
Subject: PC Scheme Error Handlers
Reply-To: camp@ti-csl.csc.ti.com
With respect to the PC Scheme error handlers, send me a pair of
initialized DOS disks and a self-addressed STAMPED return mailer and
I'll send you a set of utilities which do what you want. There is no
charge for this. Also included are several menu shells,
window-handlers, on-line help utilities, keyboard utilities and
mechanisms for "pushing" new top-level loops as well as a new
top-level command-line editor with EMACS-like editing and UNIX-like
history (e.g. scroll through previous entries, edit the one you like
and submit it).
In the meantime, a very crude version of a user error handler can be
implemented as follows:
(define foo (lambda (error-number irritant error-msg sys-error-handler)
(... do your own thing ...)
))
(set! *user-error-handler* foo)
This is covered (albeit briefly) in the section on breakpoints (pp3-6
thru 3-8) in the PC Scheme user's guide. Make SURE your error handler
is bug free or you're in real trouble.
Clyde R. Camp
Texas Instruments, Incorporated
P.O. Box 655474 M/S 238
Dallas, TX 75266
(214)995-0407
------------------------------
End of Scheme Digest
********************
∂10-Nov-88 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #6
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Nov 88 21:52:16 PST
Date: 11 NOV 88 00:10:22 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #6
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #6 11 NOV 88 00:10:22 EST
Today's Topics:
PC Scheme Error Handlers Address Correction
----------------------------------------------------------------------
Date: Thu, 10 Nov 88 11:01:41 CST
From: Clyde Camp <camp@mips.csc.ti.com>
Message-Id: <8811101701.AA13609@mips>
Subject: PC Scheme Error Handlers Address Correction
Reply-To: camp@ti-csl.csc.ti.com
Oops!! The correct Zipcode is 75265. The other one will get to me as
well, but may take a little longer.
- Clyde
------------------------------
End of Scheme Digest
********************
∂12-Nov-88 0008 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #7
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Nov 88 00:08:04 PST
Date: 12 NOV 88 00:10:24 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #7
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #7 12 NOV 88 00:10:24 EST
Today's Topics:
self duplicating code summary
----------------------------------------------------------------------
Date: Fri, 11 Nov 88 16:58:19 MST
From: carr%car@cs.utah.edu (Harold Carr)
Message-Id: <8811112358.AA00568@car.utah.edu>
Subject: self duplicating code summary
Quite a number a people asked for copies of the self duplicating code
I requested. Here it is in one swell foop. If you have any self
duplicating code that is duplicated ( ;-) ) here I would like to see it.
Thanks for all the replies,
Harold
--------------
Summary-line: 7-Oct stoller@morgan #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25166; Fri, 7 Oct 88 13:56:07 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA06715; Fri, 7 Oct 88 13:56:00 MDT
Received: by morgan.utah.edu (5.54/utah-2.0-leaf)
id AA04067; Fri, 7 Oct 88 13:55:56 MDT
Date: Fri, 7 Oct 88 13:55:56 MDT
From: stoller@morgan (Leigh B. Stoller)
Message-Id: <8810071955.AA04067@morgan.utah.edu>
To: carr@car
Cc: pass@cs, scheme@mc.lcs.mit.edu, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 13:30:30 MDT <8810071930.AA25143@car.utah.edu>
Subject: Re: self reproducing code
*** EOOH ***
Date: Fri, 7 Oct 88 13:55:56 MDT
From: stoller@morgan (Leigh B. Stoller)
To: carr@car
Cc: pass@cs, scheme@mc.lcs.mit.edu, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 13:30:30 MDT <8810071930.AA25143@car.utah.edu>
Subject: Re: self reproducing code
Date: Tue, 19 May 87 15:39:42 MDT
From: carr@orion.utah.edu (Harold Carr)
To: kessler@orion.utah.edu
Subject: Fun stuff
Cc: pass@orion.utah.edu
Here's one everyone has already probably seen, but I forgot about it.
What does the following evaluate to?
((lambda (x) (list x (list (quote quote) x)))
(quote (lambda (x) (list x (list (quote quote) x)))))
Great problem for Bob's Lisp class.
Harold
Summary-line: 7-Oct Alan@AI.AI.MIT.EDU #self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25184; Fri, 7 Oct 88 14:11:43 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA07523; Fri, 7 Oct 88 14:10:26 MDT
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141482; Fri 7-Oct-88 16:00:51 EDT
Date: Fri, 7 Oct 88 16:00 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: self reproducing code
To: carr%car@cs
Cc: pass@cs, scheme@MC.LCS.MIT.EDU, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Message-Id: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
*** EOOH ***
Date: Fri, 7 Oct 88 16:00 EDT
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: self reproducing code
To: carr%car@cs
Cc: pass@cs, scheme@MC.LCS.MIT.EDU, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Date: Fri, 7 Oct 88 13:30:30 MDT
From: carr%car@cs.utah.edu (Harold Carr)
A couple of years ago I found an example of self reproducing code....
in Common Lisp, ...
My favorite example:
(let ((let '`(let ((let ',let))
,let)))
`(let ((let ',let))
,let))
I believe that Mike McMahon is the author of this variant. It is
unfortunate that this isn't standard Scheme because of the use of
LET as an identifier...
Summary-line: 7-Oct sandra@defun #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25206; Fri, 7 Oct 88 14:24:23 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA16358; Fri, 7 Oct 88 14:24:21 MDT
From: sandra@defun (Sandra J Loosemore)
Message-Id: <8810072024.AA16358@defun.utah.edu>
Date: Fri, 7 Oct 88 14:24:20 MDT
Subject: Re: self reproducing code
To: carr@car (Harold Carr)
In-Reply-To: carr@car (Harold Carr), Fri, 7 Oct 88 14:19:26 MDT
*** EOOH ***
From: sandra@defun (Sandra J Loosemore)
Date: Fri, 7 Oct 88 14:24:20 MDT
Subject: Re: self reproducing code
To: carr@car (Harold Carr)
In-Reply-To: carr@car (Harold Carr), Fri, 7 Oct 88 14:19:26 MDT
Here's my contribution for the simplest piece of self-reproducing code:
T
-Sandra :-)
-------
Summary-line: 7-Oct jar@void.ai.mit.edu #self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25234; Fri, 7 Oct 88 14:40:52 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08444; Fri, 7 Oct 88 14:40:40 MDT
Received: by void.ai.mit.edu (5.59/1.5)
id AA03464; Fri, 7 Oct 88 16:43:05 EDT
Date: Fri, 7 Oct 88 16:43:05 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8810072043.AA03464@void.ai.mit.edu>
To: carr%car@cs
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 13:30:30 MDT <8810071930.AA25143@car.utah.edu>
Subject: self reproducing code
Reply-To: jar@zurich.ai.mit.edu
*** EOOH ***
Date: Fri, 7 Oct 88 16:43:05 EDT
From: jar@void.ai.mit.edu (Jonathan Rees)
To: carr%car@cs
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 13:30:30 MDT <8810071930.AA25143@car.utah.edu>
Subject: self reproducing code
Reply-To: jar@zurich.ai.mit.edu
This works in both common lisp and scheme. You can expand the
backquotes into calls to list etc. if you like but I think this is
easier to understand. (As evidenced by the fact that I could generate
it from memory.)
(let ((x '`(let ((x ',x)) ,x)))
`(let ((x ',x)) ,x))
Summary-line: 7-Oct michaelf@decwrl.dec.com #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25246; Fri, 7 Oct 88 14:45:29 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08608; Fri, 7 Oct 88 14:45:19 MDT
Received: from saturn.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
id AA08422; Fri, 7 Oct 88 13:44:06 PDT
Received: from localhost by saturn.pa.dec.com (5.54.5/4.7.34)
id AA09432; Fri, 7 Oct 88 13:44:16 PDT
Message-Id: <8810072044.AA09432@saturn.pa.dec.com>
To: carr%car@cs (Harold Carr)
Subject: Re: self reproducing code
In-Reply-To: Your message of Fri, 07 Oct 88 13:30:30 -0600.
<8810071930.AA25143@car.utah.edu>
Date: Fri, 07 Oct 88 13:44:14 -0700
From: Michael A. Fetterman <michaelf@decwrl.dec.com>
*** EOOH ***
To: carr%car@cs (Harold Carr)
Subject: Re: self reproducing code
In-Reply-To: Your message of Fri, 07 Oct 88 13:30:30 -0600.
<8810071930.AA25143@car.utah.edu>
Date: Fri, 07 Oct 88 13:44:14 -0700
From: Michael A. Fetterman <michaelf@decwrl.dec.com>
The traditional piece of code to do this is a very famous piece of lambda
calculus:
((lambda (x) (x x)) (lambda (x) (x x)))
[Where the above is written in tradition lisp notation rather than in
lambda calculus notation].
The lambda calculus is very much like lisp or scheme, as you can tell. To
translate this to scheme, you get:
((lambda (x) (list x `',x)) '(lambda (x) (list x `',x)))
where I'm using quasi-quote from scheme r3rs.
If you don't have quasi-quote in your scheme, try:
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
This same code should work fine in common lisp.
Summary-line: 7-Oct stever@Riverside.SCRC.Sym #self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25276; Fri, 7 Oct 88 15:39:05 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA10784; Fri, 7 Oct 88 15:38:51 MDT
Received: from HALEAKALA.S4CC.Symbolics.COM by IVORY.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194006; Fri 7-Oct-88 17:04:11 EDT
Date: Fri, 7 Oct 88 17:04 EDT
From: stever@Riverside.SCRC.Symbolics.COM
Sender: Zippy@QUABBIN.SCRC.Symbolics.COM
Subject: self reproducing code
To: Harold Carr <carr%car@cs>
Cc: pass@cs, scheme@mc.lcs.mit.edu, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Message-Id: <19881007210401.2.LISP-MACHINE@HALEAKALA.S4CC.Symbolics.COM>
*** EOOH ***
Date: Fri, 7 Oct 88 17:04 EDT
From: stever@Riverside.SCRC.Symbolics.COM
Sender: Zippy@QUABBIN.SCRC.Symbolics.COM
Subject: self reproducing code
To: Harold Carr <carr%car@cs>
Cc: pass@cs, scheme@mc.lcs.mit.edu, shebs@apple.apple.com,
mohammad%hpcllz2@sde.hp.com
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Date: Fri, 7 Oct 88 13:30:30 MDT
From: carr%car@cs.utah.edu (Harold Carr)
It was an anonymous lambda application which, when evaluated in Common
Lisp, would return the exact same for, which could then be evaluated
again, always returning the same anonymous application.
((LAMBDA (TEMPLATE)
(SETF (SECOND (SECOND TEMPLATE)) (COPY-TREE TEMPLATE))
TEMPLATE)
'((LAMBDA (TEMPLATE)
(SETF (SECOND (SECOND TEMPLATE)) (COPY-TREE TEMPLATE))
TEMPLATE)
(QUOTE *PLACEHOLDER*)))
This will work. I'm pretty sure there's a more elegant way to do it.
If anyone send you one, I'd appreciate a copy.
Thanks,
Stephen
Summary-line: 7-Oct U09052@UICVM.BITNET #
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25286; Fri, 7 Oct 88 15:55:29 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA11334; Fri, 7 Oct 88 15:54:39 MDT
Message-Id: <8810072154.AA11334@cs.utah.edu>
Received: from UICVM.BITNET by CC.UTAH.EDU; Fri, 7 Oct 88 15:55 MDT
Received: by UICVM (Mailer X1.25) id 3599; Fri, 07 Oct 88 16:51:39 CDT
Date: 7 October 1988 16:50:27 CDT
From: U09052@UICVM.BITNET
To: CARR%CAR@cs
*** EOOH ***
Date: 7 October 1988 16:50:27 CDT
From: U09052@UICVM.BITNET
To: CARR%CAR@cs
I am sending you by "snail-mail" an article I published in Creative
Computing in 1980 on "Self-reproducing programs". It contains (at the end)
the Lisp code you are interested in.
Summary-line: 7-Oct bard@theory.lcs.mit.edu #self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25345; Fri, 7 Oct 88 17:05:33 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA13458; Fri, 7 Oct 88 17:05:18 MDT
Received: by toucan.LCS.MIT.EDU
id AA01684; Fri, 7 Oct 88 19:04:46 EDT
Date: Fri, 7 Oct 88 19:04:46 EDT
From: bard@theory.lcs.mit.edu
Message-Id: <8810072304.AA01684@toucan.LCS.MIT.EDU>
To: carr%car@cs
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
*** EOOH ***
Date: Fri, 7 Oct 88 19:04:46 EDT
From: bard@theory.lcs.mit.edu
To: carr%car@cs
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
My favorite is the PDP-11 machine code:
MOV --(PC), (R0)++
which copies itself throughout the machine's memory.
But it ain't lisp.
Summary-line: 7-Oct will@fog.cs.uoregon.edu #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25363; Fri, 7 Oct 88 17:22:58 MDT
Received: from mist.math.uoregon.edu by cs.utah.edu (5.54/utah-2.0-cs)
id AA14301; Fri, 7 Oct 88 17:22:51 MDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Fri, 7 Oct 88 16:18:46 PDT
Received: by fog.cs.uoregon.edu; Fri, 7 Oct 88 16:18:41 PDT
Date: Fri, 7 Oct 88 16:18:41 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8810072318.AA25772@fog.cs.uoregon.edu>
To: carr%car@CS
Subject: Re: self reproducing code
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Organization: University of Oregon, Computer Science, Eugene OR
Cc:
*** EOOH ***
Date: Fri, 7 Oct 88 16:18:41 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
To: carr%car@CS
Subject: Re: self reproducing code
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Organization: University of Oregon, Computer Science, Eugene OR
Cc:
In Scheme the code you are looking for might be something like
((lambda (x)
(list x (list 'quote x)))
'(lambda (x)
(list x (list 'quote x))))
You can't write something like ((lambda (lambda) ... because
lambda is a reserved word in Scheme (although some implementations
remove this restriction). On the other hand, I don't know why you'd
want to write it that way; "x" is shorter than "lambda".
A shorter self-reproducing expression is:
0
Peace, Will
Summary-line: 8-Oct FWHITE@G.BBN.COM #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25791; Sat, 8 Oct 88 11:58:01 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28938; Sat, 8 Oct 88 11:57:47 MDT
Date: 8 Oct 1988 13:56-EDT
Sender: FWHITE@G.BBN.COM
Subject: Re: self reproducing code
From: FWHITE@G.BBN.COM
To: carr%car@CS
Cc: fwhite@BBN.COM
Message-Id: <[G.BBN.COM] 8-Oct-88 13:56:28.FWHITE>
In-Reply-To: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
*** EOOH ***
Date: 8 Oct 1988 13:56-EDT
Sender: FWHITE@G.BBN.COM
Subject: Re: self reproducing code
From: FWHITE@G.BBN.COM
To: carr%car@CS
Cc: fwhite@BBN.COM
In-Reply-To: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Or if cheating is allowed, how about (in Common Lisp):
#1='#1#
Summary-line: 8-Oct iku.dk!danvy@uunet.UU.NET #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25849; Sat, 8 Oct 88 16:15:13 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA02854; Sat, 8 Oct 88 16:15:05 MDT
Received: from uunet.UU.NET (TCP 30003106601) by MC.LCS.MIT.EDU 8 Oct 88 17:54:32 EDT
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA22266; Sat, 8 Oct 88 17:53:02 EDT
Received: by mcvax.cwi.nl; Sat, 8 Oct 88 22:23:48 +0100 (MET)
Received: from diku.dk
by dkuug.dk (3.2/smail2.5/ease)
id AA07492; Sat, 8 Oct 88 17:15:36 +0100
Received: by diku.dk (5.51/smail2.5/ease)
id AA14951; Sat, 8 Oct 88 17:15:22 +0100
Date: Sat, 8 Oct 88 17:15:22 +0100
From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy)
Message-Id: <8810081615.AA14951@diku.dk>
To: Alan@ai.ai.mit.edu, carr%car@cs
Subject: Re: self reproducing code
Cc: carr%car@cs, mohammad%hpcllz2@sde.hp.com, pass@cs, scheme@mc.lcs.mit.edu,
shebs@apple.apple.com
*** EOOH ***
Date: Sat, 8 Oct 88 17:15:22 +0100
From: mcvax!diku.dk!danvy@uunet.UU.NET (Olivier Danvy)
To: Alan@ai.ai.mit.edu, carr%car@cs
Subject: Re: self reproducing code
Cc: carr%car@cs, mohammad%hpcllz2@sde.hp.com, pass@cs, scheme@mc.lcs.mit.edu,
shebs@apple.apple.com
Chez Scheme Version 2.0.3 Copyright (c) 1987 R. Kent Dybvig
> ()
()
>
This one is pretty small :-)
It is illegal according to the r3rs's BNF for Scheme, though.
Olivier
Summary-line: 8-Oct KMP@STONY-BROOK.SCRC.Symb #Re: self reproducing code
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA25910; Sat, 8 Oct 88 20:53:40 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA10632; Sat, 8 Oct 88 20:53:18 MDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 473424; Sat 8-Oct-88 22:51:52 EDT
Date: Sat, 8 Oct 88 22:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: self reproducing code
To: mcvax!diku.dk!danvy@uunet.UU.NET
Cc: Alan@ai.ai.mit.edu, carr%car@cs, mohammad%hpcllz2@sde.hp.com, pass@cs,
scheme@mc.lcs.mit.edu, shebs@apple.apple.com
In-Reply-To: <8810081615.AA14951@diku.dk>
Message-Id: <881008225128.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
*** EOOH ***
Date: Sat, 8 Oct 88 22:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: self reproducing code
To: mcvax!diku.dk!danvy@uunet.UU.NET
Cc: Alan@ai.ai.mit.edu, carr%car@cs, mohammad%hpcllz2@sde.hp.com, pass@cs,
scheme@mc.lcs.mit.edu, shebs@apple.apple.com
In-Reply-To: <8810081615.AA14951@diku.dk>
() by itself is certainly cute, but I don't think it counts.
It's not -constructing- a program, it's just -returning- one.
All self-evaluating forms have the same property, after all.
{{1, 2, 3, ...}, {#t, #f}, ...}
Another borderline case, that comes up in Common Lisp, is:
#1='#1#
But depending on your model of what QUOTE does, that's just
self-evaluating, too, and doesn't count either. Btw, don't
try to look at the result without setting *print-circle* or
*print-level* appropriately.
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA26669; Mon, 10 Oct 88 07:38:31 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA19565; Mon, 10 Oct 88 07:37:56 MDT
Received: by ATHENA.CS.YALE.EDU; Mon, 10 Oct 88 09:33:38 EDT
Date: Mon, 10 Oct 88 09:33:38 EDT
From: Ashwin Ram <ram-ashwin@YALE.ARPA>
Message-Id: <8810101333.AA05276@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-abc3/ABC3)
via WIMP-MAIL (Version 1.3/1.5) ; Mon Oct 10 09:24:25
To: carr%car@CS (Harold Carr)
Subject: Re: self reproducing code
Newsgroups: comp.lang.scheme
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Reply-To: Ram-Ashwin@YALE.ARPA (Ashwin Ram)
*** EOOH ***
Date: Mon, 10 Oct 88 09:33:38 EDT
From: Ashwin Ram <ram-ashwin@YALE.ARPA>
To: carr%car@CS (Harold Carr)
Subject: Re: self reproducing code
Newsgroups: comp.lang.scheme
In-Reply-To: <8810071930.AA25143@car.utah.edu>
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Reply-To: Ram-Ashwin@YALE.ARPA (Ashwin Ram)
If you get any responses, could you please forward them to me?
Thanks.
-- Ashwin.
ARPA: Ram-Ashwin@cs.yale.edu
UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin
BITNET: Ram@yalecs
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA26949; Mon, 10 Oct 88 13:22:34 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA05433; Mon, 10 Oct 88 13:22:17 MDT
Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 10 Oct 88 09:24:42 EDT
Date: 10 Oct 88 09:06:52 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: scheme@mc.lcs.mit.edu
Message-Id: <101088.090653.alberga@ibm.com>
Subject: Self replicating code
*** EOOH ***
Date: 10 Oct 88 09:06:52 EDT
From: Cyril Alberga <ALBERGA@ibm.com>
To: scheme@mc.lcs.mit.edu
Subject: Self replicating code
Here is a brute-force expression which prints itself. This was in LISP370,
circa 1978.
(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) )
(COPY
"(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) ) (COPY "NIL) "NIL ) ) )
"(PRINT
( (LAMBDA (X Y)
(SEQ
(RPLACA (CDAR (CDDADR X)) (COPY Y))
(RPLACA (CDADR (CADADR X)) (COPY Y))
(EXIT X) ) ) (COPY "NIL) "NIL ) ) ) )
The uses of copy were to keep it from modifying itself.
Obviously, shared sub-structure could be used to shorten the
representation.
Cyril N. Alberga
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA28201; Tue, 11 Oct 88 05:50:17 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA27168; Tue, 11 Oct 88 05:50:11 MDT
Message-Id: <8810111150.AA27168@cs.utah.edu>
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 Oct 88 07:15:39 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1995; Tue, 11 Oct 88 07:13:31 EDT
Received: from IRUCCIBM by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1994;
Tue, 11 Oct 88 07:13:29 EDT
Received: from IRUCCVAX.UCC.IE by IRUCCIBM (Mailer X1.25) with BSMTP id 0193;
Mon, 10 Oct 88 15:45:35 IST
Date: Mon, 10 Oct 88 15:48 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: self-replicating code
To: SCHEME@MC.LCS.MIT.EDU
X-Vms-To: SCHEME
*** EOOH ***
Date: Mon, 10 Oct 88 15:48 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: self-replicating code
To: SCHEME@MC.LCS.MIT.EDU
X-Vms-To: SCHEME
Various respondents to the question of self-replicating anonymous lambda
expressions have given us solutions, but no derivations. I hope therefore
that the following contribution might be of interest.
If one has a normal-order evaluator in Scheme rather than an applicative
order one then the simplest self-replicating lambda expression is
((lambda (x) (x x)) (lambda (x) (x x)))
since the argument expression is substituted without being evaluated, but
loops forever with applicative order.
Any approach to generating self-replication in applicative order evaluators
must therefore include emulation of normal-order evaluation. Consider as a
first attempt:
(define f (lambda (x) (list 'f x)))
This doesn't quite work because the x in the list will be replaced by its
value. So a better attempt is:
(define f (lambda (x) (list 'f <reconstruction-of-x>)))
As a first step towards eliminating the recursive use of f, it makes sense
to pass f an argument that will evaluate to the lambda expression for f at
the 'f position, but will not itself (the argument that is) be evaluated to
f. The insight for this comes by recognizing that ((lambda () <body>))
evaluates to <body>. This suggests that f be recast to the form:
(define f (lambda (x) (list (x) <reconstruction-of-x>)))
and that it be passed the argument: (lambda () 'f). (This is where the
normal-order evaluation is emulated.)
The reconstruction of x can now be accomplished to give for f:
(define f (lambda (x) (list (x) (list 'lambda '() 'f))))
followed again by the elimination of 'f to yield:
(define f
(lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x))))))
It can be verified that:
> (f (lambda () 'f)
(f (lambda () 'f)
>
Elimination of the define statement is now straightforward, to yield the
required anonymous self-replicating expression:
((lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x)))))
(lambda ()
'(lambda (x)
(list (x)
(list 'lambda '() (list 'quote (x)))))))
Any comments?
Gordon Oulsnam
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA28267; Tue, 11 Oct 88 09:23:02 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA02848; Tue, 11 Oct 88 09:22:53 MDT
Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 11 Oct 88 10:53:58 EDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03181; 10 Oct 88 15:39 BST
Date: Mon, 10 Oct 88 15:39:36 BST
Message-Id: <10500.8810101439@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: self reproducing code
To: scheme@mc.lcs.mit.edu
*** EOOH ***
Date: Mon, 10 Oct 88 15:39:36 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: self reproducing code
To: scheme@mc.lcs.mit.edu
Here's one I wrote a while ago using the fairly standard technique
of having some data that looks pretty much like the code that uses
the data to reconstruct the data and the code.
;;; Self-reproducing function
(defun v ()
(let ((m '(subst m
'**
'(defun v () (let ((m '**)) **)))))
(subst m
'**
'(defun v () (let ((m '**)) **)))))
-- Jeff
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29177; Tue, 11 Oct 88 17:51:07 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA21848; Tue, 11 Oct 88 17:50:54 MDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 OCT 88 19:19:13 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA20412@EDDIE.MIT.EDU>; Tue, 11 Oct 88 19:18:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA29975@BLOOM-BEACON.MIT.EDU>; Tue, 11 Oct 88 18:55:18 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Oct 88 22:24:52 GMT
From: sun.soe!sun.soe.clarkson.edu!gary@tcgould.tn.cornell.edu (Gary Levin)
Organization: Clarkson University
Subject: Re: self reproducing code
Message-Id: <GARY.88Oct11182452@milo.mcs.clarkson.edu>
References: <10500.8810101439@subnode.aiai.ed.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
*** EOOH ***
Date: 11 Oct 88 22:24:52 GMT
From: sun.soe!sun.soe.clarkson.edu!gary@tcgould.tn.cornell.edu (Gary Levin)
Organization: Clarkson University
Subject: Re: self reproducing code
References: <10500.8810101439@subnode.aiai.ed.ac.uk>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
A non-trivial expression must be a list of at least 2 elements, so
let's guess that our solution looks like:
( ____________ ___________ )
The first blank must be a lambda expression if we are to avoid the
necessity of defining a function outside of our solution. (Which
would violate the self-reproducing aspect to some extent.)
( (lambda (x) ________ ) ____________ )
The choice of the name ``x'' was arbitrary. The choice of one
argument followed from the assumption of a two element list. The body
of the lambda expression must return a two element list, if we are to
re-produce the original input. There are different choices possible;
I'll choose
( (lambda (x) (list _____ _____ )) ___________ )
The argument might as well be quoted, otherwise we need to delve
deeper into the expression. This then determines some of the second
argument to ``list''.
( (lambda (x) (list _1_ (list (quote quote) _2_ ))) (quote _3_ ) )
Now comes the ``magic'' part. Notice that whatever is written in _3_,
we can make the second element of our result match by replacing _2_ by x.
( (lambda (x) (list _1_ (list (quote quote) x ))) (quote _3_ ) )
yields ( value_of_1_ (quote _3_ ) )
We can now use ``x'' for _1_, which let's us determine the value_of_1_
by our choice of _3_. The solution follows immediately.
( (lambda (x) (list x (list (quote quote) x )))
(quote (lambda (x) (list x (list (quote quote) x ))) ) )
The logic of the derivation makes this easy to remember/reconstruct.
--
-----
Gary Levin/Dept of Math & CS/Clarkson Univ/Potsdam, NY 13676/(315) 268-2384
BitNet: gary@clutx Internet: gary@clutx.clarkson.edu
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29347; Wed, 12 Oct 88 02:08:04 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA28514; Wed, 12 Oct 88 02:07:56 MDT
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA16036; Wed, 12 Oct 88 01:07:26 PDT
Date: Wed, 12 Oct 88 01:07:26 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8810120807.AA16036@kestrel.arpa>
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
*** EOOH ***
Date: Wed, 12 Oct 88 01:07:26 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
Here's a fun variation: write a Lisp function which returns its own
defining form (that is, a form EQUAL to the one you typed in to define
the function in the first place).
My solution to follow. No doubt there are many.
-- Scott
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29368; Wed, 12 Oct 88 03:37:21 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29288; Wed, 12 Oct 88 03:37:11 MDT
Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 12 Oct 88 04:08:34 EDT
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA16036; Wed, 12 Oct 88 01:07:26 PDT
Date: Wed, 12 Oct 88 01:07:26 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8810120807.AA16036@kestrel.arpa>
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
*** EOOH ***
Date: Wed, 12 Oct 88 01:07:26 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
In-Reply-To: Harold Carr's message of Fri, 7 Oct 88 14:19:26 MDT <8810072019.AA25193@car.utah.edu>
Subject: self reproducing code
Here's a fun variation: write a Lisp function which returns its own
defining form (that is, a form EQUAL to the one you typed in to define
the function in the first place).
My solution to follow. No doubt there are many.
-- Scott
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29603; Wed, 12 Oct 88 10:39:41 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA07201; Wed, 12 Oct 88 10:39:25 MDT
Message-Id: <8810121639.AA07201@cs.utah.edu>
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 12 Oct 88 12:11:03 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 9799; Wed, 12 Oct 88 12:07:43 EDT
Received: from IRUCCIBM by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 9798;
Wed, 12 Oct 88 12:06:34 EDT
Received: from IRUCCVAX.UCC.IE by IRUCCIBM (Mailer X1.25) with BSMTP id 1372;
Wed, 12 Oct 88 16:34:38 IST
Date: Wed, 12 Oct 88 16:35 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: Self-reproducing code (correction)
To: SCHEME@MC.LCS.MIT.EDU
X-Vms-To: SCHEME
*** EOOH ***
Date: Wed, 12 Oct 88 16:35 GMT
From: "G.OULSNAM" <STCS8004%IRUCCVAX.UCC.IE@MITVMA.MIT.EDU>
Subject: Self-reproducing code (correction)
To: SCHEME@MC.LCS.MIT.EDU
X-Vms-To: SCHEME
My thanks to John Gateley for pointing out the erroneous claim regarding
the normal order/applicative order evaluation of ((lambda (x) (x x) (lambda
(x) (x x)). I'm sorry he chose not to examine the rest of the derivation,
as it did not rely on the erroneous claim. For the record, what I now
consider I should have written was:
"Consider
((lambda (x) (x x)) (lambda (x) (x x))).
With normal order evaluation this reproduces itself, but loops forever on
attempting to evaluate the result. However, in Scheme the
argument is evaluated to an internal procedure, say #<procedure>, which
then loops forever trying to evaluate the first (x x) in the above
expression, without reproducing the original form directly."
The remark about Scheme applies to TI Scheme (v2), and can be checked by
depositing extra code to see what is being passed around. My point was, and
remains, that both normal order and applicative order (by-value in Scheme)
cause the above to loop, but for different reasons. Normal order provided
the idea for self-reproducing code, if one could first find a way to
emulate normal order evaluation, and then find a way to stop evaluation of
the result. The remainder of the article showed how.
Gordon Oulsnam.
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA29691; Wed, 12 Oct 88 12:02:08 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA11572; Wed, 12 Oct 88 12:01:48 MDT
Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 12 OCT 88 12:36:11 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07031@EDDIE.MIT.EDU>; Wed, 12 Oct 88 12:35:42 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA19237@BLOOM-BEACON.MIT.EDU>; Wed, 12 Oct 88 12:09:38 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Oct 88 22:58:15 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Subject: Re: Self-reproduction
Message-Id: <26381@ucbvax.BERKELEY.EDU>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
*** EOOH ***
Date: 10 Oct 88 22:58:15 GMT
From: dewey.soe.berkeley.edu!oster@ucbvax.berkeley.edu (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Subject: Re: Self-reproduction
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
A cute trick, not quite a self-reproducing program, but an interesting
example of a string that produces itself, is to take an arbitrary error
message, and hand it back to the interpreter as input. On many systems if
you repeat this 4-8 times, you reach a fixed point at which no further
change occurs. This is also fun with a C compiler.
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA00414; Thu, 13 Oct 88 02:58:28 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA03251; Thu, 13 Oct 88 02:58:22 MDT
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA25781; Thu, 13 Oct 88 04:58:07 EDT
Received: by mcvax.cwi.nl; Wed, 12 Oct 88 04:47:36 +0100 (MET)
Received: from ski.cs.vu.nl by botter.cs.vu.nl id aa02469; 11 Oct 88 18:57 MET
To: carr%car@cs
From: J A Biep Durieux <mcvax!cs.vu.nl!biep@uunet.UU.NET>
Subject: Re: self reproducing code
Newsgroups: comp.lang.scheme
In-Reply-To: <8810072019.AA25193@car.utah.edu>
References: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Organization: VU Informatica, Amsterdam
Cc:
Date: Tue, 11 Oct 88 18:58:01 MET
Sender: mcvax!cs.vu.nl!biep@uunet.UU.NET
Message-Id: <8810111858.aa17014@ski.cs.vu.nl>
*** EOOH ***
To: carr%car@cs
From: J A Biep Durieux <mcvax!cs.vu.nl!biep@uunet.UU.NET>
Subject: Re: self reproducing code
Newsgroups: comp.lang.scheme
In-Reply-To: <8810072019.AA25193@car.utah.edu>
References: <19881007200040.6.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Organization: VU Informatica, Amsterdam
Cc:
Date: Tue, 11 Oct 88 18:58:01 MET
Sender: mcvax!cs.vu.nl!biep@uunet.UU.NET
If you want trivial ones too, what about
NIL
or, even shorter
T
?
--
Biep. (biep@cs.vu.nl via mcvax)
Never confound "power", "command" with "right",
especially not when it concerns our own body!
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA00973; Thu, 13 Oct 88 14:40:38 MDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA19175; Thu, 13 Oct 88 14:40:25 MDT
Received: from aic.nrl.navy.mil (TCP 3200200010) by MC.LCS.MIT.EDU 12 Oct 88 13:45:38 EDT
Return-Path: <hoey@aic.nrl.navy.mil>
Received: Wed, 12 Oct 88 13:43:58 EDT by aic.nrl.navy.mil id AA19260
Date: Wed, 12 Oct 88 13:43:58 EDT
From: Dan Hoey <hoey@aic.nrl.navy.mil>
Message-Id: <8810121743.AA19260@aic.nrl.navy.mil>
To: scheme@mc.lcs.mit.edu
Subject: Automatic programming
*** EOOH ***
Return-Path: <hoey@aic.nrl.navy.mil>
Date: Wed, 12 Oct 88 13:43:58 EDT
From: Dan Hoey <hoey@aic.nrl.navy.mil>
To: scheme@mc.lcs.mit.edu
Subject: Automatic programming
My favorite version of the LAMBDA self-reproducer is
((LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA))
'(LAMBDA (LAMBDA) `(,LAMBDA ',LAMBDA)))
though SCHEMErs will have to forgo the pun. There is also
(format t "~A~:*~S)" "(format t \"~A~:*~S)\" ")
Dan
Received: by car.utah.edu (5.54/utah-2.0-leaf)
id AA01218; Fri, 14 Oct 88 02:08:47 MDT
Received: from MC.LCS.MIT.EDU by cs.utah.edu (5.59/utah-2.0-cs)
id AA13301; Fri, 14 Oct 88 02:08:40 MDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Oct 88 03:44:02 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA07904@BLOOM-BEACON.MIT.EDU>; Thu, 13 Oct 88 23:46:04 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Oct 88 09:58:03 GMT
From: mcvax!enea!kth!draken!Urd!newsuser@uunet.uu.net (LTH network news server)
Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden
Subject: Self-reproducing code
Message-Id: <1988Oct12.105804.3747@LTH.Se>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
*** EOOH ***
Date: 12 Oct 88 09:58:03 GMT
From: mcvax!enea!kth!draken!Urd!newsuser@uunet.uu.net (LTH network news server)
Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden
Subject: Self-reproducing code
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
Several examples of self-reproducing code has been given in this group
lately. While running a definite risc of reminding people of what may
be already generally known, I would like to submit the shortest solution
of all. And not only the shortest, it will work in almost any language!
The solution is:
The only problem with this solution, the empty program, is that someone
might argue that it is not a program at all. Still, I think it has a
certain elegance to it.
"Real Programmers aren't afraid of RISC architectures."
--
Jan Eric Larsson janeric@Control.LTH.Se +46 46 108795
Department of Automatic Control
Lund Institute of Technology "We watched the thermocouples dance to the
Box 118, S-221 00 LUND, Sweden spirited tunes of a high frequency band."
Received: from cs.utah.edu by car.utah.edu (5.59/utah-2.0-leaf)
id AA02703; Mon, 17 Oct 88 12:07:50 MDT
Received: from KESTREL.ARPA by cs.utah.edu (5.59/utah-2.0-cs)
id AA03697; Mon, 17 Oct 88 12:07:01 MDT
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA14370; Mon, 17 Oct 88 07:50:21 PDT
Date: Mon, 17 Oct 88 07:50:21 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8810171450.AA14370@kestrel.arpa>
To: carr%car@cs
Subject: Lisp function which returns its own defining form
*** EOOH ***
Date: Mon, 17 Oct 88 07:50:21 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
To: carr%car@cs
Subject: Lisp function which returns its own defining form
In deference to the recent complaints, I'm not sending this to the
whole list, but I thought you'd like to see it, since I had promised
it:
(defun generate-self ()
(let ((foo (quote (lambda (x)
(list (quote defun) (quote generate-self)
(list (quote let)
(list (list (quote foo)
(list (quote quote) x)))
(quote (funcall foo foo))))))))
(funcall foo foo)))
As you can see, it makes use of the somewhat archaic property retained
in Common Lisp that a list whose car is 'LAMBDA is a funcallable
object. To do the same thing in Scheme requires an explicit call to
EVAL, which makes it a little plainer what's going on.
-- Scott
Received: from cs.utah.edu by car.utah.edu (5.59/utah-2.0-leaf)
id AA03897; Wed, 19 Oct 88 05:20:38 MDT
Received: from uunet.UU.NET by cs.utah.edu (5.59/utah-2.0-cs)
id AA09978; Wed, 19 Oct 88 05:20:29 MDT
Received: from mcvax.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA05951; Wed, 19 Oct 88 07:19:56 EDT
Received: by mcvax.cwi.nl; Mon, 17 Oct 88 14:28:41 +0100 (MET)
Received: by inria.inria.fr with Fnet-EUnet; Fri, 14 Oct 88 14:39:17 +0100 (MET)
Date: Fri, 14 Oct 88 12:00:25 -0100
From: mcvax!poly!queinnec@uunet.UU.NET (Queinnec Christian)
Message-Id: <8810141100.AA23995@poly.poly.fr>
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
Subject: Self reproducing code
*** EOOH ***
Date: Fri, 14 Oct 88 12:00:25 -0100
From: mcvax!poly!queinnec@uunet.UU.NET (Queinnec Christian)
To: carr%car@cs
Cc: scheme@mc.lcs.mit.edu
Subject: Self reproducing code
I wrote these two solutions several years ago after seeing the original
problem in the McCarthy's paper "Lisp Micro-Manual, not the whole
truth" as a little exercice. Something like (as I remember)
Find s such that (equal s (eval s))
which is self-reproducing code.
They are written in Le-Lisp and can be found as examples in its manual
after description of EQUAL.
((lambda (s) `(,(car s) ',s))
'((lambda (s) `(,(car s) ',s))) )
and using old-style FLAMBDA (fexprs)
((flambda (s) `(,s ,s)) (flambda (s) `(,s ,s)))
which bears strong similarity to a certain lambda term.
-----------------------------------------------------------------------
New Address !!! Christian Queinnec
LIX Laboratoire d'Informatique de l'\'Ecole Polytechnique
Route de Saclay 91128 Palaiseau Cedex France
Internet: queinnec@poly.poly.fr Earn: QUEINNEC at FRPOLY11
-----------------------------------------------------------------------
Received: from cs.utah.edu by car.utah.edu (5.59/utah-2.0-leaf)
id AA07808; Tue, 25 Oct 88 17:04:02 MDT
Received: from MC.LCS.MIT.EDU by cs.utah.edu (5.59/utah-2.0-cs)
id AA10378; Tue, 25 Oct 88 17:03:53 MDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 24 Oct 88 14:56:59 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3598; Mon, 24 Oct 88 09:37:18 EDT
Received: from DB0TUI6.BITNET (ZTUBTFAL) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 3597; Mon, 24 Oct 88 09:22:50 EDT
Received: by tub.UUCP; Mon, 24 Oct 88 13:38:39 +0200; AA06867
Received: by tub-tfs.uucp (4.0/SMI-3.0DEV3)
id AA20497; Mon, 24 Oct 88 13:40:34 +0100
Date: Mon, 24 Oct 88 13:40:34 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8810241240.AA20497@tub-tfs.uucp>
To: tub!scheme%mc.lcs.mit.edu
Subject: Re: self-replicating-code, self-replicating-messages
*** EOOH ***
Date: Mon, 24 Oct 88 13:40:34 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
To: tub!scheme%mc.lcs.mit.edu
Subject: Re: self-replicating-code, self-replicating-messages
I find it more interesting to discuss things like self replicating
code than technical details of SCHEME Implementations. Perhaps I am
on the wrong mailing list. Is there one about functional-programming,
lambda-calculus, theory and application ???
The most solutions to the problem were quite tricky. The reason is
that the problem was ill defined. The most interesting contributioon
came from
"G.OULSNAM" <uunet!MITVMA.MIT.EDU!STCS8004%IRUCCVAX.UCC.IE@tub.UUCP>
((lambda (x) (x x)) (lambda (x) (x x)))
The critic was that these expression has no normal form - even worse
it is an example for an so called non solvable term, which puts even
a lazy evaluator (which does only head reductions) into an infinite
loop.
But the point is, that every solution to the proble has no normal
form, because if :
x ---> x
(---> means reduces to), than you can go on reducing x...
More interesting is another question : Is there a function, which
returns itself for every argument ?
This problem can be solved more straightforward. You just need a
solution for the equation
f x = f , for every x.
This can be done with the fixed-point-combinator Y. The solution is
f = Y K
or in lambda notation :
f = lambda f . ( lambda x . f x x ) ( lambda x . f x x )
(lambda x y . x)
The Y - Kombinator is a relative of letrec in scheme, so in scheme you
would write :
(define y-k (letrec ((h (lambda (x) h))) h))
It is also possible to define Y in terms of simple scheme expressions
without refering to letrec at all :
(define (yy y f x) ((f ((y y) f)) x))
(define y (yy yy))
So now you can just write :
(define (k x) (lambda (y) x))
(define y-k (y k))
Thorsten
Received: from cs.utah.edu by car.utah.edu (5.59/utah-2.0-leaf)
id AA08172; Wed, 26 Oct 88 11:42:43 MDT
Received: from MC.LCS.MIT.EDU by cs.utah.edu (5.59/utah-2.0-cs)
id AA03858; Wed, 26 Oct 88 11:42:26 MDT
Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 26 Oct 88 13:16:05 EDT
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1800; Wed, 26 Oct 88 13:13:48 EDT
Received: from DB0TUI6.BITNET (ZTUBTFAL) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 1798; Wed, 26 Oct 88 13:13:04 EDT
Received: by tub.UUCP; Wed, 26 Oct 88 18:11:43 +0200; AA12857
Received: by tub-tfs.uucp (4.0/SMI-3.0DEV3)
id AA05234; Wed, 26 Oct 88 18:13:44 +0100
Date: Wed, 26 Oct 88 18:13:44 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8810261713.AA05234@tub-tfs.uucp>
To: tub!uunet!rice.edu!dorai
Cc: tub!scheme%mc.lcs.mit.edu
In-Reply-To: Dorai Sitaram's message of Tue, 25 Oct 88 22:46:50 CDT
<8810260346.AA26475@titan.rice.edu>
Subject: self-replicating-code, self-replicating-messages
*** EOOH ***
Date: Wed, 26 Oct 88 18:13:44 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
To: tub!uunet!rice.edu!dorai
Cc: tub!scheme%mc.lcs.mit.edu
In-Reply-To: Dorai Sitaram's message of Tue, 25 Oct 88 22:46:50 CDT
<8810260346.AA26475@titan.rice.edu>
Subject: self-replicating-code, self-replicating-messages
> I think you are confusing the phenomenon of reduction to normal form
> in the lambda calculus with the process of evaluation which takes
> place in the case of a Scheme program yielding a value.
Sorry, I haven't been clear here. There is a strong analogy between
reduction and evaluation, but it's not the same thing. For me the
lambda calculus serves as a principial model of functional languages,
which can be used to understand certain aspects of these languages
without the overload of accidential properties of implementations. So
evaluation relates to reduction and values to normal forms.
There are functional languages which use reduction as evaluation.
MIRANDA is such an example, it uses a reduction machine for lazy
evaluation. See the book of Simon L. Peyton Jones ("The implementation
of functional programming languages", Prentice/Hall, 1988) for how
lazy functional languages are implemented by reduction machines.
> E.g., the result of the program (list 'list 8) is (list 8), *not* (8),
> which would have been the case in the case of continual reduction.
I think the relation between normal forms and values is, that normal
forms somehow denotate values. The point that lisp values can be lisp
programs again is - as important it is for programming practice - only
confusing here.
> >(define (yy y f x) ((f ((y y) f)) x))
> >(define y (yy yy))
> You doubtless imply currying, viz.,
> (define yy (lambda (y) (lambda (f) (lambda (x) ((f ((y y) f)) x)))))
I am sorry, somehow I copied the old version of the function into my
buffer. I imply nothing it's just a mistake - your version is the
correct one.
Thank you for your comments . . .
Until now nobody has answered my other question (mailing list for
theoretical questions of functional programming).
Thorsten
Received: from cs.utah.edu by car.utah.edu (5.59/utah-2.0-leaf)
id AA08882; Thu, 27 Oct 88 15:33:32 MDT
Received: from MC.LCS.MIT.EDU by cs.utah.edu (5.59/utah-2.0-cs)
id AB05648; Thu, 27 Oct 88 15:33:14 MDT
Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Oct 88 16:16:53 EDT
Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7
id <AA22826@BLOOM-BEACON.MIT.EDU>; Thu, 27 Oct 88 05:47:31 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
for scheme@mc.lcs.mit.edu (scheme@mc.lcs.mit.edu)
(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Oct 88 00:58:21 GMT
From: pasteur!agate!saturn!kjell@ames.arpa (Kjell Post)
Organization: University of California, Santa Cruz
Subject: Re: self-replicating-code, self-replicating-messages
Message-Id: <5259@saturn.ucsc.edu>
References: <8810241240.AA20497@tub-tfs.uucp>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
*** EOOH ***
Date: 26 Oct 88 00:58:21 GMT
From: pasteur!agate!saturn!kjell@ames.arpa (Kjell Post)
Organization: University of California, Santa Cruz
Subject: Re: self-replicating-code, self-replicating-messages
References: <8810241240.AA20497@tub-tfs.uucp>
Sender: scheme-request@mc.lcs.mit.edu
To: scheme@mc.lcs.mit.edu
In article <8810241240.AA20497@tub-tfs.uucp> alti@tub-tfs.UUCP (Thorsten Altenkirch) writes:
>I find it more interesting to discuss things like self replicating
>code than technical details of SCHEME Implementations. Perhaps I am
>on the wrong mailing list. Is there one about functional-programming,
>lambda-calculus, theory and application ???
I haven't seen one but I certainly wouldn't mind.
By the way, why isn't there a comp.lang.ml?
fun Y f x = f (Y f) x;
fun fac x = Y (fn f => fn x => if x = 0 then 1 else x*f(x-1)) x;
-------
That's it....
------------------------------
End of Scheme Digest
********************
∂14-Nov-88 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #8
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Nov 88 21:47:47 PST
Date: 15 NOV 88 00:10:57 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #8
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #8 15 NOV 88 00:10:57 EST
Today's Topics:
Efficiency of Y (Was: Limitation with lambda)
Efficiency of Y (Was: Limitation with lambda)
----------------------------------------------------------------------
Date: 14 Nov 88 22:29:54 GMT
From: zodiac!DUCHAMPS.ADS.COM!rar@ames.arpa (Bob Riemenschneider)
Subject: Efficiency of Y (Was: Limitation with lambda)
Message-Id: <8811142229.AA01756@duchamps.ads.com>
[Sorry this is so late; I'm behind on my correspondence.]
Awhile ago, Joe Weening asserted (in response to an article posted by
Jonathan Dubman) that use of the Y combinator for definition of recursive
functions "would be fairly inefficient". Mark VandeWettering then questioned
this assertion in his response to Joe, saying that looking at the
efficiency of Y was an element of his thesis work.
Here's a simple experiment you can perform using your favorite Scheme.
1. Define a fixed point combinator:
(define Y
(lambda (g)
((lambda (h) (g (lambda (x) ((h h) x))))
(lambda (h) (g (lambda (x) ((h h) x)))))))
2. Define three procedures for computing the factorial function,
one iterative:
(define factorial-loop
(lambda (n)
(do ((i 1 (+ i 1))
(a 1 (* i a)))
((> i n) a))))
one recursive (but not tail-recursive, so introduction of an
accumulator is left up to the compiler):
(define factorial-rec
(lambda (n)
(if (= n 0)
1
(* n (factorial-rec (- n 1))))))
and one using the combinator:
(define factorial-lfp
(Y (lambda (f)
(lambda (n)
(if (= n 0)
1
(* n (f (- n 1))))))))
3. Compute the factorial of a number using each of the three procedures,
timing the results. Make the number large enough so that you can get
a reasonably accurate timing. (I found 100 worked well for MacScheme,
and 1000 for T on my Sun 3.)
I found performance of the three to be identical, leading me to believe that,
given current Scheme compiler technology, there's no reason to avoid using Y.
-- rar
------------------------------
Date: 15 Nov 88 02:55:51 GMT
From: edward@ucbarpa.berkeley.edu (Edward Wang)
Subject: Re: Efficiency of Y (Was: Limitation with lambda)
Message-Id: <26809@ucbvax.BERKELEY.EDU>
In article <8811142229.AA01756@duchamps.ads.com> you write:
> 3. Compute the factorial of a number using each of the three procedures,
> timing the results. Make the number large enough so that you can get
> a reasonably accurate timing. (I found 100 worked well for MacScheme,
> and 1000 for T on my Sun 3.)
>
>I found performance of the three to be identical, leading me to believe that,
>given current Scheme compiler technology, there's no reason to avoid using Y.
Wouldn't the time be dominated by bignum arithmetic?
A better test would be to go through the iterations without
actually computing the factorial.
------------------------------
End of Scheme Digest
********************
∂15-Nov-88 2211 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #9
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Nov 88 22:11:08 PST
Date: 16 NOV 88 00:11:14 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #9
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #9 16 NOV 88 00:11:14 EST
Today's Topics:
Scheme Digest #8 , Efficiency of Y
Efficiency of Y (Was: Limitation with lambda)
Scheme available via ftp?
The Paradoxical Combinator -- Y (LONG)
To Y or not to Y? That is the question! (Was: Efficiency of Y)
----------------------------------------------------------------------
Date: Tue, 15 Nov 88 10:26:46 EST
From: kranz@wheaties.ai.mit.edu (David Kranz)
Message-Id: <8811151526.AA00789@shredded-wheat.ai.mit.edu>
Subject: Scheme Digest #8 , Efficiency of Y
Edward Wang is correct that the time in the example is dominated by bignum
arithmetic. I changed the * in factorial to + and got the following result in
T3.1:
(factorial-loop 20000) -> .1 sec
(factorial-rec 20000) -> .22 sec
(factorial-lfp 20000) -> 1.32 sec
With *:
(factorial-rec 100) -> .42 sec
(factorial-rec 1000) -> 57.78 sec
------------------------------
Date: 15 Nov 88 16:51:50 GMT
From: mike@arizona.edu (Mike Coffin)
Subject: Re: Efficiency of Y (Was: Limitation with lambda)
Message-Id: <7857@megaron.arizona.edu>
From article <8811142229.AA01756@duchamps.ads.com> (Bob Riemenschneider):
> Here's a simple experiment you can perform using your favorite Scheme.
[three definitions of a factorial function omitted: one
iterative, one recursive, and one using the Y combinator]
> 3. Compute the factorial of a number using each of the three procedures,
> timing the results. Make the number large enough so that you can get
> a reasonably accurate timing. (I found 100 worked well for MacScheme,
> and 1000 for T on my Sun 3.)
>
> I found performance of the three to be identical, leading me to believe that,
> given current Scheme compiler technology, there's no reason to avoid using Y.
I tried this using T. When I performed the experiment as stated, I
indeed got identical times for the three definitions:
> (time (factorial-loop 100))
virtual time = 0.36 seconds
> (time (factorial-rec 100))
virtual time = 0.36 seconds
> (time (factorial-lfp 100))
virtual time = 0.36 seconds
However, when I instead calculated the factorial of a small number many
times, there was a huge difference --- more than a factor of 10 ---
between the times:
> (time (factorial-loop 10) 1000)
virtual time = 0.18 seconds
> (time (factorial-rec 10) 1000)
virtual time = 0.2 seconds
> (time (factorial-lfp 10) 1000)
virtual time = 2.58 seconds
I think the benchmark, as originally stated, mostly measures the speed
of longnum arithmetic, and not the efficiency of the various contol
constructs.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike
Tucson, AZ 85721 (602)621-2858
------------------------------
Date: 15 Nov 88 18:29:44 GMT
From: dweissfe@afit-ab.arpa (David P. Weissfeld)
Subject: Scheme available via ftp?
Message-Id: <722@afit-ab.arpa>
We are using scheme here on a number of our mainframes.
We are looking for the latest version of scheme.
The question is, is the latest version of scheme available
via ftp and if so, what is the ftp address?
Thanks....
------------------------------
Date: 15 Nov 88 23:03:24 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Subject: The Paradoxical Combinator -- Y (LONG)
Message-Id: <3168@uoregon.uoregon.edu>
Newsgroups: comp.lang.scheme
Subject: The Paradoxical Combinator -- Y
Expires:
References:
Sender:
Reply-To: markv@drizzle.UUCP (Mark VandeWettering)
Followup-To:
Distribution: world
Organization: University of Oregon, Computer Science, Eugene OR
Keywords:
Alternatively entitled:
"Y? Why Not?" :-)
The discussion that has been going on in regards to the Y combinator as
the basic operation in implementing recursive functions are interesting.
The practical tests that people have made have shown that the Y
combinator is orders of magnitude slower for implementing recursion than
directly compiling it.
This is true for Scheme. I hold that for an interesting set of
languages, (lazy languages) that this result will not necessarily hold.
The problem with Y isn't its complexity, it is the fact that it is an
inherently lazy operation. Any implementation in Scheme is clouded by
the fact that Scheme is an applicative order evaluator, while Y prefers
to be evaluated in normal order.
(define Y
(lambda (g)
((lambda (h) (g (lambda (x) ((h h) x))))
(lambda (h) (g (lambda (x) ((h h) x)))))))
(define fact
(lambda (f)
(lambda (n)
(if (= n 1)
1
(* n (f (- n 1)))))))
Evaluating (Y fact) 2 results in the following operations in
Scheme:
The argument is (trivially) evaluated, and returns two.
(Y fact) must be evaluated. What is it? Y and fact each evaluate
to closures. When applied, Y binds g to fact, and executes the
body.
The body is an application of a closure to another closure. The
operator binds h to the operand, and executes its body which....
Evaluates (g (lambda (x) ((h h) x))). The operand is a closure,
which gets built and then returns. g evaluates to fact. We
substitute the closure (lambda (x) ((h h) x)) in for the function
f in the definition of fact, giving...
(lambda (n)
(if (= n 1)
1
(* n ((lambda (x) ((h h) x)) (- n 1)))))
Which we return as the value of (Y fact). When we apply this to 2, we get
(* 2 ((lambda (x) ((h h) x)) 1))
We then have to evaluate
((lambda (x) ((h h) x)) 1)
or
((h h) 1)
But remembering that h was (lambda (h) (g (lambda (x) ((h h) x)))),
we have
(((lambda (h) (g (lambda (x) ((h h) x))))
(lambda (h) (g (lambda (x) ((h h) x)))))
1) ....
So, we rebind h to be the right stuff, and evaluate the body, which is
((g (lambda (x) ((h h) x))) 1)
Which by the definition of g (still == fact) is just 1.
(* 2 1) = 2.
########################################################################
Summary: If you didn't follow this, performing this evaluation
was cumbersome at best. As far as compiler or interpreter is
concerned, the high cost of evaluating this function is related
to two different aspects:
It is necessary to create "suspended" values. These suspended
values are represented as closures, which are in general heap
allocated and expensive.
For every level of recursion, new closures are created (h gets
rebound above). While this could probably be optimized out by a
smart compiler, it does seem like the representation of suspended
evaluation by lambdas is inefficient.
########################################################################
You can try to figure out how all this works. It is complicated, I
believe I understand it. The point in the derivation above is that in
Scheme, to understand how the implementation of Y works, you have to
fall back on the evaluation mechanism of Scheme. Suspended values must
be represented as closures. It is the creation of these closures that
cause the Scheme implementation to be slow.
If one wishes to abandon Scheme (or at least applicative order
evaluators of Scheme) one can typically do much better. My thesis work
is in graph reduction, and trying to understand better the issues having
to do with implementation.
In graph reduction, all data items (evaluated and unevaluated) have the
same representation: as graphs in the heap. We choose to evaluate using
an outermost, leftmost strategy. This allows the natural definition of
(Y h) = (h (Y h)) to be used. An application node of the form:
@
/ \
/ \
Y h
can be constructed in the obvious way:
@
/ \
/ \
h @
/ \
/ \
Y h
costing one heap allocation per level of recursion, which is
certainly cheaper than the multiple allocations of scheme
closures above. More efficiently, we might choose to implement
it using a "knot tying" version:
/\
/ \
@ |
/ \ /
/ \/
h
Which also works quite well. Y has been eliminated, and will
cause no more reductions.
The basic idea is somehow that recursion in functional languages
is analogous to cycles in the graph in a graph reduction engine.
Therefore, the Y combinator is a specific "textual" indicator of
the graph.
The G-machine (excellently described in Peyton Jones' book "The
Implementation of Functional Programming Languages") also
described the Y combinator as being efficient. He chose letrecs
as being a primitive in the extended lambda calculus. His
methodology behind compiling these recursive definitions was
basically to compile fixed code which directly built these cyclic
structures, rather than having them built at runtime.
I think (and my thesis work is evolving into this kind of
argument) that Y is overlooked for trivial reasons. Partial
evaluation and smarter code generation could make an SK based
compiler generate code which is equal in quality to that produced
by supercombinator based compilation.
This is too long already, ciao for now.
Mark VandeWettering
------------------------------
Date: 16 Nov 88 01:26:34 GMT
From: zodiac!DUCHAMPS.ADS.COM!rar@ames.arpa (Bob Riemenschneider)
Subject: To Y or not to Y? That is the question! (Was: Efficiency of Y)
Message-Id: <8811160126.AA02163@duchamps.ads.com>
Apparently, I should have been more explicit about the point I was making
in my previous posting. Let me take another shot at it.
When Joe Weening wrote that use of the Y combinator for definition of
recursive functions "would be fairly inefficient", I took him to be making
a general claim that you shouldn't use Y. (Maybe I was wrong about this.)
I decided to test this claim. Like most Lisp programmers, the first recursive
function test I try when testing is factorial. It turned out that bignum
arithmetic performance dominated everything else in the computation.
*That was the point I was trying to make.* My conclusion was not that you
can *always* use Y without performance penalty--I knew that was false based
on the second experiment I tried (see below)--but that you can *sometimes*
use Y without *significant* performance penalty. For all I knew a priori,
(factorial-lfp N) would run [[N]] times as slowly as (factorial-rec N), so
this seemed significant enough to post. Given that Y makes for more
elegant code than letrec--it's nice for the same reasons that lambda is nice--
the experiment shows that there may be a role for Y in your Scheme toolkit.
In particular, if you need to compute factorials (or Fibonacci numbers, or
...), but you don't need to compute them often, feel free to use Y. My
statement that
I found performance of the three to be identical, leading
me to believe that, given current Scheme compiler technology,
there's no reason to avoid using Y.
would have been less misleading if I'd added "completely" at the end.
But, based on the performance figures I've seen and my second experiment,
I'm now willing to go a bit farther.
Here's the second experiment.
1. Build a moderately complicated test list.
(define l '())
(do ((i 0 (+ i 1)))
((> i 15) i)
(set l (cons l l)))
(15 was determined by trial and error using T on a Sun--I wanted
the largest value that wouldn't cause a garbage collection during
a test run.)
2. Define three procedures for computing the function flatten, one
iterative:
(define flatten-trec-aux
(lambda (l l-aux l-acc)
(cond ((null? l-aux)
(cond ((null? l) l-acc)
((atom? l) (cons l l-acc))
(else
(flatten-trec-aux
(car l) (cdr l) l-acc))))
((atom? l-aux)
(flatten-trec-aux l '() (cons l-aux l-acc)))
(else
(flatten-trec-aux
(cons l (car l-aux))
(cdr l-aux)
l-acc)))))
(define flatten-trec
(lambda (l)
(flatten-trec-aux l '() '())))
one recursive:
(define flatten-rec
(lambda (l)
(cond ((null? l) '())
((atom? l) (list l))
(else (append
(flatten-rec (car l))
(flatten-rec (cdr l)))))))
and one using Y:
(define flatten-lfp
(Y (lambda (f)
(lambda (l)
(cond ((null? l) '())
((atom? l) (list l))
(else (append
(f (car l))
(f (cdr l)))))))))
3. Compute flatten of l using each of the three procedures, garbage
collecting between computations.
No bignums here, just basic list manipulation. I found flatten-lfp to be
about half as fast as flatten-rec, and flatten-rec to be about half as fast
as flatten-trec. (And I have a funny feeling flatten-trec-aux wasn't the
best choice of an auxiliary function for flatten-trec; it's just the first
thing that occurred to me.)
I'm still not sure I have a good handle on the efficiency of Y. But, based
on my two experiments and the other figures I've seen posted, I'll stick my
neck out and claim:
Y is *efficient enough* that using, say,
((Y (lambda (f) ... f ...)) --- )
in place of
(letrec ((f ...f...))
(f ---))
where ...f... won't give you tail-recursion, is *never* bad
programming; if efficiency is enough of a concern that Y
shouldn't be used, you should come up with an iterative
algorithm.
(Unlike my original claim, this *ought* to create some controversy!)
-- rar
------------------------------
End of Scheme Digest
********************
∂17-Nov-88 0200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #10
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Nov 88 21:51:05 PST
Date: 17 NOV 88 00:00:51 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #10
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #10 17 NOV 88 00:00:51 EST
Today's Topics:
Scheme Digest #8, Efficiency of Y
Scheme Digest #9
Scheme Digest #9
Scheme Digest #8, Efficiency of Y
----------------------------------------------------------------------
Date: Wed, 16 Nov 88 05:12:11 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8811161012.AA13091@kleph.ai.mit.edu>
Subject: Scheme Digest #8, Efficiency of Y
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 15 Nov 88 10:26:46 EST
From: kranz@wheaties.ai.mit.edu (David Kranz)
Edward Wang is correct that the time in the example is dominated by
bignum arithmetic. I changed the * in factorial to + and got the
following result in T3.1:
I tried a similar experiment in MIT Scheme (using + instead of *,
except a smaller loop to account for smaller fixnums), with the
following results:
(factorial-loop 100) -> 1.03 msec
(factorial-rec 100) -> 1.0 msec
(factorial-lfp 100) -> 2.74 msec
Bill Rozas has expended no small effort in the MIT Scheme compiler to
make the Y combinator produce good results, and these timings are
evidence of that. Still not perfect, but I believe Bill claims that
he can make the output code identical given a bit more work.
------------------------------
Date: Wed, 16 Nov 88 09:28:18 EST
From: bard@theory.lcs.mit.edu
Message-Id: <8811161428.AA13775@toucan.LCS.MIT.EDU>
Subject: Scheme Digest #9
>
> Mark VandeWettering writes:
>
> I think (and my thesis work is evolving into this kind of
> argument) that Y is overlooked for trivial reasons. Partial
> evaluation and smarter code generation could make an SK based
> compiler generate code which is equal in quality to that produced
> by supercombinator based compilation.
I thought that the reason for using supercombinators rather than S and K is
space. Ordinary \-calculus expressions can be translated into SK-combinatory
expressions, but the combinatory version is exponentially longer than the SK
term. Some sets of supercombinators give polynomial-length expansions; I
think some give linear expansions.
Now, code size isn't usually much of a problem, in that we don't
usually care whether a program is 50K or 250K. The difference between 50K
and 2↑50K is significant. I don't know if the translation has a decent
expected case or not.
In any event, the SK compiler has a lot of work to do before it can match
even a fairly stupid supercombinator compiler, simply because it can be
forced to produce incredibly long code. My guess, and I gather the guess of
many people who actually work on this, is that SK would lose. I would be
very interested in some proof that this guess was wrong.
-- Bard Bloom
------------------------------
Date: 16 Nov 88 18:59:15 GMT
From: jeschke@iuvax.cs.indiana.edu (Eric Jeschke)
Subject: Re: Scheme Digest #9
Message-Id: <15089@iuvax.cs.indiana.edu>
Mark VandeWettering writes:
|
| I think (and my thesis work is evolving into this kind of
| argument) that Y is overlooked for trivial reasons. Partial
| evaluation and smarter code generation could make an SK based
| compiler generate code which is equal in quality to that produced
| by supercombinator based compilation.
|
Bard Bloom points out the space problem:
|I thought that the reason for using supercombinators rather than S and K is
|space.
| <stuff deleted>
|
| In any event, the SK compiler has a lot of work to do before it can match
|even a fairly stupid supercombinator compiler, simply because it can be
|forced to produce incredibly long code. My guess, and I gather the guess of
|many people who actually work on this, is that SK would lose. I would be
|very interested in some proof that this guess was wrong.
|
More specifically, the problem is not with the larger code image
produced by SK compilation (because memory size is typically not a
problem these days), but rather that the granularity of the
instructions is too fine. Supercombinators have much coarser
granularity, and get more work done per `instruction'.
This is reminicent of the RISC vs. CISC arguments that are raging over
in comp.arch. I think Mark is making a case that with a high enough
instruction bandwidth and more intelligent code
generation/optimization, SK reduction performance could approach
current supercombinator reduction performance.
I doubt it, especially with SK, but you might with a larger set of
fixed combinators, such as Turner's expanded set. I think you will
also need hardware support to really approach/improve on
supercombinator performance. Some fixed combinator machines have been
built, but I haven't heard of any that are close performance-wise to
the current breed of supercombinator implementations.
In short, a number of people have looked into this already, and most
are opting in favor of supercombinators. With the performance of
general-purpose architectures climbing steadily, the trend seems to be
moving away from building special purpose machines. For the
forseeable future, fixed combinator implementations will be slower,
given the advanced state of supercombinator compilation techniques.
--
Eric ------
jeschke@iuvax.cs.indiana.edu ...{pyramid, rutgers}!iuvax!jeschke
------
------------------------------
Date: 16 Nov 88 16:43:27 GMT
From: polya!max@labrea.stanford.edu (Max Hailperin)
Subject: Re: Scheme Digest #8, Efficiency of Y
Message-Id: <5084@polya.Stanford.EDU>
In article <8811161012.AA13091@kleph.ai.mit.edu> cph@zurich.ai.mit.edu writes:
>Bill Rozas has expended no small effort in the MIT Scheme compiler to
>make the Y combinator produce good results, and these timings are
>evidence of that. Still not perfect, but I believe Bill claims that
>he can make the output code identical given a bit more work.
As this remark points out, there is no reason from an efficiency
standpoint to not simply define letrec in terms of Y. While Y may be
expensive in some general cases, as long as it only appears
surrounding an explicit lambda, there is no particular reason a
compiler can't catch on to what's going on.
HOWEVER,
There is another reason, in Scheme, not to use Y: it breaks the fact
that you can use procedures as objects. While the R↑3R says that a
procedure created by a given lambda at a given time will be eqv to
itself (and implies eq as well, though on looking I see that isn't in
there -- is this a mistake?), the same does not necessarily hold for
the various incarnations of a procedure that Y will churn out (or
rather, that Y is entitled to churn out: presumably in Rozas's
implementation there is indeed only one procedure).
Perhaps I'm wrong to mix together such disparate worlds as Y and
eqvness of procedures belong to, but I do consider this to be
something of an issue. Does anyone else?
------------------------------
End of Scheme Digest
********************
∂17-Nov-88 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #11
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Nov 88 21:30:54 PST
Date: 18 NOV 88 00:01:00 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #11
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #11 18 NOV 88 00:01:00 EST
Today's Topics:
Scheme Digest #8, Efficiency of Y
Scheme Digest #9
Scheme Digest #9
Scheme Digest #8, Efficiency of Y
Scheme Digest #9
AmigaScheme
Please use meaningful subject lines
Re↑2: Scheme Digest #8, Efficiency of Y
Re↑2: Scheme Digest #8, Efficiency of Y
Scheme Digest #8, Efficiency of Y
----------------------------------------------------------------------
Date: 17 Nov 88 00:30:53 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: Re: Scheme Digest #8, Efficiency of Y
Message-Id: <43311@yale-celray.yale.UUCP>
In article <8811161012.AA13091@kleph.ai.mit.edu>, cph@KLEPH (Chris Hanson)
writes:
>Bill Rozas has expended no small effort in the MIT Scheme compiler to
>make the Y combinator produce good results, and these timings are
>evidence of that. Still not perfect, but I believe Bill claims that
>he can make the output code identical given a bit more work.
Is there a particular reason why its worth a lot of effort to make Y
compile efficiently?? More the the point, does anyone have examples
of code that is more elegant (or better in some other way) than, say,
a simple recursive implementation??
Bruce
------------------------------
Date: 16 Nov 88 23:29:11 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Subject: Re: Scheme Digest #9
Message-Id: <3180@uoregon.uoregon.edu>
In article <15089@iuvax.cs.indiana.edu> jeschke@iuvax.UUCP (Eric Jeschke) writes:
> More specifically, the problem is not with the larger code image
>produced by SK compilation (because memory size is typically not a
>problem these days), but rather that the granularity of the
>instructions is too fine. Supercombinators have much coarser
>granularity, and get more work done per `instruction'.
Perhaps I haven't been entirely clear: I am NOT using SK combinators
as the final code in the target machine. Just as supercombinators have
an efficient implementation in the G-machine, I believe that SK
combinators have an efficient implementation in a similar stack based
machine.
Why use SK combinators? Because they provide a convenient formalism for
reasoning about optimizations, strictness and partial evaluation.
>This is reminicent of the RISC vs. CISC arguments that are raging over
>in comp.arch. I think Mark is making a case that with a high enough
>instruction bandwidth and more intelligent code
>generation/optimization, SK reduction performance could approach
>current supercombinator reduction performance.
I see the problem of implementing an SK machine as twofold, the
instructions themselves are reasonably "highlevel", but do relatively
little relative to the source language. For instance, a numerically
intensive program spends most of its time copying argument pointers into
the right place on the heap for execution.
I believe that by partially evaluating SK expressions, and studying the
actions that are performed in an INTERPRETER, we eliminate most of the
silly and redundant copying of pointers and heap allocation that plague
SK implementations.
>I doubt it, especially with SK, but you might with a larger set of
>fixed combinators, such as Turner's expanded set. I think you will
>also need hardware support to really approach/improve on
>supercombinator performance. Some fixed combinator machines have been
>built, but I haven't heard of any that are close performance-wise to
>the current breed of supercombinator implementations.
I should be more clear, when I say SK combinators, I mean the expanded
set.
> In short, a number of people have looked into this already, and most
>are opting in favor of supercombinators. With the performance of
>general-purpose architectures climbing steadily, the trend seems to be
>moving away from building special purpose machines. For the
>forseeable future, fixed combinator implementations will be slower,
>given the advanced state of supercombinator compilation techniques.
I agree in part, smart compilation will beat special hardware MOST of
the time. But I don't believe that the state of the art in compiler
technology has been applied to compiling combinators. Also, the target
of my compilation is NOT to a fixed set of combinators.
>Eric ------
> jeschke@iuvax.cs.indiana.edu ...{pyramid, rutgers}!iuvax!jeschke
>------
Mark VandeWettering
------------------------------
Date: 16 Nov 88 23:17:46 GMT
From: uoregon!markv@beaver.cs.washington.edu (Mark VandeWettering)
Subject: Re: Scheme Digest #9
Message-Id: <3179@uoregon.uoregon.edu>
In article <8811161428.AA13775@toucan.LCS.MIT.EDU> bard@THEORY.LCS.MIT.EDU writes:
>
>>
>> Mark VandeWettering writes:
>>
>> I think (and my thesis work is evolving into this kind of
>> argument) that Y is overlooked for trivial reasons. Partial
>> evaluation and smarter code generation could make an SK based
>> compiler generate code which is equal in quality to that produced
>> by supercombinator based compilation.
>I thought that the reason for using supercombinators rather than S and K is
>space. Ordinary \-calculus expressions can be translated into SK-combinatory
>expressions, but the combinatory version is exponentially longer than the SK
>term. Some sets of supercombinators give polynomial-length expansions; I
>think some give linear expansions.
This is true for the trivial compilation algorithm described in Turner's
original paper. Typically with better compilation and the addition of
several "longer reach" combinators, expansions can typically be O(nlogn)
or less.
I should point out that I do not intend to use SK combinators as the
final "primitives" in the SK machine. I believe that SK combinators
form a good basis for performing partial evaluation. Hence, the
compilation algorithm I am currently deriving is as follows:
SASL-like functional language
|
V
Enriched Lambda Calculus
|
V
SK combinators
| (by Partial Evaluation)
V
Stack Machine Code (similar to the G-machine)
I have found the work of Wand, Friedman, Haines and Kohlbecker to be
interesting, in that they transform an interpreter for Scheme into a
compiler. I have applied much of the same methodology within the
framework of a graph reduction engine, and find very interesting
results.
> Now, code size isn't usually much of a problem, in that we don't
>usually care whether a program is 50K or 250K. The difference between 50K
>and 2↑50K is significant. I don't know if the translation has a decent
>expected case or not.
Recent evidence has shown that it does have "decent" performance.
> In any event, the SK compiler has a lot of work to do before it can match
>even a fairly stupid supercombinator compiler, simply because it can be
>forced to produce incredibly long code. My guess, and I gather the guess of
>many people who actually work on this, is that SK would lose. I would be
>very interested in some proof that this guess was wrong.
I question whether "longer code" is indeed the bugaboo here. We are
basically talking about a logn performance difference here. Imagine
that our implementation of supercombinators actually required the
implementation of a primitive that didn't have a bounded execution time.
Most of the time, we are indeed concerned with TIME of execution rather
than space. I wonder (and don't really believe) if the way that other
supercombinator methods don't achieve shorter code is by making more
complex primitives.
It was an idea, not a particularly good one. I am very impressed
with the G machine, and find myself playing "catch up" to make SK
combinators have similar performance.
Why? Well, its the stuff that theses are made of.....
>-- Bard Bloom
Mark VandeWettering
------------------------------
Date: 17 Nov 88 02:43:28 GMT
From: zodiac!DUCHAMPS.ADS.COM!rar@ames.arpa (Bob Riemenschneider)
Subject: Re: Scheme Digest #8, Efficiency of Y
Message-Id: <8811170243.AA00199@duchamps.ads.com>
=> In article <8811161012.AA13091@kleph.ai.mit.edu>, cph@KLEPH (Chris Hanson)
=> writes:
=> >Bill Rozas has expended no small effort in the MIT Scheme compiler to
=> >make the Y combinator produce good results, and these timings are
=> >evidence of that. Still not perfect, but I believe Bill claims that
=> >he can make the output code identical given a bit more work.
=>
=> Is there a particular reason why its worth a lot of effort to make Y
=> compile efficiently?? More the the point, does anyone have examples
=> of code that is more elegant (or better in some other way) than, say,
=> a simple recursive implementation??
=>
=>
=> Bruce
Rather than present particular examples, let me make three general points.
1. Y is elegant for the same reason lambda is elegant: you can define
and use a procedure without having to give it a name.
2. The treatment of procedures in Scheme, while better than Lisp, is still
not entirely first-class. Here's an example.
Suppose n ==> 2. After
(define n (* n n))
n ==> 4: (* n n) gets evaluated, and the result gets stored in the
location n is bound to. Now suppose f computes the successor function.
If procedure values were treated like numeric values, after
(define f
(lambda (n)
(if (= n 0)
1
(+ n (f (- n 1))))))
f would compute the function that returns 1 when applied to 0,
and 2n when applied to any n > 0: the lambda would be evaluated in
an environment where f computes successor and the resulting procedure
would be stored in the location f is bound to. Of course, that's
not what happens in Scheme. The definition is interpreted as: let
f be a solution (in fact, the least solution) to
f = (lambda (n) ...f...)
Having Y allows you to convert the implicit definition into an
explicit definition
(define f (Y (lambda (g) (lambda (n) ...g...))))
and pretend that procedures are treated just like other values by define.
This certainly seems more elegant to me.
3. Having Y around makes Scheme seem more like "an interpreter for
extended lambda calculus".
-- rar
------------------------------
Date: 16 Nov 88 18:59:15 GMT
From: jeschke@iuvax.cs.indiana.edu (Eric Jeschke)
Subject: Re: Scheme Digest #9
Message-Id: <15089@iuvax.cs.indiana.edu>
Mark VandeWettering writes:
|
| I think (and my thesis work is evolving into this kind of
| argument) that Y is overlooked for trivial reasons. Partial
| evaluation and smarter code generation could make an SK based
| compiler generate code which is equal in quality to that produced
| by supercombinator based compilation.
|
Bard Bloom points out the space problem:
|I thought that the reason for using supercombinators rather than S and K is
|space.
| <stuff deleted>
|
| In any event, the SK compiler has a lot of work to do before it can match
|even a fairly stupid supercombinator compiler, simply because it can be
|forced to produce incredibly long code. My guess, and I gather the guess of
|many people who actually work on this, is that SK would lose. I would be
|very interested in some proof that this guess was wrong.
|
More specifically, the problem is not with the larger code image
produced by SK compilation (because memory size is typically not a
problem these days), but rather that the granularity of the
instructions is too fine. Supercombinators have much coarser
granularity, and get more work done per `instruction'.
This is reminicent of the RISC vs. CISC arguments that are raging over
in comp.arch. I think Mark is making a case that with a high enough
instruction bandwidth and more intelligent code
generation/optimization, SK reduction performance could approach
current supercombinator reduction performance.
I doubt it, especially with SK, but you might with a larger set of
fixed combinators, such as Turner's expanded set. I think you will
also need hardware support to really approach/improve on
supercombinator performance. Some fixed combinator machines have been
built, but I haven't heard of any that are close performance-wise to
the current breed of supercombinator implementations.
In short, a number of people have looked into this already, and most
are opting in favor of supercombinators. With the performance of
general-purpose architectures climbing steadily, the trend seems to be
moving away from building special purpose machines. For the
forseeable future, fixed combinator implementations will be slower,
given the advanced state of supercombinator compilation techniques.
--
Eric ------
jeschke@iuvax.cs.indiana.edu ...{pyramid, rutgers}!iuvax!jeschke
------
------------------------------
Date: 17 Nov 88 15:51:13 GMT
From: mailrus!uflorida!haven!uvaarpa!hudson!vivaldi.acc.Virginia.EDU!pmy@ohio-state.arpa (Pete Yadlowsky)
Subject: AmigaScheme
Message-Id: <777@hudson.acc.virginia.edu>
Hello,
Does anyone know if Scheme has been implemented on the Commodore Amiga?
Thanks.
Peter M. Yadlowsky
Academic Computing Center
University of Virginia
pmy@vivaldi.acc.Virginia.EDU
------------------------------
Date: Thu, 17 Nov 88 17:03:52 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8811172203.AA13742@void.ai.mit.edu>
Subject: Please use meaningful subject lines
Reply-To: scheme-request@mc.lcs.mit.edu
Now that the list is digested, it is important that submissions be
labeled with meaningful "Subject:" lines. (The subject line of each
item is listed in the table of contents at the top of the digest.)
This means you may have to override the default that your mail reading
system supplies if that's something useless like "Scheme Digest #10".
Thanks.
- administrator.
------------------------------
Date: 17 Nov 88 21:08:31 GMT
From: zodiac!DUCHAMPS.ADS.COM!rar@ames.arpa (Bob Riemenschneider)
Subject: Re↑2: Scheme Digest #8, Efficiency of Y
Message-Id: <8811172108.AA00499@duchamps.ads.com>
Max Hailpern writes:
=> There is another reason, in Scheme, not to use Y: it breaks the fact
=> that you can use procedures as objects. While the R↑3R says that a
=> procedure created by a given lambda at a given time will be eqv to
=> itself (and implies eq as well, though on looking I see that isn't in
=> there -- is this a mistake?), the same does not necessarily hold for
=> the various incarnations of a procedure that Y will churn out (or
=> rather, that Y is entitled to churn out: presumably in Rozas's
=> implementation there is indeed only one procedure).
=>
=> Perhaps I'm wrong to mix together such disparate worlds as Y and
=> eqvness of procedures belong to, but I do consider this to be
=> something of an issue. Does anyone else?
Could you provide a specific example? I don't see how Y makes the situation
any worse than lambda. Just as you might decide to write
(let ((p (lambda (n) ...n...)))
===p===p===)
rather than
===(lambda(n) ...n...)===(lambda (n) ...n...)===
because Scheme doesn't guarantee that even syntactically identical lambda
terms will test equivalent---Does anyone know why 'operational equivalence'
for procedures was defined extensionally, making it uncomputable, rather
than intensionally (say, in terms of alpha-convertability)?--, you might
decide to write
(let ((p (Y (lambda (q) ...q...))))
===p===p===)
rather than
===(Y (lambda(q) ...q...))===(Y (lambda (q) ...q...))===
Arguments against Y that apply equally well to lambda don't count!
-- rar
------------------------------
Date: 17 Nov 88 21:50:17 GMT
From: zodiac!SUMEX-AIM.STANFORD.EDU!mxh@ames.arpa (Max Hailperin)
Subject: Re: Re↑2: Scheme Digest #8, Efficiency of Y
Message-Id: <CMM.0.88.595806617.mxh@sumex-aim.stanford.edu>
What I had in mind was something like this:
(letrec ((p (lambda () p)))
(eqv? p (p)))
This is will evaluate to #t, according to R↑3R.
On the other hand, if we rewrite this as
(let ((p (Y (lambda (p) (lambda () p)))))
(eqv? p (p)))
then it is undefined whether the result will be #t or #f. For a
straightforward impelementation of Y, it will probably be #f, but for an
optimized one, it would be #t.
The problem is not, as you suggested, from two occurences of (Y (lambda
...)), but from the difference between the procedure as the outside world
knows it vs. as it knows itself.
Now that I've explained myself, let me try to answer your question about the
definition of eqvness of procedures. The problem with defining it as
alpha-convertability [plus same environment] is two fold:
1) It is not in keeping with the philosophy as to what a procedure is. In
particular, contrary to some other languages, scheme doesn't allow you to
"reopen" a closure: they are black boxes which can only be applied.
2) It can lead to inefficiencies of two sorts (one obvious, one less so):
a) if the implementation doesn't choose to fold together procedures
which are eqv in your sense, then testing eqvness is slow
b) if the implementation *does* choose to fold together procedures which
it can determine are operationally equivalent but *not* eqv in your
sense, then your eqv test becomes impossible -- so such a compiler
optimization has to be ruled out, at a possible loss in speed.
2b in particular essentially is a way of saying that you want to
define into the language spec a particular level of
compiler-optimization smarts. That's unwise. Moreover, the existing
definition turns out to work well in practice.
------------------------------
Date: 17 Nov 88 23:28:36 GMT
From: polya!max@labrea.stanford.edu (Max Hailperin)
Subject: Re: Scheme Digest #8, Efficiency of Y
Message-Id: <5145@polya.Stanford.EDU>
In article <8811170243.AA00199@duchamps.ads.com> rar@DUCHAMPS.ADS.COM
(Bob Riemenschneider) writes in response to a question of why Y is useful:
>1. Y is elegant for the same reason lambda is elegant: you can define
> and use a procedure without having to give it a name.
If you write
(Y (lambda (f)
(lambda (x)
... f ...)))
then you have given the procedure a name, namely f, within itself,
just not externally. The same can be accomplished with named-lambda
or with letrec. For example, (letrec ((f (lambda (x) ... f ...))) f).
So Riemenshneider's argument isn't much of an argument, if this is
all he has in mind.
What you can do with Y and not easily with letrec or some such is
write something like (Y f) or (Y (f x)). Of course, Rozas's optimized
implementation may not be quite as much help here. Does anyone have a
good use for Y in any context other than surrounding a lambda
expression?
>2. The treatment of procedures in Scheme, while better than Lisp, is still
> not entirely first-class. Here's an example
>
> Suppose n ==> 2. After
>
> (define n (* n n))
>
> n ==> 4: (* n n) gets evaluated, and the result gets stored in the
> location n is bound to. Now suppose f computes the successor function.
> If procedure values were treated like numeric values, after
>
> (define f
> (lambda (n)
> (if (= n 0)
> 1
> (+ n (f (- n 1))))))
>
> f would compute the function that returns 1 when applied to 0,
> and 2n when applied to any n > 0: the lambda would be evaluated in
> an environment where f computes successor and the resulting procedure
> would be stored in the location f is bound to. Of course, that's
> not what happens in Scheme.
Riemenshneider seems to be confused here about the store vs. the
environment. This has nothing to do with the firstclassness of
procedures. Incidentally, the numeric definition he gives only works
as he states at the top level: as an internal definition it is an
error.
------------------------------
End of Scheme Digest
********************
∂18-Nov-88 2110 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #12
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Nov 88 21:10:22 PST
Date: 19 NOV 88 00:01:03 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #12
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #12 19 NOV 88 00:01:03 EST
Today's Topics:
Re↑2: Scheme Digest #8, Efficiency of Y
Scheme Digest #8, Efficiency of Y
----------------------------------------------------------------------
Date: 18 Nov 88 19:43:31 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Re↑2: Scheme Digest #8, Efficiency of Y
Message-Id: <2165@kalliope.rice.edu>
Bob Riemenschneider writes:
$Max Hailpern writes:
$
$=> There is another reason, in Scheme, not to use Y: it breaks the fact
$=> that you can use procedures as objects. While the R↑3R says that a
$=> procedure created by a given lambda at a given time will be eqv to
$=> itself (and implies eq as well, though on looking I see that isn't in
$=> there -- is this a mistake?), the same does not necessarily hold for
$=> the various incarnations of a procedure that Y will churn out (or
$=> rather, that Y is entitled to churn out: presumably in Rozas's
$=> implementation there is indeed only one procedure).
$=>
$=> Perhaps I'm wrong to mix together such disparate worlds as Y and
$=> eqvness of procedures belong to, but I do consider this to be
$=> something of an issue. Does anyone else?
$
$Could you provide a specific example? I don't see how Y makes the situation
$any worse than lambda. Just as you might decide to write
$
$ (let ((p (lambda (n) ...n...)))
$ ===p===p===)
$
$rather than
$
$ ===(lambda(n) ...n...)===(lambda (n) ...n...)===
$
$because Scheme doesn't guarantee that even syntactically identical lambda
$terms will test equivalent---Does anyone know why 'operational equivalence'
$for procedures was defined extensionally, making it uncomputable, rather
$than intensionally (say, in terms of alpha-convertability)?--, you might
$decide to write
$
$ (let ((p (Y (lambda (q) ...q...))))
$ ===p===p===)
$
$rather than
$
$ ===(Y (lambda(q) ...q...))===(Y (lambda (q) ...q...))===
$
$Arguments against Y that apply equally well to lambda don't count!
$
$ -- rar
It is very useful that a procedure be eq to itself [and to nothing
else (not even to something alpha-convertible)]. For instance, we can
create abstract data objects using lambda and set!. Using the fact
that procedures are self-eq, we can determine whether these data
objects are self-eq.
Lambda and set! give the conventional Scheme way of getting recursive
functions with rec/letrec. Recursive procedures created thus a r e
self-eq, like any other procedure. Eg,
(let ([h (rec h (lambda (dummy) h))])
(eq? h (h 'any)))
yields t r u e.
However, if _h_ had been defined with _Y_, ie,
(let ([h (Y (lambda (h) (lambda (dummy) h)))])
(eq? h (h 'any)))
the result is f a l s e, owing of course to the different [read
non-eq] procedures created for _h_ at each time it shows up.
Self-eqness of ADOs is lost, and though it can retrieved with some
amount of hacking [like adding a separate field in the ADO a n d
redefining the eq function (see Matthias Felleisen's thesis where he
describes a cons data object)] the result is anything but concise or
easily extendable.
--dorai
------------------------------
Date: 18 Nov 88 20:41:59 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Scheme Digest #8, Efficiency of Y
Message-Id: <2166@kalliope.rice.edu>
In article <5145@polya.Stanford.EDU> mxh@ksl.Stanford.EDU (Max Hailperin) writes:
>In article <8811170243.AA00199@duchamps.ads.com> rar@DUCHAMPS.ADS.COM
>(Bob Riemenschneider) writes in response to a question of why Y is useful:
>
>>1. Y is elegant for the same reason lambda is elegant: you can define
>> and use a procedure without having to give it a name.
>
>If you write
> (Y (lambda (f)
> (lambda (x)
> ... f ...)))
>then you have given the procedure a name, namely f, within itself,
>just not externally. The same can be accomplished with named-lambda
>or with letrec. For example, (letrec ((f (lambda (x) ... f ...))) f).
>So Riemenshneider's argument isn't much of an argument, if this is
>all he has in mind.
Last time, I didn't wait to see Hailperin's response to
Riemenschneider before I posted m y own response, which turned out
to be almost a clone. Sorry. Now that H has answered the 2nd half of
R's claim #1, let's consider the 1st half:
Using whatever metric for elegance, Y c a n n o t be elegant for the
same [or similar] reason that lambda is. They are not in the same
league. Lambda is a core form; Y, on the other hand, is something
defined u s i n g lambda. Y can be compared to [let]rec, though. It
is strictly less powerful than the latter, for [let]rec can define
cyclic data objects, including self-eq recursive procedures, whereas Y
can only define non-self-eq recursive procedures. Y can however claim
elegance on the following point: it requires only one* core form
[lambda] for its definition, whereas [let]rec require two [lambda +
set!].
I have used the "elegance" of a construct to mean a combination of 2
factors, the economy of core forms needed to get it going, and the
profusion of other constructs this construct itself produces. The
latter, when applied to {a set of} core form(s) is better known as
"expressiveness".
--dorai
*if you consider a p p l i c a t i o n to be a core form, add one to
both contestants.
------------------------------
End of Scheme Digest
********************
∂19-Nov-88 2212 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #13
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Nov 88 22:12:15 PST
Date: 20 NOV 88 00:02:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #13
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #13 20 NOV 88 00:02:32 EST
Today's Topics:
combinator code (was Re: Scheme Digest #9)
combinator code (was Re: Scheme Digest #9)
----------------------------------------------------------------------
Date: 18 Nov 88 11:18:53 GMT
From: mcvax!ukc!s1!jrk@uunet.uu.net (Richard Kennaway CMP RA)
Subject: Re: combinator code (was Re: Scheme Digest #9)
Message-Id: <190@s1.sys.uea.ac.uk>
In article <8811161428.AA13775@toucan.LCS.MIT.EDU>, bard@THEORY.LCS.MIT.EDU writes:
>
> I thought that the reason for using supercombinators rather than S and K is
> space. Ordinary \-calculus expressions can be translated into SK-combinatory
> expressions, but the combinatory version is exponentially longer than the SK
> term. Some sets of supercombinators give polynomial-length expansions; I
> think some give linear expansions.
Here's a bunch of references for the complexity of various combinator
translations. I didnt see all of this discussion, so my apologies if
I'm repeating things that have already been said here.
Yes, SK is exponential, which is why (as far as I know) noone has ever
used it for a machine.
Turner gave a translation into S, K, B, C, and I (Bxyz = x(yz), Cxyz =
xzy, Ix = x), (Software P&E, vol9, 1979), which is cubic in the worst
case. He then added three more combinators S'wxyz = w(xz)(yz), B'wxyz
= wx(yz), and C'wxyz = wxzy, (J.Symb.Logic, vol.44, 1979) which is
quadratic in the worst case.
Counting arguments show that the best you can do with any fixed set of
combinators is nlogn. This can be achieved (Noshita, Inf.Proc.Letters,
vol.20, 1985, and - ahem - Kennaway, Inf.Proc.Letters, vol.24, 1987)
though first run-length encoding the runs of identical combinators that
Turner's second translation tends to give, then programming the
run-lengths in combinators. The last step is purely of theoretical
interest, in practice you might as well directly implement the
run-length encoded version, or the closely related "director strings"
(Kennaway, op.cit, and Kennaway&Sleep, ACM Toplas, October 1988), as
has been done on the SKIM2 machine (Stoye, Proc. Functional Programming
Workshop, Goteborg, 1985), to obtain a modest improvement in speed of
evaluation of expressions, compared with Turner's second translation.
(This is probably more important than getting the code size down - in
practice I doubt the quadratic effects are significant.)
Burton (Inf.Proc.Letters, vol.14, 1982) claims a linear translation,
but this depends on a different measure of the size, and when measured
on the same basis as the other references, it's also nlogn.
The basic idea embodied in Turner's second translation, and in director
strings, can also be found in an unpublished note which Dijkstra wrote
on seeing Turner's first translation (EWD735, 1980), but which no-one,
other than one anonymous referee, seems to have heard of.
There's also the related BC-chain translation, which is a linear-space
representation of Turner's second translation (Noshita & Hikita, 1984,
RIMS Symp. on Sofware Science & Engineering, Kyoto, 1984 - I'm sure
there's a more accessible reference, but I cant find it). Evaluation
of BC-chain expressions takes linear time relative to evaluation of
Turner (extended set) combinators. I dont know what the constant
factors look like.
Of course, given an nlogn translation into some fixed finite set of
combinators, you immediately have an nlogn translation into any finite
set capable of expressing a translation, even pure SK (compose the
first translation with a translation of the first set into the second -
only a linear expansion), though of course that's another purely
theoretical result - a bit like producing a RISC compiler by combining
a CISC compiler with a RISC emulator...
Supercombinators (Hughes, thesis, Oxford, 1984, and umpteen papers by
various people since then) are nlogn in the average and worst case.
Their advantage is not in the size of the translation but in speed of
execution, due to the fact that each supercombinator embodies a larger
chunk of computation, and that the supercombinators you get are
tailored to the program being compiled, providing more opportunities for
clever implementation. (Or so I assume - has anyone compared the actual
performance of something like SKIM2 running director strings with a
supercombinator machine?)
> Now, code size isn't usually much of a problem, in that we don't
> usually care whether a program is 50K or 250K.
:-) Unless you're running from floppies...(sorry, was thinking of comp.sys.mac)
> The difference between 50K
> and 2↑50K is significant. I don't know if the translation has a decent
> expected case or not.
It's difficult to define the "expected case" - depends on the probability
distribution of the programs you compile. What is a "typical" program?
For the nlogn translations it doesnt matter - once your worst case is down
to nlogn, the counting argument shows that must be the average case as well,
but for Turner's quadratic translation, you have to look at what sort of
programs produce the worst case. Worst-case lambda-expressions for this
translation have deeply nested subexpressions and functions of many arguments
- the nesting has to be proportional to the size of the program to get
the quadratic effects, e.g. (backslash = lambda):
\x1.\x2.\x3.\x4.\x5.(x5 ((x2 (x1 x4)) x3))
Does this ever happen?
> In any event, the SK compiler has a lot of work to do before it can match
> even a fairly stupid supercombinator compiler, simply because it can be
> forced to produce incredibly long code.
Is this a particular SK compiler you're talking about? Has someone actually
implemented the naive translation into just S and K? I'm not surprised it's
no good.
> -- Bard Bloom
--
Richard Kennaway
School of Information Systems, University of East Anglia, Norwich, U.K.
uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
------------------------------
Date: 18 Nov 88 18:27:59 GMT
From: mcvax!ukc!s1!jrk@uunet.uu.net (Richard Kennaway CMP RA)
Subject: Re: combinator code (was Re: Scheme Digest #9)
Message-Id: <191@s1.sys.uea.ac.uk>
Correction: Kennaway, Inf.Proc.Letters, vol.24, 1987, should have been
Kennaway&Sleep, Inf.Proc.Letters, vol.24, 1987.
--
Richard Kennaway
School of Information Systems, University of East Anglia, Norwich, U.K.
uucp: ...mcvax!ukc!uea-sys!jrk Janet: kennaway@uk.ac.uea.sys
------------------------------
End of Scheme Digest
********************
∂22-Nov-88 0200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #14
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 01:43:52 PST
Date: 22 NOV 88 00:02:46 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #14
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #14 22 NOV 88 00:02:46 EST
Today's Topics:
Scheme Digest #13
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 18:37:29 EST
From: bard@theory.lcs.mit.edu
Message-Id: <8811212337.AA01324@toucan.LCS.MIT.EDU>
Subject: Scheme Digest #13
> Worst-case lambda-expressions for this
> translation have deeply nested subexpressions and functions of many arguments
> - the nesting has to be proportional to the size of the program to get
> the quadratic effects, e.g. (backslash = lambda):
>
> \x1.\x2.\x3.\x4.\x5.(x5 ((x2 (x1 x4)) x3))
>
> Does this ever happen?
In more theoretical settings, at least,
LET x=m IN n
is identical to
(\x.n)m.
If the typical program structure is LISP-like, it is a long sequence of short
function declarations followed by a body:
LET x1 = m1 IN
LET x2 = m2 IN
...
LET xk = mk IN
n
which is indeed a deeply nested term, although not quite of the form above.
All this proves is that you should do something in a way other than the
theoretician's straightforward translation of LET. What methods are actually
used?
> > In any event, the SK compiler has a lot of work to do before it can match
> > even a fairly stupid supercombinator compiler, simply because it can be
> > forced to produce incredibly long code.
>
> Is this a particular SK compiler you're talking about? Has someone actually
> implemented the naive translation into just S and K? I'm not surprised it's
> no good.
The naive one. As I said before, I'm a theoretician (interested in
denotational semantics of lambda calculus) and woefully ignorant about
compiler technology.
-- Bard Bloom
------------------------------
End of Scheme Digest
********************
∂22-Nov-88 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #15
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Nov 88 21:54:43 PST
Date: 23 NOV 88 00:02:54 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #15
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #15 23 NOV 88 00:02:54 EST
Today's Topics:
Scheme Digest #13
large or long-running T pgms?
----------------------------------------------------------------------
Date: 22 Nov 88 15:37:21 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: Re: Scheme Digest #13
Message-Id: <43797@yale-celray.yale.UUCP>
In article <8811212337.AA01324@toucan.LCS.MIT.EDU>, bard@THEORY writes:
>If the typical program structure is LISP-like, it is a long sequence of short
>function declarations followed by a body:
> LET x1 = m1 IN
> LET x2 = m2 IN
> ...
> LET xk = mk IN
> n
>which is indeed a deeply nested term, although not quite of the form above.
>
>All this proves is that you should do something in a way other than the
>theoretician's straightforward translation of LET.
Not necessarily. A better solution (if it works) is working on optimizing
nested terms. This will help efficiency in the general case, not just in the
case of LET. (This is the T/Orbit approach.)
Bruce Krulwich
------------------------------
Date: 21 Nov 88 21:27:00 GMT
From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: large or long-running T pgms?
Message-Id: <82000003@uicbert.eecs.uic.edu>
I am trying to figure out how large and varied a body of T programs there
is, for the purpose of gathering dynamic statistics. (These statistics
would be useful in designing garbage collectors, among other things.)
I am particularly looking for programs that are large and/or long-running,
especially those that allocate more than about 5 megabytes of data over
the course of a run. Real, heavily-used programs are somewhat preferable
to throwaway prototypes, but all kinds would be helpful.
The point of this is that I may want to implement a special garbage
collector, instrumented to gather statistics on survival, locality of
reference, and locality of state changes. This empirical data would
be useful for designing garbage collectors, among other things.
If there is not a large body of *varied* programs, that weighs against
T and for a Common Lisp such as Kyoto.
Anyway, if you have large programs that you would be willing to send
me (hopefully with easy startup instructions), please drop me a note
with a short description of what the program does, how long it runs,
and (if possible) a guess at how much memory it uses.
Thanks prematurely,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
------------------------------
End of Scheme Digest
********************
∂23-Nov-88 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #16
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Nov 88 21:39:57 PST
Date: 24 NOV 88 00:03:27 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #16
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #16 24 NOV 88 00:03:27 EST
Today's Topics:
Lisp vs. Scheme Emacs
Lisp vs. Scheme Emacs
----------------------------------------------------------------------
Date: 22 Nov 88 21:54:36 GMT
From: att!alberta!calgary!cpsc!jameson@bloom-beacon.mit.edu (Kevin Jameson)
Subject: Lisp vs. Scheme Emacs
Message-Id: <237@cs-spool.calgary.UUCP>
Why is Lisp used in GNU Emacs (and in the rest of the Emacs family)
in preference to Scheme? Or phrased another way, would there be
any significant advantages/disadvantages to basing an editor on
Scheme instead of Lisp?
Thanks
Kevin
------------------------------
Date: 23 Nov 88 16:50:21 GMT
From: fenchurch!jbs@eddie.mit.edu (Jeff Siegal)
Subject: Re: Lisp vs. Scheme Emacs
Message-Id: <10502@eddie.MIT.EDU>
In article <237@cs-spool.calgary.UUCP> jameson@cpsc.ucalgary.ca (Kevin Jameson) writes:
>[...] basing an editor on Scheme
There is an editor called EDWIN, which is an Emacs look-alike, not
only based on Scheme, but written entirely in it.
Jeff Siegal
------------------------------
End of Scheme Digest
********************
∂24-Nov-88 2153 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #17
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Nov 88 21:53:20 PST
Date: 25 NOV 88 00:03:38 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #17
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #17 25 NOV 88 00:03:38 EST
Today's Topics:
----------------------------------------------------------------------
From: dbm@research.att.com
Date: Thu, 24 Nov 88 08:40:13 EST
CALL FOR PAPERS
Conference on Functional Programming Languages and
Computer Architecture
London, September 11-13, 1989
*Sponsored by IFIP WG 2.8 and ACM SIGPLAN/SIGARCH
The fourth in a series of conferences on Functional Programming
Languages and Computer Architectures will cover the theory, design,
implementation, and application of functional or applicative
programming languages, and research on new computer architectures
designed to support functional programming. Architectural issues
relating to implementation of functional programming languages on
conventional architectures are also relevant. Papers accepted for the
conference must contain material not presented previously in any
formal forum.
Authors should submit five copies of a {\it full\/} paper (not
exceeding 20 pages), and ten additional copies of a 300-word abstract
to the Chairman of the Program Committee (if copying facilities are
not available one copy will do). Submissions should be double spaced
or typeset 10-point on 16-point spacing. Names and affiliations of
authors should appear on both paper and abstract. Papers will be
judged on relevance, clarity, correctness, originality and
significance. It is important to include specific results, sketches
of their derivations, and comparisons with previous work.
Submissions must be received by March 10, 1989, and should include a
return postal address, and an electronic address wherever possible.
Authors will be notified of acceptance or rejection by May 8, 1989.
Full versions of the accepted papers must be received in camera-ready
form by June 16, 1989, for inclusion in the proceedings. Authors of
accepted papers will be expected to sign an ACM copyright release
form. Proceedings will be published by ACM Press in association with
Addison-Wesley and will be distributed at the symposium.
Program Committee Chair Program Committee
David MacQueen Doug DeGroot, Texas Instruments, USA
Attn: FPCA '89 Paul Hudak, Yale University, USA
Room 2C-322 John Hughes, Univeristy of Glasgow, GB
AT&T Bell Laboratories Thomas Johnsson, Chalmers Univ. of Technology, S
600 Mountain Avenue Richard Kieburtz, Oregon Graduate Center, USA
Murray Hill, NJ 07974 Gary Lindstrom, University of Utah, USA
U.S.A. John Mitchell, Stanford University, USA
Simon Peyton-Jones, University College London, GB
(201) 582-7691 Ronan Sleep, University of East Anglia, GB
macqueen@research.att.com Ascandar Suarez, DEC Paris Research, F
Local Arrangements Chair Conference Chair
Chris L. Hankin Joseph Stoy
Dept. of Computer Science Programming Research Group
Imperial College Oxford University
Huxley Building, Queen's Gate 8-11 Keble Road
London SW7 2BZ Oxford OX1 3DQ
GREAT BRITAIN GREAT BRITAIN
clh@doc.ic.ac.uk stoy@prg.ox.ac.uk
*International Federation for Information Processing:
Working Group 2.8 on Functional Programming.
*Association for Computing Machinery:
Special Interest Group on Programming Languages,
Special Interest Group on Computer Architecture.
------------------------------
End of Scheme Digest
********************
∂25-Nov-88 2137 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #18
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Nov 88 21:36:55 PST
Date: 26 NOV 88 00:03:52 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #18
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #18 26 NOV 88 00:03:52 EST
Today's Topics:
Xscheme for microport sys.V
----------------------------------------------------------------------
Date: 22 Nov 88 19:30:25 GMT
From: mcvax!inria!vmucnam!occam@uunet.uu.net (occam)
Subject: Xscheme for microport sys.V
Message-Id: <562@vmucnam.UUCP>
So could someone wo has sources (Preferably for UNIX microport sys.V and PC)
for Xscheme.
R.Laurens
C.N.A.M Paris (France)
e-mail occam@vmucnam.UUCP
------------------------------
End of Scheme Digest
********************
∂29-Nov-88 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #19
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 21:17:03 PST
Date: 30 NOV 88 00:04:31 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #19
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #19 30 NOV 88 00:04:31 EST
Today's Topics:
eliza
eliza
----------------------------------------------------------------------
Date: Tue, 29 Nov 88 17:04:28 +0100
From: alti%tub-tfs.uucp%TUB.BITNET@MITVMA.MIT.EDU (Thorsten Altenkirch)
Message-Id: <8811291604.AA24439@tub-tfs.uucp>
Subject: eliza
Is there somebody who has a version of eliza running in TI-SCHEME ?
I need it very soon !
Thanks a lot .
Thorsten
------------------------------
Date: 29 Nov 88 16:04:28 GMT
From: tub-tfs.UUCP!alti@bloom-beacon.mit.edu (Thorsten Altenkirch)
Subject: eliza
Message-Id: <8811291604.AA24439@tub-tfs.uucp>
Is there somebody who has a version of eliza running in TI-SCHEME ?
I need it very soon !
Thanks a lot .
Thorsten
------------------------------
End of Scheme Digest
********************
∂30-Nov-88 2202 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #20
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Nov 88 22:02:43 PST
Date: 1 DEC 88 00:09:30 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #20
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #20 1 DEC 88 00:09:30 EST
Today's Topics:
How to obtain TI PC-Scheme?
Lisp vs. Scheme Emacs
Peephole optimizers using expert systems
----------------------------------------------------------------------
Date: 26 Nov 88 00:06:31 GMT
From: mcvax!enea!kth!draken!tut!hydra!kreeta!grano@uunet.uu.net (Juhani Grano UNIX88)
Subject: How to obtain TI PC-Scheme?
Message-Id: <609@hydra.cs.Helsinki.FI>
I guess this is the right newsgroup -- sorry if I'm wrong. I'm
posting this on behalf of my friend who's been trying to obtain the Texas
Instruments PC-Scheme implementation of Scheme. As things are here in the
land of icebears and C hackers, it seems that he can't get it from here
in Finland. He even went that far that he wrote to TI in U.S., but with no
response, of course.
ANY help would be greatly appreciated (maybe a software company in
Europe/Scandinavia selling abroad?) as this really is frustrating...
Thanks in advance!
Kari Grano, student of computer sciences.
Try one of these: grano@finuha
grano@cc.helsinki.fi
------------------------------
Date: 29 Nov 88 11:15:49 GMT
From: mcvax!enea!kth!draken!tut!pk@uunet.uu.net (Kellom{ki Pertti)
Subject: Re: Lisp vs. Scheme Emacs
Message-Id: <5451@korppi.tut.fi>
In article <237@cs-spool.calgary.UUCP> jameson@cpsc.ucalgary.ca (Kevin Jameson) writes:
>Why is Lisp used in GNU Emacs (and in the rest of the Emacs family)
>in preference to Scheme?
As I understand it, GNU Emacs Lisp has been written solely for the purpose of
writing text editors. It has some really nice features for doing that, whereas
it lacks some features that more general purpose lisps have (closures among
others). The primitive editing functions of GNU Emacs Lisp have been written
in C, so they are pretty fast. The thing I am personally most impressed about
GNU Emacs Lisp is how easy it is to manipulate buffers, windows etc. from Lisp
code.
--
Pertti Kellomaki (the 'a' with an umlaut) Tampere Univ. of Technology
+358 31 640 550 home Internet: pk@tut.fi
+358 31 162 934 work (L406) UUCP: tut!pk
------------------------------
Date: 1 Dec 88 03:42:38 GMT
From: pasteur!sim.berkeley.edu!shuvra@ames.arpa (Shuvra S. Bhattacharyya)
Subject: Peephole optimizers using expert systems
Message-Id: <7873@pasteur.Berkeley.EDU>
Does anyone know of any past work on peephole optimizers
which use expert systems?
Please send replies to shuvra@sim.berkeley.edu
Thanks in advance,
----------
Shuvra
------------------------------
End of Scheme Digest
********************
∂01-Dec-88 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #21
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 21:20:29 PST
Date: 2 DEC 88 00:09:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #21
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #21 2 DEC 88 00:09:37 EST
Today's Topics:
Rationals in MIT C Scheme
Lisp vs. Scheme Emacs
----------------------------------------------------------------------
Message-Id: <8812012300.AA29544@cs2.wsu.edu>
Subject: Rationals in MIT C Scheme
Date: Thu, 01 Dec 88 15:00:32 -0800
From: eric@cs2.wsu.edu
Can anybody give me a quick run-down of the status of rationals in MIT
C Scheme. We are running 6.1.1 and the 'numerator' and 'denominator' functions
don't seem to exist. Is there a newer version with these incorporated. I am
doing research in continued fraction arithmetic and would like to be able to
use Scheme instead of Common LISP.
Thanks for any help,
Eric Schneider (eric@cs2.wsu.edu)
------------------------------
Date: 30 Nov 88 23:53:00 GMT
From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: Re: Lisp vs. Scheme Emacs
Message-Id: <82000004@uicbert.eecs.uic.edu>
On the other hand, in Stallman's paper on EMACS, he says that it
exploits dynamic binding for flexibility.
Is the Scheme version (Edwin) as elegant as the Lisp version? Does
it fake dynamic or fluid binding explicitly?
------------------------------
End of Scheme Digest
********************
∂02-Dec-88 2119 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #22
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Dec 88 21:19:29 PST
Date: 3 DEC 88 00:09:03 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #22
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #22 3 DEC 88 00:09:03 EST
Today's Topics:
Lisp vs. Scheme Emacs
Lisp vs. Scheme Emacs
----------------------------------------------------------------------
Date: 2 Dec 88 06:42:46 GMT
From: agate!saturn!kjell@labrea.stanford.edu (Kjell Post)
Subject: Re: Lisp vs. Scheme Emacs
Message-Id: <5621@saturn.ucsc.edu>
In article <82000004@uicbert.eecs.uic.edu> wilson@uicbert.eecs.uic.edu writes:
>
>On the other hand, in Stallman's paper on EMACS, he says that it
>exploits dynamic binding for flexibility.
How can a *bug* be considered flexible?
(Boy, am I in trouble now...)
--
For athletes and programmers, ! Kjell E. Post
a woman is the end of their career. ! CIS/CE
! University of California, Santa Cruz
-- A.Wickberg ! Email: kjell@saturn.ucsc.edu
------------------------------
Date: 3 Dec 88 01:05:58 GMT
From: ucsbcsl!vision!nosmo@bloom-beacon.mit.edu (Vincent Brooke Kraemer)
Subject: Re: Lisp vs. Scheme Emacs
Message-Id: <1020@hub.ucsb.edu>
Forgive my stupidity on this answer - but wasn't EMACS originally written in
Lisp, like way way back. (i.e. before we were scheme'ing)
I am sure that you can write an EMACS in just about any language you want -
but do you really want to ignore a considerable amount of work that has
already been tried and worked. The decision was probably made more on the
basis of intelligent software engineering practice than religious beliefs. Or
at least I would hope so.
-------------------------------------------------------------------------------
I only .sig in "soc." groups - real news doesn't need it.
------------------------------
End of Scheme Digest
********************
∂03-Dec-88 2155 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #23
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Dec 88 21:55:05 PST
Date: 4 DEC 88 00:09:16 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #23
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #23 4 DEC 88 00:09:16 EST
Today's Topics:
Scheme Digest #22
Lisp vs. Scheme Emacs
named-let* ; distinct ids in binding forms
----------------------------------------------------------------------
Date: Sat, 3 Dec 88 10:40:26 EST
From: bard@theory.lcs.mit.edu
Message-Id: <8812031540.AA00290@toucan.LCS.MIT.EDU>
Subject: Scheme Digest #22
>
> Forgive my stupidity on this answer - but wasn't EMACS originally written in
> Lisp, like way way back. (i.e. before we were scheme'ing)
>
EMACS was first written in TECO. TECO is an editor with a powerful
command language, so powerful that it is a general purpose programming
language. TECO is distinguished as the language in which optimally-formatted
programs look the most like line noise: the commands are mostly
control-characters with arguments. Even assembly language, optimally
formatted, is clearly text.
-- Bard
------------------------------
Date: Sat, 3 Dec 88 17:29 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: Lisp vs. Scheme Emacs
Message-ID: <19881203222902.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Date: 2 Dec 88 06:42:46 GMT
From: agate!saturn!kjell@labrea.stanford.edu (Kjell Post)
How can a *bug* be considered flexible?
The original Scheme papers by Sussman and Steele contain some good
arguments for why dynamic variables are sometimes exactly what you want.
Date: 3 Dec 88 01:05:58 GMT
From: ucsbcsl!vision!nosmo@bloom-beacon.mit.edu (Vincent Brooke Kraemer)
Forgive my stupidity on this answer - but wasn't EMACS originally written in
Lisp, like way way back. (i.e. before we were scheme'ing)
No, the original EMACS was written in TECO. (And in case you are
wondering, TECO is dynamically scoped.)
------------------------------
Date: 3 Dec 88 22:14:22 GMT
From: pierce@locus.ucla.edu
Subject: named-let* ; distinct ids in binding forms
Message-Id: <18529@shemp.CS.UCLA.EDU>
A while back someone in this newsgroup asked if there were plans to add
a named-let* to official Scheme. I don't recall an answer to this.
I often find a named-let* useful, but really don't care if it becomes
official. I just wondered what the status of this issue was.
By named-let* I mean something like the following*:
(described in Eugene Kohlbecker's extend-syntax):
(extend-syntax (named-let*)
((named-let* loop ((x1 v1) ...) e1 e2 ...)
(andmap symbol? '(loop x1 ...))
(let* ((x1 v1) ...) (let loop ((x1 x1) ...) e1 e2 ...))))
-----
*Of course, there's no reason to have a separate syntax, they should
be combined as:
(extend-syntax (let*)
[(let* () e1 e2 ...)
(begin e1 e2 ...)]
[(let* ([x1 v1] [x2 v2] ...) e1 e2 ...)
(andmap symbol? '(x1 x2 ...))
(let ([x1 v1])
(let* ([x2 v2] ...) e1 e2 ...))]
[(let* loop ([x1 v1] ...) e1 e2 ...)
(andmap symbol? '(loop x1 ...))
(let* ([x1 v1] ...)
(let loop ([x1 x1] ...) e1 e2 ...))])
-----
Now this definition assumes that the identifiers bound by a named-let*
are distinct, but I don't see a reasonable interpretation for the meaning
of such a construction anyway. Thus the fender for named-let* might be
better written as:
(let ((ids '(loop x1 ...))
(distinct-symbols? (lambda (lst) {some appropriate defn})))
(and
(andmap symbol? ids)
(distinct-symbols? ids)))
where distinct-symbols? would have the obvious definition. Either that,
or multiple instances of the same identifier should be allowed. Any opinions
on that? (It is required that the name of a named-let be distinct from the
identifiers bound by that let, or not?)
------
I guess in addition to hearing about whether let* will be extended to include
a named form, I'd also like to find out which binding forms must bind only
distinct identifiers, and which need not, and the motivation for these
decisions.
-- Brad Pierce
pierce@CS.UCLA.EDU
------------------------------
End of Scheme Digest
********************
∂04-Dec-88 2112 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #24
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Dec 88 21:12:03 PST
Date: 5 DEC 88 00:05:46 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #24
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #24 5 DEC 88 00:05:46 EST
Today's Topics:
Where can I get XScheme?
----------------------------------------------------------------------
Date: 5 Dec 88 03:24:05 GMT
From: pasteur!agate!e260-2b.berkeley.edu!c60a-2ce@ames.arpa (Mikey)
Subject: Where can I get XScheme?
Message-Id: <17794@agate.BERKELEY.EDU>
If anyone has Xscheme, could you PLEASE send it to comp.binaries.mac?
If not, I'd love to know where I can get a copy of this. I'm taking a
course that uses Abelson & Sussman's book, you see...Thanks!
---------------------------------------------------------------------
Please reply via e-mail; I just don't have enough time to go thru
the entire newsgroup. Thanks a lot!
c60a-2ce@web.berkeley.edu.......................................Mikey
*** Call Tanelorn III! (415) 540-1180. The Apple/Mac BBS of Berkeley.
------------------------------
End of Scheme Digest
********************
∂05-Dec-88 2202 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #25
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 22:01:20 PST
Date: 6 DEC 88 00:06:03 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #25
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #25 6 DEC 88 00:06:03 EST
Today's Topics:
history of emacs and lisps
----------------------------------------------------------------------
Date: 5 Dec 88 16:39:03 GMT
From: polya!max@labrea.stanford.edu (Max Hailperin)
Subject: history of emacs and lisps
Message-Id: <5484@polya.Stanford.EDU>
>> Forgive my stupidity on this answer - but wasn't EMACS originally written in
>> Lisp, like way way back. (i.e. before we were scheme'ing)
>EMACS was first written in TECO.
While it is of course true that EMACS was originally a bunch of MIT
TECO [note that MIT TECO is not the same as DEC TECO] macros (that's
where the "MACS" part of the name comes from, if my memory serves me),
I believe there is some grain of truth in the original posting.
The second implementation of EMACS, very early on, was in Maclisp --
Multics EMACS. Unless I've got my history muddled, Multics EMACS does
predate Scheme. Therefore, there is indeed a historical grounding for
the use of Maclisp-family Lisps in writing EMACSes.
Of course, that's far from the whole story: there's also issues like
RMS's own background and tastes.
------------------------------
End of Scheme Digest
********************
∂06-Dec-88 2339 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #26
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Dec 88 23:39:02 PST
Date: 7 DEC 88 00:06:13 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #26
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #26 7 DEC 88 00:06:13 EST
Today's Topics:
lexical vs dynamic binding in editor macro languages.
EMACS and Lisp
jobs
Lisp vs. Scheme Emacs
----------------------------------------------------------------------
Date: Tue, 6 Dec 88 09:04:31 est
From: gjc%bucsf.BU.EDU@bu-it.bu.edu (George J. Carrette)
Message-Id: <8812061404.AA14759@bucsf>
Subject: lexical vs dynamic binding in editor macro languages.
It is very convenient to have dynamic binding in an editor extension
language because of the amount of state information and implied
arguments laying around. So even when you start with a lexically
scoped language, (e.g. VAX-NIL, in which the Steve editor was written)
you still end up using a lot of special variables. Especially if you
were influenced by multics emacs, zmacs, its emacs.
Editor authors usually implement their own CLOSURE mechanism as well,
and environment editing/augmenting mechanisms too. Usually terms like
"editor bindings," "buffer bindings," and "mode bindings" come into
play. It is usually quite interesting to see how the implementor
manages all these environment issues.
-gjc
------------------------------
Date: Tue, 6 Dec 88 15:03:27 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812062003.AA12924@verdi.think.com>
Subject: EMACS and Lisp
This is just to throw my memories and two cents' worth into the fray.
The original EMACS was indeed done in TECO. The EMACS command set was
an amalgam of four prototype command sets that had sprung up at MIT
once RMS had given us the ability to attach command strings to
keystrokes. I had observed that having four wildly different command
sets was impeding us, because one person could not sit down at
another's terminal to help him. I spent a few weeks running up and
down the halls and stairways with a matrix chart in my hands (the
columns were labelled ---, Control, Meta, and Control-Meta, and ASCII
characters down the left-hand edge labelled the rows), consulting with
implementors and users in Technology Square trying to get agreement on
a common set of editor commands. RMS came across me while I was
struggling to write the first thirty lines or so of TECO code to
implement the mess, offered to "help out"--and the rest is history: he
did essentially all of the implementation, as well as improving
substantially on the design, inventing new commands (and the necessary
TECO primitives to support them), and researching how users actually
used the commands. His is a magnificent achievement, against which
new editors are still sometimes measured, over ten years later.
According to Bernie Greenberg's paper in the 1980 Lisp Conference
("Prose and Cons"--what a wonderful title!), Multics EMACS was
written no earlier than 1978. Scheme first came out in 1975, and the
Revised Report on Scheme was published in January of 1978.
Nevertheless, Scheme was not available on Multics and MacLisp was.
Even if Scheme had been available, it would have been sensible to use
MacLisp anyway: for one thing, the Scheme implementations at MTI at
that time were all embedded in MacLisp anyway!
--Guy Steele
------------------------------
Date: 7 Dec 88 00:13:41 GMT
From: lord+@andrew.cmu.edu (Tom Lord)
Subject: jobs
Message-Id: <wXb7Spy00jaIIhWssR@andrew.cmu.edu>
Where can one earn a living exploring or extending Scheme?
-t
------------------------------
Date: Tue, 6 Dec 88 21:55:08 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8812070255.AA00972@kleph.ai.mit.edu>
Subject: Lisp vs. Scheme Emacs
Reply-To: cph@zurich.ai.mit.edu
Date: 30 Nov 88 23:53:00 GMT
From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
On the other hand, in Stallman's paper on EMACS, he says that it
exploits dynamic binding for flexibility.
Is the Scheme version (Edwin) as elegant as the Lisp version? Does
it fake dynamic or fluid binding explicitly?
As the author of Edwin, here's my "definitive" answer:
Naturally I believe that Edwin is as elegant as GNU Emacs; since half
the fun I get out of writing a program is making it elegant, I did my
best to accomplish this.
In some ways, it is less elegant: in particular, because Edwin was
about half built before I ever saw or played with GNU Emacs, many
parts of it are based on the original Emacs (most of the documentation
strings were snarfed directly from the TECO source code). Once I
found out about GNU Emacs, the design changed direction midstream, and
subsequent developments more closely mirror the GNU model. Future
work is likely to close the gap with GNU Emacs even more.
In other ways, I feel that it is more elegant: the programming model,
unlike GNU Emacs, fosters "object manipulation" rather than "editing
steps". By this, I mean the following: GNU Emacs (like Multics Emacs)
encourages the extension writer to view the activity of writing
extensions almost like that of writing keyboard macros; e.g. there is
always a current buffer, you switch buffers to change things in other
buffers, and there are a variety of things like `save-excursion' to
allow you to remember where you were in various ways. In other words,
many of the side effects that an extension performs are incidental
rather than essential. Edwin encourages you to think like a
programmer: you've got alot of objects lying around, and you
manipulate the objects directly; incidental side effects are
unnecessary, because there are no (or perhaps only a few) dependencies
on the current state. For example, if you want to change a buffer
other than the current one, you just get a pointer to it and
manipulate it using the usual mechanisms, which all accept buffers as
arguments.
Of course, judging elegance in this way is pretty artificial. Both of
these programming models are elegant in different ways. GNU Emacs'
programming model is elegant because it is similar to the model of the
Emacs user. Edwin's is elegant because distinguished objects play a
much smaller role, and certain kinds of programming abstractions are
easier to capture; also it is similar to the way that programmers
think (i.e. lots of objects, and side effects on those objects).
Finally: Edwin does GNU Emacs one better in the dynamic binding
question, because MIT Scheme has dynamic binding. Edwin uses dynamic
binding where it is appropriate, and the rest of the time it relies on
lexical scoping.
------------------------------
End of Scheme Digest
********************
∂07-Dec-88 2300 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #27
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 23:00:06 PST
Date: 8 DEC 88 00:06:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #27
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #27 8 DEC 88 00:06:33 EST
Today's Topics:
Commercial/Industry use of Scheme
R4RS changes? Code?
R4RS changes? Code?
----------------------------------------------------------------------
Date: 7 Dec 88 19:35:58 GMT
From: zodiac!andy@ames.arpa (Andy Cromarty)
Subject: Commercial/Industry use of Scheme
Message-Id: <6286@zodiac.UUCP>
In article <wXb7Spy00jaIIhWssR@andrew.cmu.edu lord+@andrew.cmu.edu
(Tom Lord) writes:
Where can one earn a living exploring or extending Scheme?
-t
My research group at Advanced Decision Systems uses Scheme exclusively
for our distributed computing research. We have our own R3RS compiler
and runtime environment with extensions to support our research in
object-oriented communications protocols, heterogeneous dynamic process
migration, real-time distributed problem solving, use of advanced
architecture computing systems, programming language research, and other
related topics. (I can provide a literature reference or two if there is
more interest.)
Texas Instruments has a long and impressive track record in the use
and promotion of Scheme. Surely they can represent their accomplishments
better than I, but as a brief synopsis: To my understanding, they use
Scheme (and even teach it) internally; they sell a Scheme product (TI's
PC Scheme); and they remain active in the Scheme design definition effort.
Presumably the folks at Semantic Microsystems (I believe that's their name)
who market Scheme for the Macintosh do a significant amount of Scheme coding
in the course of preparing their Scheme product, which in my estimation is
a first-class product. [Excuse the pun]
There doubtless are other active commercial/industry Scheme users; perhaps
this note will entice them out of the woodwork.
Andrew Cromarty
Advanced Decision Systems
<andy@ADS.com>
------------------------------
Date: Wed, 7 Dec 88 16:27:22 CST
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Message-Id: <8812072227.AA00515@uicbert.eecs.uic.edu>
Subject: R4RS changes? Code?
Several people (myself included) have posted requests for large
Scheme programs, with disappointing results. Apparently relatively few
people use Scheme for really serious development, and very few write
portable (e.g., R3RS) Scheme code.
I was wondering if this is likely to change over the next couple of
years, perhaps as a result of a more completely standardized language.
When is the R4RS likely to come out, and what is it likely to standardize?
Will a macro facility be standardized? Dynamic or fluid variables? These
seem to me to be the most important Lisp features not specified by
the R3RS. Is there a consensus growing as to how either of these should
be done, or is it too early to settle on a standard?
Whatever the answer is, what does it imply for the future of Scheme? Will
it be a "toy" language forever, like unextended Pascal? Or will it
eventually be a medium-sized language with a lot of available libraries,
like C? (And will it be a family of incompatible languages, like Pascal,
or take over the world, like C? :-).
Right now, I need to guess whether there will be sufficient programs
available within two years to gather performance data for some implementation
techniques. If not, I may have to go with another language for some of
the things I need to do, and that could be painful.
-- Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
------------------------------
Date: 8 Dec 88 02:58:39 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Subject: Re: R4RS changes? Code?
Message-Id: <3348@uoregon.uoregon.edu>
In article <8812072227.AA00515@uicbert.eecs.uic.edu> wilson@UICBERT.EECS.UIC.EDU (Paul Wilson) writes:
>Several people (myself included) have posted requests for large
>Scheme programs, with disappointing results. Apparently relatively few
>people use Scheme for really serious development, and very few write
>portable (e.g., R3RS) Scheme code.
I think you are right that relatively few of the people who use Scheme for
really serious development are writing portable Scheme code. On the
Macintosh, for example, "really serious" implies calling ROM routines
to achieve the Apple look and feel, which is hardly portable even with
all the high-level support provided by MacScheme+Toolsmith. It's not
portable in C, either. Some of the larger Scheme programs, like Edwin,
TI's Personal Consultant for the PC family, and various programs written
in T, are non-portable in part because they are rooted in systems that
antedate the RRRS, let alone the R3RS. I would imagine that they also
have to do a lot of inherently non-portable things with i/o.
>I was wondering if this is likely to change over the next couple of
>years, perhaps as a result of a more completely standardized language.
I think it will. Most of Scheme's popularity has been a result of the
Abelson & Sussman(s) book, which has prompted universities to use Scheme
in their introductory courses, often on an experimental basis. Universities
are only now beginning to accept Scheme as a language worthy of use in upper
division and graduate courses, and upper level textbooks that use Scheme are
only now being written. I expect the most significant publicly available
Scheme programs, some of them portable, will be written in the universities.
That's the way it is with other languages.
>When is the R4RS likely to come out, and what is it likely to standardize?
>Will a macro facility be standardized? Dynamic or fluid variables?...
>...Is there a consensus growing as to how either of these should
>be done, or is it too early to settle on a standard?
The R4RS will come out early next year. It will not standardize dynamic or
fluid variables, and I am skeptical that it will standardize macros. There
seems to be a fair consensus on macros, but the details aren't yet worked
out. There are technical problems concerning the interaction of dynamic
variables with multitasking and I don't expect them to be resolved anytime
soon.
A draft of the IEEE standard will be ready in February. This is probably
more important than the R4RS, on which it will be based.
>Whatever the answer is, what does it imply for the future of Scheme? Will
>it be a "toy" language forever, like unextended Pascal? Or will it
>eventually be a medium-sized language with a lot of available libraries,
>like C?
I think the availability of generally useful public code will soon be better
for Scheme than for unextended Pascal (if it isn't already). I doubt that
Scheme will ever approach C in the volume of generally available code, but
Scheme may be stronger than C in certain important areas such as numerical
software. It would be a waste to duplicate some C libraries, such as X, in
Scheme; better to let Scheme code call the C libraries.
>Right now, I need to guess whether there will be sufficient programs
>available within two years to gather performance data for some implementation
>techniques. If not, I may have to go with another language for some of
>the things I need to do, and that could be painful.
Though we've talked, I still don't have a good idea of the kind of programs
you're looking for. The main reason I haven't responded to your call for
programs is that I'm inclined to interpret a call for "large" programs as
a call for programs with more than 10,000 lines (at least) and I've never
written a standalone program that large in any single language.
Peace, Will
------------------------------
End of Scheme Digest
********************
∂08-Dec-88 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #28
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Dec 88 21:49:13 PST
Date: 9 DEC 88 00:06:40 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #28
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #28 9 DEC 88 00:06:40 EST
Today's Topics:
R4RS changes? Code?
why scheme?
----------------------------------------------------------------------
Date: 8 Dec 88 17:24:10 GMT
From: fenchurch!jbs@eddie.mit.edu (Jeff Siegal)
Subject: Re: R4RS changes? Code?
Message-Id: <10608@eddie.MIT.EDU>
In article <3348@uoregon.uoregon.edu> will@fog.UUCP (William Clinger) writes:
>I think you are right that relatively few of the people who use Scheme for
>really serious development are writing portable Scheme code. On the
>Macintosh, for example, "really serious" implies calling ROM routines
>to achieve the Apple look and feel, [...]
This is true in any language, but all "real" languages (Scheme
included) provide ways to package up these system dependencies to
allow easier retargeting of the code. However, this is quite
different from the non-standardization of actual language features
(e.g. dynamic bindings, macros, internal define's), which can require
converting the lots of code to transport a system.
I'm glad to hear there is at least a possibility of macros becoming
standard; the other features I can live without. On the other hand,
aren't dynamic bindings required for many of the interesting uses of
call/cc (i.e. catch and throw).
Jeff Siegal
------------------------------
Date: 8 Dec 88 21:34:16 GMT
From: mailrus!uflorida!haven!uvaarpa!hudson!vivaldi!pmy@ohio-state.arpa (Pete Yadlowsky)
Subject: why scheme?
Message-Id: <883@hudson.acc.virginia.edu>
Hello,
I was wondering if anyone would care to put in a nutshell what it is
that distinguishes scheme from other lisps, say, common lisp. I understand
that it's small and memory-efficient, but aside from that...?
Also, is anyone doing any object-oriented stuff with scheme? I currently
favor xlisp (for my Amiga), but I'm interested in looking into what
scheme has to offer, too. Thanks.
Peter M. Yadlowsky
Academic Computing Center
University of Virginia
pmy@vivaldi.acc.Virginia.EDU
------------------------------
End of Scheme Digest
********************
∂09-Dec-88 2146 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #29
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Dec 88 21:46:37 PST
Date: 10 DEC 88 00:06:50 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #29
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #29 10 DEC 88 00:06:50 EST
Today's Topics:
Scheme bibliography (few additions)
----------------------------------------------------------------------
Date: 8 Dec 88 06:44:32 GMT
From: clyde!watmath!utgpu!utzoo!yunexus!oz@bellcore.bellcore.com (Ozan Yigit)
Subject: Scheme bibliography (few additions)
Message-Id: <933@yunexus.UUCP>
Here are few additions to the scheme bibliography since the last
posting. I will do a complete re-post at an appropriate time. See
LISP POINTERS (Readings in Scheme column) for a printed version.
Keep them additions coming. (Thnx Kent!) [For example, I have not
yet been able to get the latest Lisp Conf. proceedings... Entries
from that conference would be most welcomed.] I have also received
some "abstracts", and I will post them with the biblio entries once
a critical mass is reached. (Hello Indiana ?? MIT ?? zzzttt...nnn..
can't... hear... you... :-)
Help save the scheme-literati: send me the biblio-details of those
obscure tech reports dusting(?) on your shelf... If it exists, and has
anything to do with Scheme, it ought to be in The (note the uppercase
T) Bibliography...
Notes: I think (this is a subjective opinion, based on actual
reading, and not a commercial :-) Kent's "Three implementation models
for Scheme" thesis is an excellent reading, especially for the
implementor. It describes the foundations of the `Chez' implementation.
I especially enjoyed the clean-and-concise exposition of the ideas
and algorithms.
Happy scheming... oz
---- snip ----
%A Uwe F. Pleban
%T The Standard Semantics of a Subset of SCHEME, a Dialect of LISP
%R Computer Science Technical Report TR-79-3
%I University of Kansas
%C Lawrence, Kansas
%D July 1979
%A Uwe F. Pleban
%T A Denotational Approach to Flow Analysis and Optimization of
SCHEME, A Dialect of LISP
%R Ph.D. Dissertation
%I University of Kansas
%C Lawrence, Kansas
%D 1980
%A Rex A. Dwyer
%A R. Kent Dybvig
%T A SCHEME for Distributed Processes
%R Computer Science Department Technical Report #107
%I Indiana University
%C Bloomington, Indiana
%D April 1981
%A R. Kent Dybvig
%T C-Scheme
%R Computer Science Department Technical Report #149 (MS Thesis)
%I Indiana University
%C Bloomington, Indiana
%D 1983
%A Richard Schooler
%A James W. Stamos
%T Proposal For a Small Scheme Implementation
%R MIT Lab for Computer Science Memo TM-267
%C Cambridge, Mass.
%D October 1984
%A R. Kent Dybvig
%A Bruce T. Smith
%T Chez Scheme Reference Manual Version 1.0
%I Cadence Research Systems
%C Bloomington, Indiana
%D May 1985
%A R. Kent Dybvig
%T Three Implementation Models for Scheme
%R Department of Computer Science Technical Report #87-011 (PhD Dissertation)
%I University of North Carolina at Chapel Hill
%C Chapel Hill, North Carolina
%D April 1987
%A R. Kent Dybvig
%A Robert Hieb
%T A Variable-Arity Procedural Interface
%J Proceedings of the 1988 ACM Symposium on LISP and Functional Programming
%C Salt Lake City, Utah
%D July 1988
%P 106-115
%O Also Indiana University Computer Science Department Technical Report #247
%A R. Kent Dybvig
%A Robert Hieb
%T Engines from Continuations
%R Computer Science Department Technical Report #254
%I Indiana University
%C Bloomington, Indiana
%D July 1988
%O Also to appear in Journal of Computer Languages
%A R. Kent Dybvig
%A Robert Hieb
%T Continuations and Concurrency
%R Computer Science Department Technical Report #256
%I Indiana University
%C Bloomington, Indiana
%D July 1988
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing Style: A General Macro Mechanism
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 53-76
%D June 1988
%A Olin Shivers
%T Control Flow Analysis in Scheme
%J Proceedings of the Sigplan 1988 Conference on Programming Language
Design and Implementation
%P 164-174
%C Atlanta, Georgia
%D June 1988
%K schflow
--------------------
--
You see things, and you say "WHY?" Usenet: oz@nexus.yorku.ca
But I dream things that never were; ......!uunet!utai!yunexus!oz
and say "WHY NOT?" Bitnet: oz@[yulibra|yuyetti]
[Back To Methuselah] Bernard Shaw Phonet: +1 416 736-5257x3976
------------------------------
End of Scheme Digest
********************
∂10-Dec-88 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #30
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Dec 88 21:40:47 PST
Date: 11 DEC 88 00:06:57 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #30
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #30 11 DEC 88 00:06:57 EST
Today's Topics:
Why does (eq? car car) ==> () in MacScheme?
Scheme bibliography
Why does (eq? car car) ==> () in MacScheme?
----------------------------------------------------------------------
Date: 10 Dec 88 08:04:19 GMT
From: tikal!sigma!uw-nsr!john@beaver.cs.washington.edu (John Sambrook)
Subject: Why does (eq? car car) ==> () in MacScheme?
Message-Id: <1440@uw-nsr.UUCP>
First, regarding the future of Scheme, I'd like to note that one of my
friends here at the University of Washington will be teaching a small
class of mechanical engineers (something) about software engineering.
He will be using Scheme, and not Fortran, which I guess was quite a
coup on his part.
At any rate, he and I were talking, and he commented that he had
discovered (though it is documented in the manual) that, in MacScheme
it is the case that (eq? car car) ==> (). I was suprised by this.
Could someone please explain what's going on here?
Thanks,
--
John Sambrook Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05 UUCP: uw-nsr!john
Seattle, Washington 98195 Dial: (206) 548-4386
------------------------------
Date: Sat, 10 Dec 88 09:32:43 est
From: gjc%bucsf.BU.EDU@bu-it.bu.edu (George J. Carrette)
Message-Id: <8812101432.AA18366@bucsf>
Subject: Scheme bibliography
I'm told there is something about a Scheme implementation in
the latest Usenix C++ procedings.
------------------------------
Date: 10 Dec 88 21:23:04 GMT
From: fenchurch!jbs@eddie.mit.edu (Jeff Siegal)
Subject: Re: Why does (eq? car car) ==> () in MacScheme?
Message-Id: <10634@eddie.MIT.EDU>
In article <1440@uw-nsr.UUCP> john@nsr.bioeng.washington.edu (John Sambrook 548-4386) writes:
>[...]in MacScheme
>it is the case that (eq? car car) ==> (). [...]
>Could someone please explain what's going on here?
I can guess at the following explanation:
In MacScheme, Scheme primitives are not really procedures, but when
you reference them, the compiler generates a procedure "wrapper" (i.e.
"car" becomes "(lambda (l) (car l))"
It does this each time the primitive is used as a value (so each "car"
refers to a different wrapper procedure).
This behavior is wrong according to R3RS (3/4 of the way into Sect 6.2)
Jeff Siegal
------------------------------
End of Scheme Digest
********************
∂12-Dec-88 2121 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #31
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Dec 88 21:20:54 PST
Date: 13 DEC 88 00:07:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #31
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #31 13 DEC 88 00:07:37 EST
Today's Topics:
Lisp Pointers
----------------------------------------------------------------------
Date: Mon, 12 Dec 88 08:39:35 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8812121639.AA24087@sesame.stanford.edu>
Subject: Lisp Pointers
Can someone tell me how to get on the Lisp Pointers mailing list? Please
respond by email and I will post the answer to the group.
Morry Katz
katz@polya.stanford.edu
------------------------------
End of Scheme Digest
********************
∂13-Dec-88 2220 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #32
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 22:20:30 PST
Date: 14 DEC 88 00:07:58 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #32
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #32 14 DEC 88 00:07:58 EST
Today's Topics:
Scheme's emacs interface vs. SunOS 4.0
IEEE Scheme Standard Meeting
----------------------------------------------------------------------
Date: 13 Dec 88 19:13:47 GMT
From: dartvax!griggs.dartmouth.edu!hugo@bu-cs.bu.edu
Subject: Scheme's emacs interface vs. SunOS 4.0
Message-Id: <11451@dartvax.Dartmouth.EDU>
Hi,
I just picked up C scheme and got it running, and have been fooling
with the Emacs interface. I'm running on a Sun/3 with SunOS4.0 and it
all seems to work except that the scheme process ignores all the
interrupt characters that I send it. Does anyone have this working?
Thanks,
Pete
------------------------------
Date: Tue, 13 Dec 88 17:29:32 EST
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: IEEE Scheme Standard Meeting
The second meeting of the IEEE Working Group on Scheme will be Friday,
February 3rd, from 9am to 5pm at MIT. The primary agenda item is
review of a standard draft being prepared by editors appointed at the
last meeting. Those interested in attending should contact the Chair
at the address below. Details of local arrangements will be provided
when available to those who express interest.
Christopher Haynes
Mail: Lindley Hall, Indiana Universiy, Bloomington, IN 47405
Internet: chaynes@iuvax.cs.indiana.edu
Telephone: 812-855-6486
------------------------------
End of Scheme Digest
********************
∂14-Dec-88 2123 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #33
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 21:23:39 PST
Date: 15 DEC 88 00:08:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #33
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #33 15 DEC 88 00:08:33 EST
Today's Topics:
Scheme's emacs interface vs. SunOS 4.0
R4RS changes? Code?
R4RS changes? Code?
Lisp Pointers
----------------------------------------------------------------------
Date: Wed, 14 Dec 88 04:56:16 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8812140956.AA09489@kleph.ai.mit.edu>
Subject: Scheme's emacs interface vs. SunOS 4.0
Reply-To: cph@zurich.ai.mit.edu
[Please let me remind everyone that the correct place to send bug
reports for MIT C Scheme is "bug-cscheme@zurich.ai.mit.edu", NOT this
mailing list. If you are getting this via usenet news, there is now a
C Scheme newsgroup (I believe it's called "net.lang.scheme.c") which
should be used for topics specific to the MIT implementation.]
Date: 13 Dec 88 19:13:47 GMT
From: dartvax!griggs.dartmouth.edu!hugo@bu-cs.bu.edu
I just picked up C scheme and got it running, and have been fooling
with the Emacs interface. I'm running on a Sun/3 with SunOS4.0 and it
all seems to work except that the scheme process ignores all the
interrupt characters that I send it. Does anyone have this working?
This has been fixed, but not yet distributed (we've been running full
bore getting the compiler up to scratch). Anyone who would like the
changes should send mail to "bug-cscheme@zurich.ai.mit.edu" requesting
to get them. Along with the request, please send the release number
of your copy of Scheme, as the specifics of the changes depend on it;
e.g. the number "7.1.1" in the following header:
Scheme saved on Tuesday December 13, 1988 at 7:05:56 PM
Release 7.1.1
Microcode 10.64
Runtime 14.30
SF 4.7
I'd prefer to distribute by anonymous ftp, but the changes can be
mailed if needed.
------------------------------
Date: 12 Dec 88 20:31:00 GMT
From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: Re: R4RS changes? Code?
Message-Id: <82000005@uicbert.eecs.uic.edu>
With regard to standardization, I would think it would be possible
to standardize a rather underspecified version of a macro facility,
without specifying things like scope rules. In that way, careful
programmers could use basic macros in a portable way, so that their
programs could run in varying Schemes, and be compatible with an
eventual more detailed specification; e.g., if all of your macros
have unique names, you don't have to worry about name collision
resolution details.
(This would be akin to programmers who write programs
that don't rely on dynamic or static scoping, so that
they run the same way with a dynamically-scoped interpreter and a
lexically-scoped compiler. While it's not the best situation, it's
better than not being able to use a macros (or a compiler).)
Or is this considered a path to perdition, with people writing
code that they think is portable but isn't, because of accidental
implementation dependencies? Standardization of noncontroversial
aspects of features is just one step down the slippery slope from
fully specified standard features, but it seems a particularly
attractive step to me. A small commitment to a core functionality
of macros and dynamic/fluid variables could come in very handy in
the short run, and still allow a fuller, more righteous specification
the next time around.
-- Paul
Paul R. Wilson
Electronic Mind Control* Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680 *a.k.a. Human-Computer Interaction
------------------------------
Date: 12 Dec 88 20:38:00 GMT
From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu
Subject: Re: R4RS changes? Code?
Message-Id: <82000006@uicbert.eecs.uic.edu>
On the subject of the portable code I'm looking for:
I don't know about others who are looking, but I'm looking for
programs that allocate at least one megabyte of memory during a
run, and preferably ten or more. I'd really like programs that
actually have a megabyte or more of data that is *live* at one
time. I'm especially interested in programs that run for several
minutes or more on a serious workstation (compiled). This is
for gathering locality statistics and data survival curves.
Bob Shaw's recentPh.D. dissertation at stanford reported some similar
statistics for four large Common Lisp programs. His programs were
the Reduce symbolic math package, a natural language understanding
program, a Common Lisp compiler (Hewlett-Packard's) compiling
itself, and the RSIM circuit simulator.
I would be very interested in similar programs written in
portable Scheme. Eventually I may take on porting some programs
if they don't use too many incompatible extensions, but I'd
rather not have to.
I am interested in getting a variety of programs that are
large and/or long-running, with a preference for things that
people could actually use, rather than throwaway prototypes. For
example, an implementation of OPS5 that actually uses the
RETE matching algorithm would be excellent. Non-AI "plain old
programs" that do something useful would be particularly good,
since I'm looking for data that generalize beyond AI applications.
Interactive programs would be particularly nice, if they use ASCII-
only interactions (so that I can hack up a script facility to repeatedly
run them offline).
(The reason for all this is to gather statistics that will
guide the design of generation-based garbage collectors,
virtual memories, and copy-on-write virtual copy mechanisms
for checkpointing and side-effect isolation. I'm implementing
a generational garbage collector for Scheme-48, and it will
be instrumented to gather the relevant statistics. Of
course, we'll have to scale our results to compensate for
the slowness of the bytecoded Scheme-48 interpreter. A bigger
problem is the availability of reasonable test programs --
that may require more work in porting than is involved in
implementing the gc itself.
I may have to implement the instrumented gc for something hairier,
like Kyoto Common Lisp or T, to gather data on larger programs.
The Scheme-48 version should still be valuable, because it could
be more easily extended for simulating parallel systems, etc.)
-- Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680
------------------------------
Date: Wed, 14 Dec 88 09:17:33 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8812141717.AA25855@sesame.stanford.edu>
Subject: Re: Lisp Pointers
The best information I got on Lisp Pointers is as follows:
| The latest issue of Lisp Pointers says the following:
|| Free Subscription to Lisp Pointers (postal mail only)
||
|| LISP POINTERS
|| Mary S. Van Deusen, Editor
|| IBM Watson Research
|| PO Box 704
|| Yorktown Heights, NY 10598
| Alternatively, you can mail Mary Van Deusen direct at maida@ibm.com
Morry Katz
katz@polya.stanford.edu
------------------------------
End of Scheme Digest
********************
∂15-Dec-88 2143 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #34
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 21:43:29 PST
Date: 16 DEC 88 00:08:55 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #34
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #34 16 DEC 88 00:08:55 EST
Today's Topics:
Y, again (long)
Lisp Pointers
Y, again (long)
----------------------------------------------------------------------
Date: Thu, 15 Dec 88 09:47:30 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8812151447.AA06672@chamartin.ai.mit.edu>
Subject: Y, again (long)
Reply-To: jinx@zurich.ai.mit.edu
The recent flurry of messages about the Y operator has prompted me to
spend yet a little more time on the MIT Scheme compiler. The most
recent version (4.33) does a good job on some versions of the Y
operator, but not on all. This message should clarify what it can
currently do and what it cannot.
I should point out that there is no explicit "Y-recognizer" in the
compiler, but rather the results are a consequence of various of its
parts:
- value analysis (which values can reach what variables). In
particular, a variable's value is "known" if only one value can reach
it.
- closure analysis (which lambda expressions need to be represented
by actual objects at run time, instead of having an implicit
representation in the code stream)
- a limited side effect analysis which allows the compiler to "punt"
some calls when the callee has no side effects and the value returned
is unused or known and available at the call point. This is the piece
of code that I've written recently to make the examples below "work".
Some of my thoughts about the points raised in recent messages:
As far as using some version of Y to implement LETREC, we could
probably start doing it and users would hardly ever notice the
difference, but aside from conceptual elegance nothing would be
gained, so it's not really worth it in a "real" compiler.
Why have I spent any energy getting the Y operator to "work"? From a
compiler writer's point of view, I'm not interested in the Y operator
per-se, except as a "cute" hack. It just happens to be a very good
test case for value and closure analysis, and if the compiler can do a
good job on code that uses it, it will hopefully also do a good job on
the "simpler" cases that occur in practice.
About eq?/eqv?-ness of procedures, I should say that the only time we
may need to distinguish multiple procedures whose "code" is the same
lambda expression is when they can coexist in time, and free variables
can cause the different instances to behave differently (return
different values and/or perform different effects). Clearly, any
correct compiler cannot "merge" two such instances. The rest of the
cases are for philosophers to argue about. To make them happy,
compiler writers may have to provide a "pedantic" switch in the
compiler to prevent merging of otherwise identical procedures. I'm
not saying that determining when two procedures "act the same way" is
feasible (we all know about the halting theorem), but if we are able
to determine in some instance that the only thing that could
discriminate between two procedures is eq?/eqv?, there is really no
reason not to merge.
Here are some examples of what the MIT Scheme compiler can currently do:
The following versions of factorial turn into identical (bitwise) code:
;; version 1, using letrec. reference version
(define fact
(letrec ((fact (lambda (n)
(if (= n 0)
1
(* n (fact (- n 1)))))))
fact))
;; version 2, "subroutinized" "standard" applicative order
(define fact
((lambda (f)
(let ((g (lambda (g) (f (lambda () (g g))))))
(g g)))
(lambda (fg)
(lambda (n)
(if (= n 0)
1
(* n ((fg) (- n 1))))))))
;; version 3, "standard" normal order
(define fact
((lambda (f)
((lambda (g) (f (g g)))
(lambda (g) (f (g g)))))
(lambda (fact)
(lambda (n)
(if (= n 0)
1
(* n (fact (- n 1))))))))
Note that version 3 "has no right to work" in Scheme, but I've never
found anything wrong with compilers that "fix" users' code.
The following two versions turn into code essentially identical to the
code generated for the versions above, with the differences described
below.
;; version 4, another "subroutinized" "standard" applicative order
(define fact
((lambda (f)
(let ((g (lambda (g) (f (lambda (x) ((g g) x))))))
(g g)))
(lambda (fact)
(lambda (n)
(if (= n 0)
1
(* n (fact (- n 1))))))))
;; version 5, "inline coded" Y
(define fact
(let ((kernel
(lambda (p n)
(if (= n 0)
1
(* n (p p (- n 1)))))))
(lambda (n)
(kernel kernel n))))
The code generated for version 4 differs from the code in versions 1-3
only in the order in which the basic blocks appear in the linearized
output.
The code for version 5 differs because the compiler is currently not
smart enough to eta convert (lambda (n) ...) into (lambda (p n) ...)
after it determines that p in (lambda (p n) ...) is used for "self
reference" and unneeded (and dropped). Thus there is an initial call
(branch instruction) from the code generated for (lambda (n) ...) to
the code generated for (lambda (p n) ...), but the actual "recursive"
procedure is coded identically to the other cases above.
As an example of a hairier case where the compiler "wins", it
generates identical code for
(define (delq! item items)
(letrec ((trim-initial-segment
(lambda (items)
(if (pair? items)
(if (eq? item (car items))
(trim-initial-segment (cdr items))
(begin (locate-initial-segment items (cdr items))
items))
items)))
(locate-initial-segment
(lambda (last this)
(if (pair? this)
(if (eq? item (car this))
(set-cdr! last (trim-initial-segment (cdr this)))
(locate-initial-segment this (cdr this)))
this))))
(trim-initial-segment items)))
and
(define delq!
(lambda (item items)
(((lambda (b f g)
((lambda (k1 k2)
(b (lambda () (k1 k1 k2))
(lambda () (k2 k1 k2))))
(lambda (k1 k2)
(f (lambda () (k1 k1 k2))
(lambda () (k2 k1 k2))))
(lambda (k1 k2)
(g (lambda () (k1 k1 k2))
(lambda () (k2 k1 k2))))))
(lambda (p1g p2g)
(lambda ()
((p1g) items)))
(lambda (p11g p12g)
(lambda (items)
(if (pair? items)
(if (eq? item (car items))
((p11g) (cdr items))
(begin ((p12g) items (cdr items))
items))
items)))
(lambda (p21g p22g)
(lambda (last this)
(if (pair? this)
(if (eq? item (car this))
(set-cdr! last ((p21g) (cdr this)))
((p22g) this (cdr this)))
this)))))))
Examples where the compiler "loses":
;; version 6 "non-subroutinized" "standard" applicative order
(define fact
((lambda (f)
((lambda (g) (f (lambda () (g g))))
(lambda (g) (f (lambda () (g g))))))
(lambda (fg)
(lambda (n)
(if (= n 0)
1
(* n ((fg) (- n 1))))))))
;; version 7 another "non-subroutinized" "standard" applicative order
(define fact
((lambda (f)
((lambda (g) (f (lambda (x) ((g g) x))))
(lambda (g) (f (lambda (x) ((g g) x))))))
(lambda (fact)
(lambda (n)
(if (= n 0)
1
(* n (fact (- n 1))))))))
Version 6 does not win because the compiler is not smart enough to
realize that both copies of (lambda () (g g)) are indistinguishable.
This causes (lambda (n) ...) to be represented as a closure (with one
free variable, namely fg), and even though the compiler realizes that
the call (fg) always returns a version of (lambda (n) ...) and
therefore codes the call as a direct branch, there is still overhead
associated with the closure and computing its "next" version (which
will be unused).
Version 7 does not win for a similar reason. Again, the compiler does
not realize that both copies of (lambda (x) ...) are identical and
therefore causes (lambda (n) ...) to be closed over fact. Both calls
((g g) x) are known to be calls to (lambda (n) ...), and are
translated as direct branches after computing the "next" (useless)
closure for (lambda (n) ...)
There are many other cases where it will lose due to the
"non-uniqueness" of the values which may reach individual variables.
An altogether different reason why it may lose is the fact that once a
closure is detected, a "pessimistic" code generation strategy is used
which forces some of the "useless" procedures and overhead to
reappear.
------------------------------
Date: 14 Dec 88 14:27:02 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Subject: Re: Lisp Pointers
Message-Id: <937@yunexus.UUCP>
In article <8812121639.AA24087@sesame.stanford.edu> mkatz@SESAME.STANFORD.EDU (Morris Katz) writes:
>Can someone tell me how to get on the Lisp Pointers mailing list?
Send mail to maida@ibm.com (Mary Van Deusen). Alternatively, send surface
mail to
Mary S. Van Deusen
IBM Watson Research Center
PO Box 704
Yorktown Heights, NY 10598
Phone: IBM: (914) 789 7845
oz
------------------------------
Date: 15 Dec 88 20:16:05 GMT
From: polya!max@labrea.stanford.edu (Max Hailperin)
Subject: Re: Y, again (long)
Message-Id: <5684@polya.Stanford.EDU>
I think I may have just been tarred as a philospher or as pedantic --
ouch! So let me try to clarify what I see to be some of the more
substantive issues:
1) I didn't mean to imply that Rozas's compiler actually has a Y
recognizer; my point was merely that it wasn't surprising that it
could do those things a Y recognizer could. The question is, how
does it hold up in more difficult cases? One case I'd very much
like Rozas to compare the generated code for is Y itself, *not
applied to anything*. E.g., how similar/different is the code for
these two procedures:
(define (Y1 f)
(let ((g (lambda (g)
(f (lambda (x) ((g g) x))))))
(g g)))
(define (Y2 f)
(letrec ((y-of-f (f (lambda (x) (y-of-f x)))))
y-of-f))
2) I wasn't weighing the possibility of a compiler defining letrec in
terms of Y, I was weighing the possibility of the language standard
defining letrec in terms of Y. While users of Rozas's compiler
would notice no difference if he were to do so, users of other less
optimizing compilers would notice a difference, namely in
"self"-eqvness. The issue isn't excess eqvnes, either, as Rozas
seems to think, but rather insufficient eqvness. As long as scheme
supports procedural objects with identities, letrec will have to
remain defined in terms of set! rather than Y.
------------------------------
End of Scheme Digest
********************
∂16-Dec-88 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #35
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 21:51:53 PST
Date: 17 DEC 88 00:09:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #35
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #35 17 DEC 88 00:09:37 EST
Today's Topics:
Y, again (long)
Compiler analysis
Compiler analysis
----------------------------------------------------------------------
Date: 16 Dec 88 18:27:47 GMT
From: leto!matthias@rice.edu (Matthias Felleisen)
Subject: Re: Y, again (long)
Message-Id: <2356@kalliope.rice.edu>
In article <5684@polya.Stanford.EDU> mxh@sumex-aim.Stanford.EDU (Max Hailperin) writes:
>2) I wasn't weighing the possibility of a compiler defining letrec in
> terms of Y, I was weighing the possibility of the language standard
> defining letrec in terms of Y. While users of Rozas's compiler
> would notice no difference if he were to do so, users of other less
> optimizing compilers would notice a difference, namely in
> "self"-eqvness. The issue isn't excess eqvnes, either, as Rozas
> seems to think, but rather insufficient eqvness. As long as scheme
> supports procedural objects with identities, letrec will have to
> remain defined in terms of set! rather than Y.
It is not the R↑nRS-specification of eqv? [pp13-14] that requires
(letrec ([f (lambda (x) (eqv? f f))]) (f 0))
to yield #t but the expansion-specification of letrec [p35]. If we
changed the letrec-specification, the compiler could return any
arbitrary value [recall: eqv? is an approximation of operational
equivalence].
But efficiency is not really the important issue. The assignability of
function variables, in particular for recursive functions, requires
the current letrec-specification. The importance of this cannot be
overemphasized. Dan Friedman and I have shown how to use this trick
for define-by-need and import-by-need in a module environment, and Dan
and John Franco have recently written up a tech rpt on stream
techniques that use this trick.
-- Matthias
------------------------------
Date: Fri, 16 Dec 88 14:38:34 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8812162238.AA27888@sesame.stanford.edu>
Subject: Compiler analysis
In order to yield better performance for my parallelization system, I am trying
to derive an algorithm for ddetermining which calls to cons, make-vector, etc.
generate objects which are guaranteed not to be mutated anywhere in a program.
Any ideas on this subject or references to related literature would be greatly
appreciated. It seems that this poroblem is much more difficult than one might
suspect. It gets even worse if one wants to do things like determine that the
objects returned by recursive calls of a procedure are immutable, but those
returned to the original call are mutable. This form of analysis seems
necessary if one wants to actually identify a significant number of sites where
immutable objects are created.
Thanks in advance for the help,
Morry Katz
katz@polya.stanford.edu
------------------------------
Date: 16 Dec 88 22:38:34 GMT
From: SESAME.STANFORD.EDU!mkatz@bloom-beacon.mit.edu (Morris Katz)
Subject: Compiler analysis
Message-Id: <8812162238.AA27888@sesame.stanford.edu>
In order to yield better performance for my parallelization system, I am trying
to derive an algorithm for ddetermining which calls to cons, make-vector, etc.
generate objects which are guaranteed not to be mutated anywhere in a program.
Any ideas on this subject or references to related literature would be greatly
appreciated. It seems that this poroblem is much more difficult than one might
suspect. It gets even worse if one wants to do things like determine that the
objects returned by recursive calls of a procedure are immutable, but those
returned to the original call are mutable. This form of analysis seems
necessary if one wants to actually identify a significant number of sites where
immutable objects are created.
Thanks in advance for the help,
Morry Katz
katz@polya.stanford.edu
------------------------------
End of Scheme Digest
********************
∂17-Dec-88 2116 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #36
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Dec 88 21:16:23 PST
Date: 18 DEC 88 00:09:41 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #36
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #36 18 DEC 88 00:09:41 EST
Today's Topics:
Y, again (long)
----------------------------------------------------------------------
Date: 16 Dec 88 20:33:04 GMT
From: texbell!killer!pollux!ti-csl!m2!gateley@bellcore.bellcore.com (John Gateley)
Subject: Re: Y, again (long)
Message-Id: <65837@ti-csl.CSNET>
In article <8812151447.AA06672@chamartin.ai.mit.edu> jinx@zurich.ai.mit.edu writes:
<[Lots of stuff about Y]
<;; version 3, "standard" normal order
<
<(define fact
< ((lambda (f)
< ((lambda (g) (f (g g)))
< (lambda (g) (f (g g)))))
< (lambda (fact)
< (lambda (n)
< (if (= n 0)
< 1
< (* n (fact (- n 1))))))))
<
<Note that version 3 "has no right to work" in Scheme, but I've never
<found anything wrong with compilers that "fix" users' code.
If I understand correctly, then you are saying that this terminates (and
produces a factorial function) with your compiler. This is quite
interesting! Does the compiler eliminate infinite loops all the time?
Or is it just when the loop terminates in normal order, but not in
applicative order? Has anybody complained because the compiler took
their loop out?
What about the semantics: Does Scheme require infinite loops to be generated?
John
gateley@tilde.csc.ti.com
------------------------------
End of Scheme Digest
********************
∂19-Dec-88 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #37
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 21:20:27 PST
Date: 20 DEC 88 00:10:45 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #37
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #37 20 DEC 88 00:10:45 EST
Today's Topics:
Compiler analysis
----------------------------------------------------------------------
Date: 19 Dec 88 16:51:11 GMT
From: dor@lanl.gov (David Rich)
Subject: Re: Compiler analysis
Message-Id: <7315@lanl.gov>
In article <8812162238.AA27888@sesame.stanford.edu>, mkatz@SESAME.STANFORD.EDU (Morris Katz) writes:
> In order to yield better performance for my parallelization system, I am trying
> to derive an algorithm for ddetermining which calls to cons, make-vector, etc.
> generate objects which are guaranteed not to be mutated anywhere in a program.
> Any ideas on this subject or references to related literature would be greatly
> appreciated...
Well, here's a start:
%A Adrienne Bloss
%A Paul Hudak
%A Jonathan Young
%T Code Optimizations For Lazy Evaluation
%R Draft
%I CSD, Yale UNIV
%C New Haven, CT
%D 1988
Also, Adrienne's PhD dissertation is a good reference (it predates this
one I believe) -- most likely available as a technical report from Yale.
She uses a technique called "Path Analysis" (a form of abstract interpretation)
to determine when destructive updates are possible. However, if I remember
correctly, her work deals mainly with first order languages and serial evaluation.
Hope this helps!
--Dave
------------------------------
End of Scheme Digest
********************
∂22-Dec-88 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #38
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 21:42:43 PST
Date: 23 DEC 88 00:12:09 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #38
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #38 23 DEC 88 00:12:09 EST
Today's Topics:
Scheme on a PC
Why is (eq? car car) false in MacScheme
----------------------------------------------------------------------
Date: 22 Dec 88 00:45:34 GMT
From: kevin@csvax.caltech.edu (Kevin S. Van Horn)
Subject: Scheme on a PC
Message-Id: <8953@cit-vax.Caltech.Edu>
Does anyone know where I can get an implementation of Scheme on a
PC-compatible? Please send e-mail.
Kevin S. Van Horn
kevin@cit-adel.caltech.edu
------------------------------
Date: 23 Dec 88 00:39:48 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Subject: Re: Why is (eq? car car) false in MacScheme
Message-Id: <3422@uoregon.uoregon.edu>
In article <10702@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes:
>Does anyone know the real answer?
In MacScheme a reference to CAR that is not in operator position will be
compiled as though it were (LAMBDA (X) (CAR X)). This is true of certain
other integrable procedures as well. Several years ago, before EQ? was
specified to do anything in particular with procedures as arguments, and
before you could buy a Macintosh with more than 128K of RAM, a measurement
and calculation showed that creating full-fledged procedures for these
integrable procedures only when needed would tend to save a few bytes of
space.
Fixing this bug has not been a high priority. If it were the most serious
bug in MacScheme I would be extremely happy.
Peace, William Clinger
------------------------------
End of Scheme Digest
********************
∂24-Dec-88 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #39
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Dec 88 21:17:40 PST
Date: 25 DEC 88 00:13:04 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #39
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #39 25 DEC 88 00:13:04 EST
Today's Topics:
Help with Cscheme
----------------------------------------------------------------------
Date: 24 Dec 88 05:50:25 GMT
From: oliveb!olivej!frankc@ames.arpa (Frank Crowell)
Subject: Help with Cscheme
Message-Id: <34873@oliveb.olivetti.com>
I need help invoking emacs for Cscheme 6.1.1 and 6.1.2; I have built
the runtime and microcode, but I can't seem to be able to access
emacs although emacs.bin was loaded into the runtime.
What is going on?
------------------------------
End of Scheme Digest
********************
∂30-Dec-88 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #40
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Dec 88 21:49:02 PST
Date: 31 DEC 88 00:14:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #40
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #40 31 DEC 88 00:14:33 EST
Today's Topics:
Scheme on a PC
Scheme on a PC
Oaklisp Release
----------------------------------------------------------------------
Date: 29 Dec 88 21:28:16 GMT
From: decvax!zinn!mipsmag!dbetz@bloom-beacon.mit.edu (David Betz)
Subject: Re: Scheme on a PC
Message-Id: <572@mipsmag.UUCP>
If you're looking for a simple implementation of Scheme for the IBM-PC
(or the Mac or the Atari-ST or the Amiga ...), you could try XScheme.
It is an implementation of Scheme written in C. It consists of a bytecode
compiler and a virtual machine to execute the bytecodes.
David Betz
MIPS Magazine
(603) 882-1232
------------------------------
Date: 30 Dec 88 13:23:51 GMT
From: imagine!pawl3.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam)
Subject: Re: Scheme on a PC
Message-Id: <2215@imagine.PAWL.RPI.EDU>
In article <572@mipsmag.UUCP> dbetz@mipsmag.UUCP (David Betz) writes:
>If you're looking for a simple implementation of Scheme for the IBM-PC
>(or the Mac or the Atari-ST or the Amiga ...), you could try XScheme.
>It is an implementation of Scheme written in C. It consists of a bytecode
>compiler and a virtual machine to execute the bytecodes.
> David Betz
Ok, ill bite. Where can i find XScheme? Preferably by anonymous ftp?
Any graphics support? Can i end another sentence in a question mark?
I would like to find a R3RS compliant scheme that is free (or near to it)
that i can provide for student use in a course ill be teaching. Scheme
will not be required, but id like to provide an alternative to Fortran
(ick).
jeff putnam -- "Sometimes one must attempt the impossible if only to
jefu@pawl.rpi.edu -- show it is merely inadvisable."
------------------------------
Date: 30 Dec 1988 14:52-EST
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
Subject: Oaklisp Release
Message-Id: <Fri.Dec.30.14:52:00.1988/bap@F.GP.CS.CMU.EDU>
A new release of Oaklisp is available. There are some tiny bug fixes,
the emulator should compile properly on machines with 16 bit int C
compilers, and bignums, complexes and rationals are fully supported. No
flonums, but you can fake them with rationals. The bignums are
surprisingly fast, about a factor of 6 slower than T 3.1 at naive
factorial of 100. An O((log n)↑1.59) algorithm is used for multiplying
pairs of really large integers. Not O(log n) Schonhage-Strassen, but at
least it's not O((log n)↑2).
The distribution can be FTPed from host DOGHEN.BOLTZ.CS.CMU.EDU (aka
128.2.222.37), user "anonymous", file "oak/release.tar.Z". Be sure to
use binary mode.
Bug fixes and reports are appreciated, particularly with regard to
portability to odd architectures. A 36 or 48 bit word port would be
nice. Requests for tapes from people without FTP will be denied.
Oaklisp is unsupported, but we do consult.
------------------------------
End of Scheme Digest
********************
∂01-Jan-89 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #41
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Jan 89 21:47:41 PST
Date: 2 JAN 89 00:15:05 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #41
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #41 2 JAN 89 00:15:05 EST
Today's Topics:
Oaklisp release problem
Scheme on a PC
----------------------------------------------------------------------
Date: 1 Jan 1989 14:30-EST
From: Barak.Pearlmutter@F.GP.CS.CMU.EDU
Subject: Oaklisp release problem
Message-Id: <Sun.Jan.1.14:30:05.1989/bap@F.GP.CS.CMU.EDU>
Some source files were inadvertently omitted from the Oaklisp
distribution tar file. These problems should be corrected as of noon on
Monday Jan 2. I apologize to those who were inconvenienced by this
problem.
If you FTPed the distribution already and just want some particular
files, you should be able to find them in oak/src/release/mac/, which is
publically accessible.
Below I repeat the original announcement, for your FTP convenience. Oh,
and watch the symbolic links. "CD ~" will get you back to the ftp guest
home directory.
------
A new release of Oaklisp is available. There are some tiny bug fixes,
the emulator should compile properly on machines with 16 bit int C
compilers, and bignums, complexes and rationals are fully supported. No
flonums, but you can fake them with rationals. The bignums are
surprisingly fast, about a factor of 6 slower than T 3.1 at naive
factorial of 100. An O((log n)↑1.59) algorithm is used for multiplying
pairs of really large integers. Not O(log n) Schonhage-Strassen, but at
least it's not O((log n)↑2).
The distribution can be FTPed from host DOGHEN.BOLTZ.CS.CMU.EDU (aka
128.2.222.37), user "anonymous", file "oak/release.tar.Z". Be sure to
use binary mode.
Bug fixes and reports are appreciated, particularly with regard to
portability to odd architectures. A 36 or 48 bit word port would be
nice. Requests for tapes from people without FTP will be denied.
Oaklisp is unsupported, but Kevin and I will consult.
------------------------------
Date: 1 Jan 89 19:14:12 GMT
From: decvax!zinn!mipsmag!dbetz@bloom-beacon.mit.edu (David Betz)
Subject: Re: Scheme on a PC
Message-Id: <573@mipsmag.UUCP>
Right now, the way to get XScheme (for IBM-PC compatibles and the Macintosh)
is to send me a formatted disk (5.25 for the IBM-PC, 800K for the Macintosh)
and a STAMPED, self-addressed return mailer. My address is:
David Betz
127 Taylor Road
Peterborough, NH 03458
I'm working on making XScheme available through ftp from a machine at MIT.
I'll post a note here once that is setup.
David Betz
------------------------------
End of Scheme Digest
********************
∂03-Jan-89 2110 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #42
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 21:10:05 PST
Date: 4 JAN 89 00:00:18 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #42
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #42 4 JAN 89 00:00:18 EST
Today's Topics:
semantics of unwind-protect
----------------------------------------------------------------------
Date: 2 Jan 89 13:25:47 GMT
From: mcvax!inria!geocub!casteran@uunet.uu.net (Pierre Casteran)
Subject: semantics of unwind-protect
Message-Id: <489@geocub.UUCP>
I am looking for a precise definition of constructs like UNWIND-PROTECT,
or DYNAMIC-WIND, and so-on.
the best form would be :
a denotational definition (like in R3RS)
or an equivalent written in terms of CALL/CC or the Felleisen & Friedman's
"F" construct,
or a CPS translator.
Pierre Cast\'eran.
Universit\'e Bordeaux I (*)
Unit\'e de Recherche Associ\'ee au Centre National de la
Recherche Scientifique n. 726 (labri)
(*) Bordeaux is a city where you can find wines and Schemists
------------------------------
End of Scheme Digest
********************
∂04-Jan-89 2112 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #43
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 21:12:04 PST
Date: 5 JAN 89 00:00:51 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #43
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #43 5 JAN 89 00:00:51 EST
Today's Topics:
Scheme environments
----------------------------------------------------------------------
Date: 4 Jan 89 14:56:16 GMT
From: mit-vax!josh@bloom-beacon.mit.edu (Joshua Marantz)
Subject: Scheme environments
Message-Id: <5405@mit-vax.LCS.MIT.EDU>
I haven't used scheme for a while, but I just read the Revised(3.5)
Report on the Algorithmic Language Scheme. Some interesting things
have been added (or at least documented) since I last worked with
scheme in 1983. But one function that appears to be missing from the
spec is (eval expression environment). In particular, environments
are not explicitly discussed, though they are lurking in the
background of section 3.1.
I wanted to use environments to implement namespace hierarchies. I
faintly remember that scheme used to support the notion of a
"package", but I could not find it in any of my old documentation.
Has this been removed? Or have these things been left out of the spec
to allow different scheme implementations to define their own way of
dealing with these concepts? MIT C-Scheme has an eval function that
takes the expected arguments, but I couldn't find any relevant
documentation beyond the revised report.
-Joshua Marantz
Viewlogic Systems, Inc.
------------------------------
End of Scheme Digest
********************
∂06-Jan-89 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #44
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:19:55 PST
Date: 7 JAN 89 00:01:34 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #44
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #44 7 JAN 89 00:01:34 EST
Today's Topics:
Scheme on a PC
top-level vs internal DEFINE's
----------------------------------------------------------------------
Date: Fri, 6 Jan 89 16:29:40 +0100
From: Oliver Laumann <net%TUB.BITNET@MITVMA.MIT.EDU>
Message-Id: <8901061529.AA12071@tub.UUCP>
Subject: Re: Scheme on a PC
> I would like to find a R3RS compliant scheme that is free (or near to it)
> that i can provide for student use in a course ill be teaching. Scheme
> will not be required, but id like to provide an alternative to Fortran
I'm soon going to publish the sources of a R3RS compliant Scheme
interpreter written in C; it should be easily portable to Atari-
or Amiga-type machines. The distribution contains an interface to
both the Xlib and the X toolkit (Xt) which allows Scheme programmers
to make use of Xt widgets. The functionality of the Xlib interface
is similar to that of CLX.
However, the interface to the X Window System is a prototype and currently
undocumented (if you don't count demonstration programs as documentation).
Regards,
--
Oliver Laumann net@TUB.BITNET net@tub.UUCP
------------------------------
Date: 6 Jan 89 18:14:58 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: top-level vs internal DEFINE's
Message-Id: <47045@yale-celray.yale.UUCP>
What is the reason for Scheme's handling DEFINE differently at top level and
non-top-level?? According to R3RS, they are specifically different things:
top level DEFINEs are equivalent to SET! (with a binding if needed) and
internal DEFINEs are local to the body they're in.
I have a few objections to this:
(1) Internal DEFINE's add no power to the language: according to
R3RS "A <body> containing internal definitions can always be
converted to a completely equivalent LETREC expression."
(2) It is very useful to be able to DEFINE global functions that
are within the scope of a LET (or another function I suppose).
(3) It makes the semantics of the DEFINE expression vary by its
position in the code, which seems inherently wrong.
I'm sure this has been discussed before and there must be reasons for the
decision made in R3RS. What are the advantages of the R3RS decision??
If people send me mail I'll summarize to the net. That may keep down
redundant messages.
Bruce Krulwich
------------------------------
End of Scheme Digest
********************
∂09-Jan-89 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #45
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 21:14:14 PST
Date: 10 JAN 89 00:03:08 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #45
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #45 10 JAN 89 00:03:08 EST
Today's Topics:
help with CScheme on 386ix
----------------------------------------------------------------------
Date: 9 Jan 89 04:37:50 GMT
From: pikes!udenva!isis!scicom!craig@boulder.colorado.edu (Craig Anderson)
Subject: help with CScheme on 386ix
Message-Id: <1234@scicom.alphacdc.com>
I would like to build cscheme on a 386ix system. Any one out there done it?
Any help will be much appreciated.
Craig H. Anderson
UUCP (ncar,isis,boulder,nbires)!scicom!craig
DOMAIN craig@scicom.alphacdc.com
------------------------------
End of Scheme Digest
********************
∂10-Jan-89 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #46
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 21:15:00 PST
Date: 11 JAN 89 00:03:17 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #46
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #46 11 JAN 89 00:03:17 EST
Today's Topics:
Scheme on a PC
OOPSLA '89 Call in news.announce.conferences
TI-Scheme and Extended Memory
Scheme on a PC
----------------------------------------------------------------------
Date: 10 Jan 89 04:51:17 GMT
From: contact!ileaf!io!chuck@husc6.harvard.edu (Chuck Cullen x4423)
Subject: Re: Scheme on a PC
Message-Id: <887@io.UUCP>
In article <8953@cit-vax.Caltech.Edu>, kevin@cit-vax.Caltech.Edu (Kevin S. Van Horn) writes:
> Does anyone know where I can get an implementation of Scheme on a
> PC-compatible?
I have been planning on getting Scheme from Texas Instruments for use
on a pc project I told somebody I would do.
Does anybody disagree that the TI implementation is currently the best
solution available for Scheme on a pc?
Chuck Cullen
Interleaf, Inc.
10 Canal Park
Cambridge, MA 02141
(617) 577-9800 x4423
UUCP: {mit-eddie,bbn,sun!sunne}!ileaf!chuck
------------------------------
Date: 11 Jan 89 00:10:08 GMT
From: apple!kentb@bloom-beacon.mit.edu (Kent Beck)
Subject: OOPSLA '89 Call in news.announce.conferences
Message-Id: <23693@apple.Apple.COM>
Please look in news.announce.conferences for all the particulars about OOPSLA
'89. The conference will be held 2-6 October in New Orleans, and papers
are due to me by 17 March.
Kent Beck
Apple Computer, Inc.
20525 Mariani, MS 42C
Cupertino, CA 95014 USA
408/974-6027
------------------------------
Date: 9 Jan 89 23:22:44 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: TI-Scheme and Extended Memory
Message-Id: <1854@randvax.UUCP>
I see that TI's Personal Consultant package now runs on 286/386 machines
in protected mode and can address 4 megs (instead of 2 megs) of extended
memory.
Does anybody know if this implies a new version of TI-Scheme is coming out
that will run in protected mode and address the larger memory space? We
have an application that sure could take advantage of that... -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Date: 10 Jan 89 16:49:04 GMT
From: imagine!pawl20.pawl.rpi.edu!jefu@itsgw.rpi.edu (Jeffrey Putnam)
Subject: Re: Scheme on a PC
Message-Id: <2278@imagine.PAWL.RPI.EDU>
In article <887@io.UUCP> chuck@io.UUCP (Chuck Cullen x4423) writes:
>I have been planning on getting Scheme from Texas Instruments for use
>on a pc project I told somebody I would do.
>Does anybody disagree that the TI implementation is currently the best
>solution available for Scheme on a pc?
I have PC Scheme and its not bad. I do have a couple problems with it -
it doesnt support Hercules graphics, and every so often it goes away
with a "VM error" and just dies. This happens completely unpredictably
and i cant get it to repeat at will.
Other than that PC Scheme is good. The documentation is huge and quite
well done. Its even fairly fast.
jeff putnam -- "Sometimes one must attempt the impossible if only to
jefu@pawl.rpi.edu -- show it is merely inadvisable."
------------------------------
End of Scheme Digest
********************
∂11-Jan-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #47
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 21:34:16 PST
Date: 12 JAN 89 00:03:53 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #47
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #47 12 JAN 89 00:03:53 EST
Today's Topics:
Scheme on a PC
Past postings
Scheme->C a portable Scheme-to-C compiler
Scheme on a PC
----------------------------------------------------------------------
Date: 10 Jan 89 21:50:47 GMT
From: att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu (Vincent Manis)
Subject: Re: Scheme on a PC
Message-Id: <336@ubc-cs.UUCP>
In article <887@io.UUCP> chuck@io.UUCP (Chuck Cullen x4423) writes:
>Does anybody disagree that the TI implementation is currently the best
>solution available for Scheme on a pc?
I certainly don't. I've used it quite extensively (though not for
massive programs), and it satisfies my requirements quite well. V3.0
is pretty compatible with R↑3S, and supports a fair number of
extensions (most of the worthwhile extensions are PC-specific). In
particular, it supports an external language interface which permits
you to invoke primitive procedures in any compilable language (I use
Turbo C). The package includes the interpreter/compiler, a debugger,
and an Emacs-compatible editor.
There are only two downsides to PC Scheme: (1) it's a bit sluggish on
my PC XT compatible (on an AT it's quite pleasant), and (2) it doesn't
produce standalone programs (therefore anyone who uses a PC Scheme
program has to have a licence for the interpreter). Still, for US$100,
it's very hard to beat.
TI's phone number (US only--us foreigners don't count) is 1-800-TI-PARTS.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Had George III been a Scheme programmer, he might have responded
____________ to Patrick Henry by freeing him and then killing him."
-- Michael Eisenberg
------------------------------
Date: Wed, 11 Jan 89 08:26:22 PST
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8901111626.AA12201@sesame.Stanford.EDU>
Subject: Past postings
ciao,
Something went wrong with the net at Stanford for a period of time and
I now find myself with the Scheme digest #40-45. If anyone saved these, I
would appreciate a copy! (Also, if anyone has #1-6 I would like a copy)
(peace chance)
mas
shaff@sesame.stanford.edu
------------------------------
Message-Id: <8901111819.AA06187@saturn.pa.dec.com>
Subject: Scheme->C a portable Scheme-to-C compiler
Date: Wed, 11 Jan 89 10:19:42 -0800
From: bartlett@decwrl.dec.com
The Western Research Laboratory of Digital Equipment Corporation is
pleased to announce the availability of a new, experimental Scheme
compiler for research use on the VAX and DECstation 3100 (MIPS R2000
processor) computers.
The compiler compiles Revised**3 Scheme to C that is then compiled by
the native C compiler for the target machine. This design results in
a portable system that allows either stand-alone Scheme programs or
programs written in both compiled and interpreted Scheme and other
languages. An experiment run on a microVAX II suggests that this
approach does not adversely effect performance. There, the system
was able to execute the Gabriel benchmarks with performance similar
to that of a native Common LISP implementation.
If you are a member of a research organization interested in this software,
please contact me for licensing information.
Joel Bartlett bartlett@decwrl.dec.com
------------------------------
Date: 11 Jan 89 21:17:53 GMT
From: bgsuvax!maner@ohio-state.arpa (Walter Maner)
Subject: Re: Scheme on a PC
Message-Id: <3394@bgsuvax.UUCP>
From article <887@io.UUCP>, by chuck@io.UUCP (Chuck Cullen x4423):
> Does anybody disagree that the TI implementation is currently the best
> solution available for Scheme on a pc?
>
Until Betz puts his shareware XScheme in general release (Any Day Now),
TI Scheme is your best bet on a PC *IF* you have at least a 286 machine
*AND* at least 1 meg of RAM. I use TI Scheme on just such a machine and
am well satisfied with it.
--
CSNet : maner@research1.bgsu.edu | (419) 372-2337
InterNet: maner@research1.bgsu.edu (129.1.1.2) | Computer Science Dept.
UUCP : ... !osu-cis!bgsuvax!maner | BGSU
Generic : maner%research1.bgsu.edu@relay.cs.net | Bowling Green, OH 43403
------------------------------
End of Scheme Digest
********************
∂12-Jan-89 1351 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com R4RS Number Syntax
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 13:50:57 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 12 Jan 89 15:54:47 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac01776; 12 Jan 89 15:29 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25410; 12 Jan 89 15:14 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA09013; Thu, 12 Jan 89 11:14:26 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA08476; Thu, 12 Jan 89 11:13:59 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA03876; Thu, 12 Jan 89 11:15:57 pst
Message-Id: <8901121915.AA03876@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: scheme-standard@WHEATIES.AI.MIT.EDU
Subject: R4RS Number Syntax
Date: Thu, 12 Jan 89 11:15:53 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET
I have not seen mail in some time, so I though I would send some.
It seems to me that the sharp (#) character is somewhat overused used in
number syntax. I would like to see some character other than sharp used to
denote `extra digits'. I would prefer dollar ($) or question (?) for their
mnemonic value. Could one of these be excluded from special-initials? Bar
(|) is not in the extended alphabetics, but looks ugly to me.
Comments? Suggestions?
Ken Dickey <note change of email address>> kend@mrloog.LA.TEK.COM
PS: Any consensus on nice names for reckless rec-lets (er, named LETs)?
∂12-Jan-89 2117 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #48
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 21:17:17 PST
Date: 13 JAN 89 00:04:12 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #48
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #48 13 JAN 89 00:04:12 EST
Today's Topics:
TI-Scheme and Extended Memory
Past postings available
----------------------------------------------------------------------
Date: 11 Jan 89 04:05:25 GMT
From: att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu (Vincent Manis)
Subject: Re: TI-Scheme and Extended Memory
Message-Id: <345@ubc-cs.UUCP>
I've long since come to the conclusion that the PC Scheme used by TI
is very much more powerful than the one they sell. For one thing, it
can produce standalone programs.
Let me say here, in the hope that TI people are listening, that a
protected mode or OS/2 Scheme would be looked at with great favour, at
least by me.
____________ Vincent Manis | manis@cs.ubc.ca
___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn
____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net
___ /\ ___ University of British Columbia | uunet!ubc-cs!manis
__ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394
_ / __ \ _ "Had George III been a Scheme programmer, he might have responded
____________ to Patrick Henry by freeing him and then killing him."
-- Michael Eisenberg
------------------------------
Date: Thu, 12 Jan 89 10:58:34 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8901121558.AA03396@void.ai.mit.edu>
Subject: Past postings available
Reply-To: jar@zurich.ai.mit.edu
Date: Wed, 11 Jan 89 08:26:22 PST
From: shaff@sesame.stanford.edu (Mike Shaff)
Something went wrong with the net at Stanford for a period of time and
I now find myself with the Scheme digest #40-45. If anyone saved these, I
would appreciate a copy! (Also, if anyone has #1-6 I would like a copy)
Since you're on the Internet, you can anonymously FTP the archives
from mc.lcs.mit.edu. The relevant file is LSPMAI; SCHEME MAIL. (Note
spaces in file name. You may have to use double quotes, depending on
the details of your FTP program.) It's just a concatenation of all
messages since 16 Nov 1988, not divided into digests. Messages prior
to that are on ai.ai.mit.edu in LSPMAI; SCHEME MAILxx for xx from 1 on
up.
------------------------------
End of Scheme Digest
********************
∂13-Jan-89 2240 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #49
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 22:40:43 PST
Date: 14 JAN 89 00:04:58 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #49
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #49 14 JAN 89 00:04:58 EST
Today's Topics:
Scheme on a PC
Scheme->C compiler: questions and answers
----------------------------------------------------------------------
Date: 11 Jan 89 15:42:20 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: Re: Scheme on a PC
Message-Id: <1855@randvax.UUCP>
Of the dozen or so PC Scheme or LISP dialects that I'm familiar with, TI's
PC Scheme clearly has the best performance for its price. The
implementation really is remarkably well done.
The only "limitations" that have caused me pain are that: (1) the extended
memory version doesn't know about protected mode, and consequently runs
much slower than the 640k version; and (2) there is no built-in way to
freeze a session at some point and then restart the session some other day
(although there is a slick mechanism for bouncing from Scheme to DOS and
back). -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Message-Id: <8901140023.AA29380@saturn.pa.dec.com>
Subject: Scheme->C compiler: questions and answers
Date: Fri, 13 Jan 89 16:23:38 -0800
From: bartlett@decwrl.dec.com
I got a number of questions from people who saw my announcement
(thank you for your interest) which suggests that I should supply a
little more information about the Scheme->C compiler.
Licensing mechanics.
License and software distribution is via paper mail so I will need
your postal address. I'm going to have to defer replying to requests
from outside U.S.A. and Canada for a couple of weeks until we figure
out U.S. export restrictions. There is a distribution fee of $100
(U.S.) for the software. Software is distributed on a tar tape in
source form. Like any other research software, it's on an "as is"
basis. If your organization is unwilling to sign the license and you
still want the software, we'll have to discuss it.
Computer systems licensed.
Currently the system runs on top of ULTRIX. It has also been run on
4.2 BSD UNIX. A VMS version has not been made, but it can probably
run under Eunice.
While the software was designed to be portable and has been ported to
three different processors, the terms of the license restrict the
software to Digital VAX and DECstation 3100 computers.
Is it really Scheme?
The system supports the essentials of Revised**3 and many of the
optionals. Extensions include "expansion passing style" macros and a
foreign function call capability. The system does provide
call-with-current-continuation. Numbers are represented internally
as 29-bit integers, or 64-bit floating point values. Sorry, no X
window support.
The system is oriented towards block compilation to generate code
which can run in standalone programs which may include code from
other languages. While debugging is typically done using the
interpreter, it will never be considered a "Scheme environment".
The one "wart" in the system is that the compiler cannot compile all
tail calls correctly. This follows from some of the design tradeoffs
made when mapping Scheme to C. A forthcoming technical report
discusses this in some detail, please defer flames until then.
Greatest strength --> Scheme->C is not a <-- Greatest weakness
Scheme environment.
Misc. Technical details
The compiler is written in Scheme. Most of the runtime system
(including an interpreter) is written in Scheme. The garbage
collector and a few other things are written in C. There is a small
(< 100) amount of assembly code.
A technical report (I'll post a msg on the Scheme list when it's
available) will provide details about the design. It will include
some sample code, benchmark data etc.
Keep on schemeing,
jfb
------------------------------
End of Scheme Digest
********************
∂15-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #50
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 89 21:30:19 PST
Date: 16 JAN 89 00:09:33 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #50
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #50 16 JAN 89 00:09:33 EST
Today's Topics:
Scheme on a PC
----------------------------------------------------------------------
Date: 15 Jan 89 14:49:29 GMT
From: decvax!zinn!mipsmag!dbetz@bloom-beacon.mit.edu (David Betz)
Subject: Re: Scheme on a PC
Message-Id: <575@mipsmag.UUCP>
PC Scheme by TI is a *very* nice product and well worth the money. I'd
say it is the best implementation of Scheme for the IBM-PC.
------------------------------
End of Scheme Digest
********************
∂18-Jan-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #51
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 21:34:21 PST
Date: 19 JAN 89 00:10:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #51
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #51 19 JAN 89 00:10:32 EST
Today's Topics:
EDWIN status check
----------------------------------------------------------------------
Date: Wed, 18 Jan 89 08:47:25 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8901181647.AA23695@kestrel.arpa>
Subject: EDWIN status check
Last I heard, EDWIN (a text editor written in Scheme, by Chris Hanson
if I remember correctly) was yet to be released. What's the latest on
this?
My plan is to try to bring it up under T. Has anyone done this, or
tried and given up for some reason?
-- Scott
------------------------------
End of Scheme Digest
********************
∂19-Jan-89 2215 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #52
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 22:15:26 PST
Date: 20 JAN 89 00:11:09 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #52
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #52 20 JAN 89 00:11:09 EST
Today's Topics:
EDWIN status check
----------------------------------------------------------------------
Date: Thu, 19 Jan 89 21:03:26 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8901200203.AA02338@kleph.ai.mit.edu>
Subject: EDWIN status check
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 18 Jan 89 08:47:25 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Last I heard, EDWIN (a text editor written in Scheme, by Chris Hanson
if I remember correctly) was yet to be released. What's the latest on
this?
It's conceivable that it will be released this year, but that depends
on what kind of time I have available. Right now we're busy getting
our compiler ready for release; after that I'll see. I would be
willing, but reluctant, to give you a "current" copy: one that runs on
the 6.001 Chipmunks, under an older non-R3RS version of Scheme, taking
advantage of the screen hardware to avoid doing the hairy redisplay
computation. But if you're willing to wait a while the released
version should work with X (and perhaps with terminals in general),
and many of the user-visible differences between Edwin and GNU Emacs
will have been eliminated.
------------------------------
End of Scheme Digest
********************
∂20-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #53
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 21:30:48 PST
Date: 21 JAN 89 00:11:19 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #53
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #53 21 JAN 89 00:11:19 EST
Today's Topics:
scheme implementation.
Subscribe to SCHEME list
Macros in TI Scheme and Mac Scheme
----------------------------------------------------------------------
Date: Fri, 20 Jan 89 10:11:17 est
From: gjc%bucsf.BU.EDU@bu-it.bu.edu (George J. Carrette)
Message-Id: <8901201511.AA05969@bucsf>
Subject: scheme implementation.
In the 1988 USENIX C++ Conference there was a paper titled
"A C++ Interpreter for Scheme"
------------------------------
Date: Fri, 20 Jan 89 08:19:10 EST
From: Mott Given <dsacg1!dsacg3!ntm1169@tis.llnl.gov>
Message-Id: <8901201319.AA26374@dsacg3.UUCP>
Subject: Subscribe to SCHEME list
Mott Given @ Defense Logistics Agency ,DSAC-TMP, P.O. Box 1605, Bldg. 27
Section 1, Systems Automation Center, Columbus, OH 43216-5002
INTERNET: mgiven%dsacg1.uucp@daitc.arpa I speak for myself
Phone: 614-238-9431 AUTOVON: 850-9431
------------------------------
Date: 20 Jan 89 18:11:59 GMT
From: uoregon!akm@beaver.cs.washington.edu (Anant Kartik Mithal)
Subject: Macros in TI Scheme and Mac Scheme
Message-Id: <3566@uoregon.uoregon.edu>
Are there any compatibility problems between the macros for TI Scheme
and the macros for Mac Scheme? We have a large system written in Mac
Scheme, and would like to run it under TI Scheme. In the past, we've
had major problems between Mac Scheme and MIT Scheme, mostly in the area
of macros.
------------------------------
End of Scheme Digest
********************
∂22-Jan-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #54
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 89 21:29:55 PST
Date: 23 JAN 89 00:11:59 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #54
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #54 23 JAN 89 00:11:59 EST
Today's Topics:
scheme implementation.
----------------------------------------------------------------------
Date: 21 Jan 89 18:46:52 GMT
From: attcan!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Subject: Re: scheme implementation.
Message-Id: <956@yunexus.UUCP>
In article <8901201511.AA05969@bucsf> gjc@BUCSF.BU.EDU (George J. Carrette) writes:
>In the 1988 USENIX C++ Conference there was a paper titled
>"A C++ Interpreter for Scheme"
Could you please send|post exact ref details so that I can include
it in my scheme bibliography ?? Many thnx...
oz
--
... and I say to them, Usenet: oz@nexus.yorku.ca
`Where the hell were you ......!uunet!utai!yunexus!oz
when the page was blank?' Bitnet: oz@[yulibra|yuyetti]
Harlan Ellison Phonet: +1 416 736-5257x3976
------------------------------
End of Scheme Digest
********************
∂24-Jan-89 2203 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #55
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 22:03:32 PST
Date: 25 JAN 89 00:12:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #55
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #55 25 JAN 89 00:12:37 EST
Today's Topics:
Implementors of Scheme: Please read!
Scheme news?
----------------------------------------------------------------------
Date: 23 Jan 89 14:30:16 GMT
From: mcvax!cernvax!ethz!mfranz@uunet.uu.net (Michael Franz)
Subject: Implementors of Scheme: Please read!
Message-Id: <749@ethz.UUCP>
I have just completed an interpreter for R3 Scheme, as part of a
thesis project, with which I am fulfilling the requirements for
the degree of "Engineer in Computer Science" from ETH, the Swiss
Federal Institute of Technology in Zurich. ETH's Engineer's degree
is similar to a U.S. Master's degree in Computer Science.
My interpreter is written in the programming language Oberon and is
designed to run on the Ceres workstation under the Oberon Operating
System.
The Ceres workstation, Oberon operating system and the Oberon
language (the successor to Modula-2) were all developed here at ETH
by Professor Niklaus Wirth, who also oversees my thesis. The Ceres
line of computers is based on NS32000 series microprocessors.
Oberon is similar to Modula-2, but offers the concept of "type
extensions".
[N. Wirth, "Type Extensions", ACM TOPLAS V10 N2 Apr88, pp204-214]
[N. Wirth, "The Programming Language Oberon", Software, Practice
and Experience, V18 N7 Jul88, pp671-690]
The main goal of my thesis was less to develop an efficient
implementation of Scheme than to evaluate different strategies for
implementing a functional language **in a Modula-like-language and
without using any machine-specific tricks**. There is very little
experience with functional language programming at ETH, being the
original source of languages such as Pascal and Modula.
The result of my programming project is an interpreter entirely
written in Oberon (which by the way does not offer a GOTO, so the
program needs a very ugly dispatch function), which should be
easily portable to any other machine on which a compiler for either
Oberon or Modula is available. (Actually, I implemented Scheme
three times, using different approaches.)
As part of my thesis, I would like to include a small survey about
existing Scheme **interpreter** implementations on microprocessors
and would like to ask you to send me a short reply to the following
questions. (I do realize, that most implementations of Scheme are
compilers that either generate native code or some kind of interpre-
ted intermediate code, but these are not really comparable to my
work, which is a true interpreter and does not process instructions
prior to execution (apart from lexical conversion). Please only
answer if you can comment on an existing **interpreter**.
Questions:
1.1. Name of Project/Program
1.2. Based On or New Work
1.3. Implementation Language
1.4. Destination Processor / Word Length
1.5. Are any parts of the program coded in assembly language?
1.6. Amount of memory available to the interpreter for data storage
1.7. Garbage collection strategy used
1.8. Source Code / Object Size (lines/bytes) of Scheme Interpreter
2.1. Time to execute (fib 20) with body of fib defined as
(cond ((< n 2) n) (else (+ (fib (- n 2)) (fib (- n 1)))))
2.2. Time to execute (fib 20) using IF instead of COND
2.3. Time to execute (tak 18 12 6) with (tak x y z) defined as
(cond ((<= x y) z)
(else (tak (tak (- x 1) y z)
(tak (- y 1) z x)
(tak (- z 1) x y))))
Also, if you have any Scheme programs that I could use for testing my
interpreter, I would also be grateful if you could send them to me.
Thank you very much. I greatly appreciate your help.
Michael Franz
mfranz@czheth5a.bitnet
mfranz@ifi.ethz.ch and mfranz@rzeth.ethz.ch
..uunet!mcvax!cernvax!ethz!mfranz
P.S.: I have been trying to get a copy of R. Kent Dybvigs Ph.D.
dissertation (unfortunately, I only saw the reference to it way after
I had started on my own set of implementation models), but no library
that I have access to seems to have it. If anyone could make a copy
and send it to me, please notify me by E-mail; I will send you a my
complete postal address and a check to cover copying and postage.
Please send me a mail before you copy anything, because there may be
more than one person who can help me with this one (who knows, even R.K.D.
himself...)
------------------------------
Date: 23 Jan 89 20:57:37 GMT
From: mcvax!unido!pcsbst!jkh@uunet.uu.net (Jordan K. Hubbard)
Subject: Scheme news?
Message-Id: <748@pcsbst.UUCP>
I'm running C-Scheme Vers 6.1 and would be very interested in staying
up-to-date with what's going on with it. In particular, a compiler
(called LIAR?) and X interface are mentioned in one of the release
documents, but I don't know what stage of development they're in. I
guess I have two questions. In particular, what's going on with the
compiler and the X (Version 11?) interface? In general, how do I
stay up to date?
Jordan Hubbard
uunet!pyramid!pcsbst!jkh
------------------------------
End of Scheme Digest
********************
∂28-Jan-89 0240 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #56
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 89 02:40:19 PST
Date: 28 JAN 89 00:14:21 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #56
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #56 28 JAN 89 00:14:21 EST
Today's Topics:
Request for scheme code
Scheme semantics
----------------------------------------------------------------------
Date: Fri, 27 Jan 89 11:38:01 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8901271938.AA10448@sesame.Stanford.EDU>
Subject: Request for scheme code
Before I got to the trouble of writing Scheme code for regular expression
matching, I thought I would send out a quick message to see if anyone already
has this code and would be willing to give it to me. Any volunteers?
Morry Katz
katz@polya.stanford.edu
------------------------------
Date: 26 Jan 89 21:18:32 GMT
From: schaefer!uhura!quale@csd4.milw.wisc.edu (Douglas E. Quale)
Subject: Scheme semantics
Message-Id: <143@uhura.cs.wisc.edu>
The R3RS section on formal semantics states that the semantic description
was machine generated from an executable specification in Scheme.
Are either of these programs still around?
Both Scheme semantic description and the translator might be of interest.
-- Doug Quale
quale@uhura.cs.wisc.edu
------------------------------
End of Scheme Digest
********************
∂30-Jan-89 2126 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #57
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 21:25:57 PST
Date: 31 JAN 89 00:03:23 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #57
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #57 31 JAN 89 00:03:23 EST
Today's Topics:
actually about Xscheme
----------------------------------------------------------------------
Date: 30 Jan 89 04:12:04 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: actually about Xscheme
Message-Id: <6446@polya.Stanford.EDU>
[This is cross-posted as Xlisp and Xscheme are genetically related].
I've got my hands on the xscheme distribution for what looks like
ms-dos machines. I'd like to get it up on a Unix System V machine.
I'm not much of a C or Unix hacker - has anyone done this or can
point me in the right direction?
(As far as I can see, it comes down to straightforward I/O stuff -
but when I see too many &'s and *'s on the same line I freak out...)
thanks,
--ilan
caron@polya.stanford.edu
------------------------------
End of Scheme Digest
********************
∂31-Jan-89 0756 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 07:56:07 PST
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 31 Jan 89 10:49:19 EST
Received: by void.ai.mit.edu (5.59/1.5)
id AA11770; Tue, 31 Jan 89 10:54:04 EST
Date: Tue, 31 Jan 89 10:54:04 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8901311554.AA11770@void.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: truth of '()
Reply-To: jar@zurich.ai.mit.edu
Does anyone out there seriously object to allowing the empty list to be
considered true? That is, permit implementations to return either #t or
#f for (if '() #t #f).
I think we just didn't get around to discussing this at Snowbird, and
I have the impression that we are ready to make this change.
I hope we can make language decisions (at least provisionally) on this
mailing list, without having to wait for meetings.
∂31-Jan-89 0950 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 09:50:18 PST
Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 31 Jan 89 12:45:01 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13348; Tue, 31 Jan 89 09:43:37 PST
Date: Tue, 31 Jan 89 09:43:37 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8901311743.AA13348@sesame.Stanford.EDU>
To: jar@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan Rees's message of Tue, 31 Jan 89 10:54:04 EST <8901311554.AA11770@void.ai.mit.edu>
Subject: truth of '()
Date: Tue, 31 Jan 89 10:54:04 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Reply-To: jar@zurich.ai.mit.edu
Does anyone out there seriously object to allowing the empty list to be
considered true? That is, permit implementations to return either #t or
#f for (if '() #t #f).
I think we just didn't get around to discussing this at Snowbird, and
I have the impression that we are ready to make this change.
I hope we can make language decisions (at least provisionally) on this
mailing list, without having to wait for meetings.
My understanding of the discussion at Snowbird was that it was decided that '()
and #f were not necessarily eq? in all implementations. There is no point in
allowing this distinction if '() cannot be considered a `true value' in systems
which distinguish the two objects. I therefore strongly urge that the truth
value of '() be unspecified.
Going one step further, I once again must suggest that the truth values of all
objects other than #f and #t should be unspecified. Functions FALSE? and TRUE?
should be introduced into the language ((FALSE? N) returns #t when N is #f, #f
otherwise; and (TRUE? N) returns #t when N is #t, #f otherwise). These
procedures along with the existing ones like NULL?, PAIR?, etc. would allow all
the necessary boolean conditions to be expressed and canonicalized for use with
IF, etc. The resulting code would, in my opinion, be much easier to read and
less error prone. Since I suspect that compatability with old code is the
major impediment to people agreeing to such a change, let me suggest that the
old semantics booleans can easily be retrieved from the new by using a few
simple macros for IF, etc. (While we still haven't managed to standardize
macros, I am sure that all existing Scheme systems have them, so backwards
compatability is possible in this manner.) Lets not get hung up on history,
but rather fix this traditionally poor semantics.
Morry Katz
katz@polya.stanford.edu
∂31-Jan-89 1202 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com Re: truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 12:02:08 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 31 Jan 89 14:54:43 EST
Received: from relay2.cs.net by RELAY.CS.NET id aj15334; 31 Jan 89 13:48 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa13406; 31 Jan 89 13:29 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA13589; Tue, 31 Jan 89 09:05:13 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA04919; Tue, 31 Jan 89 09:04:11 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA10814; Wed, 1 Feb 89 09:06:20 pst
Message-Id: <8902011706.AA10814@bloom.LA.TEK.COM>
To: jar@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: truth of '()
In-Reply-To: Your message of Tue, 31 Jan 89 10:54:04 -0500.
<8901311554.AA11770@void.ai.mit.edu>
Date: Wed, 01 Feb 89 09:06:17 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET
I would prefer that '() be true always. I think that the question should be
`why should anything other than #f be false?'. While I understand the
historical arguments and sympathize with implementors, I feel that having
(if '() #t #f) return #t or #f depending on the implementation will be bad
for the language. It will be an irritation for a long time if this is not
decided now; a hinderance to portability.
-Ken Dickey kend@mrloog.LA.TEK.COM
∂31-Jan-89 1234 @MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 12:34:08 PST
Received: from helios.northeastern.edu (TCP 20102400402) by MC.LCS.MIT.EDU 31 Jan 89 15:26:51 EST
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
id aa17133; 31 Jan 89 15:21 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.5)
id AA17812; Tue, 31 Jan 89 15:20:09 EST
Date: Tue, 31 Jan 89 15:20:09 EST
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8901312020.AA17812@corwin.CCS.Northeastern.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Quoting vectors?
Does anyone remember why we decided to force vectors to be quoted, while #t
and #f and character constants need not be quoted?
--Mitch
∂31-Jan-89 1244 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 12:44:20 PST
Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU 31 Jan 89 15:37:20 EST
Received: by kleph.ai.mit.edu (5.59/1.5)
id AA08459; Tue, 31 Jan 89 15:34:39 EST
Date: Tue, 31 Jan 89 15:34:39 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8901312034.AA08459@kleph.ai.mit.edu>
To: wand@corwin.ccs.northeastern.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mitchell Wand's message of Tue, 31 Jan 89 15:20:09 EST <8901312020.AA17812@corwin.CCS.Northeastern.EDU>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 31 Jan 89 15:20:09 EST
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Does anyone remember why we decided to force vectors to be quoted, while #t
and #f and character constants need not be quoted?
I don't remember why, but I believe this was an unnecessary decision.
Leaving out the quote causes no confusion.
∂31-Jan-89 1732 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 17:32:33 PST
Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 31 Jan 89 20:09:52 EST
Received: by ZOHAR.AI.MIT.EDU; Tue, 31 Jan 89 16:49:17 est
Date: Tue, 31 Jan 89 16:49:17 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8901312149.AA12923@zohar>
To: cph@zurich.ai.mit.edu
Cc: wand@corwin.ccs.northeastern.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 31 Jan 89 15:34:39 EST <8901312034.AA08459@kleph.ai.mit.edu>
Subject: Quoting vectors?
I would rather that vectors (and all objects that cannot be confused
with expressions) not need quotes, as the only reason for quotes is to
distinguish expressions from their values.
∂31-Jan-89 1748 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 17:47:57 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:18:46 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 17:18:32 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 1840 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 18:39:59 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:23:36 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:46:15 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 1850 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 18:50:27 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:24:02 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:48:32 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 1901 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:01:20 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:24:31 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:45:23 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std
Date: Fri, 27 Jan 89 14:46:12 PST
From: Pavel.pa@Xerox.COM
I note with some misgivings several differences between R4RS and the draft
IEEE standard such that the standard is not a subset of R4RS....
I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS. There are only two things in the draft
IEEE standard that might not belong in the R4RS:
WITH-INPUT-FROM-PORT
WITH-OUTPUT-TO-PORT
Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS. (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)
I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.
The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER. If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.
The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.
Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer. (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part. Does anyone disagree?) I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.
Peace, Will
acting editor, R4RS
∂31-Jan-89 1911 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:11:42 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:25:04 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 13:49:03 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std
Date: Fri, 27 Jan 89 14:46:12 PST
From: Pavel.pa@Xerox.COM
I note with some misgivings several differences between R4RS and the draft
IEEE standard such that the standard is not a subset of R4RS....
I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS. There are only two things in the draft
IEEE standard that might not belong in the R4RS:
WITH-INPUT-FROM-PORT
WITH-OUTPUT-TO-PORT
Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS. (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)
I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.
The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER. If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.
The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.
Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer. (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part. Does anyone disagree?) I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.
Peace, Will
acting editor, R4RS
∂31-Jan-89 1921 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu differences between R4RS and draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:21:18 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:25:34 EST
Received: from [128.223.4.2] by mist.math.uoregon.edu; Tue, 31 Jan 89 14:53:54 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:45:15 PDT
Date: Tue, 31 Jan 89 13:45:15 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312145.AA10910@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: differences between R4RS and draft IEEE std
Date: Fri, 27 Jan 89 14:46:12 PST
From: Pavel.pa@Xerox.COM
I note with some misgivings several differences between R4RS and the draft
IEEE standard such that the standard is not a subset of R4RS....
I predict that the R4RS will adopt almost all of the changes urged upon it by
the people writing the IEEE standard, making the draft IEEE standard very
close to being a subset of the R4RS. There are only two things in the draft
IEEE standard that might not belong in the R4RS:
WITH-INPUT-FROM-PORT
WITH-OUTPUT-TO-PORT
Many people have wanted these procedures, but I do not feel that the authors
have yet approved their inclusion in R4RS. (These also happen to be the
features of the draft IEEE standard that I am least comfortable with, as
discussed in a separate message.)
I consider that addition of the STRING procedure to R4RS is warranted as a
"regularization of procedures", which the authors indicated they were willing
to consider by electronic mail.
The subcommittee delegated to clean up numbers was specifically charged with
the task of simplifying NUMBER->STRING and STRING->NUMBER. If that subcommittee
recommends that the R4RS description of these procedures be changed to match
the draft IEEE standard, as I am sure they will, then the change will happen.
The changes to CHAR-UPPER-CASE? and CHAR-LOWER-CASE? are non-controversial and
should fall within the discretion of the editors.
Requiring that CHAR->INTEGER be given an exact non-negative integer is
needed for consistency with R4RS's requirement that INTEGER->CHAR return an
exact non-negative integer. (Actually the non-negative part was not explicit
when this was approved at Snowbird, but I think that was just an oversight on
my part. Does anyone disagree?) I do not feel that the R4RS should drop the
requirement of order isomorphism, but the draft IEEE standard can drop it
without endangering its status as a subset.
Peace, Will
acting editor, R4RS
∂31-Jan-89 1931 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:31:13 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:26:01 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 15:48:31 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 1943 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:43:30 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:27:15 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 16:18:34 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 1954 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 19:53:54 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 31 Jan 89 20:27:47 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 31 Jan 89 16:48:33 PDT
Received: by fog.cs.uoregon.edu; Tue, 31 Jan 89 13:46:07 PDT
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901312146.AA10918@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: comments on draft IEEE std
I also favor using a boolean in place of a symbol as the third argument
in (string->number STRING RADIX EXACTNESS). Not only are there only two
possible values, but I think this would be the only standard procedure
to perform a case dispatch on a symbol.
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
I'd like to see backquote in the IEEE standard, but I'm worried about
not having a good specification of its semantics. Jonathan's code is great
but too specific. Maybe the code could go in a non-binding appendix?
I think the => syntax of `cond' is a good example of the kind of thing that
can go in the Report but should stay out of the IEEE standard.
One person's random opinions. Peace, Will
∂31-Jan-89 2017 @MC.LCS.MIT.EDU:cph@murren.ai.mit.edu comments on draft IEEE std
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 20:17:08 PST
Received: from murren.ai.mit.edu (TCP 2212600263) by MC.LCS.MIT.EDU 31 Jan 89 20:59:03 EST
Received: by murren.ai.mit.edu (5.59/1.5)
id AA20427; Tue, 31 Jan 89 20:51:41 EST
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
Message-Id: <8902010151.AA20427@murren.ai.mit.edu>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: William Clinger's message of Tue, 31 Jan 89 13:46:07 PDT <8901312146.AA10918@fog.cs.uoregon.edu>
Subject: comments on draft IEEE std
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a way
to change the default ports is that some people do not want them to be
changable. Furthermore the implementation-dependent behavior of these
new procedures is a serious problem because they muck with a global
resource: the default ports. The implementation-dependent behavior of
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE is better isolated and
therefore less troublesome.
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
∂31-Jan-89 2250 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #58
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 22:49:59 PST
Date: 1 FEB 89 00:03:38 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #58
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #58 1 FEB 89 00:03:38 EST
Today's Topics:
Scheme semantics
xscheme distribution available
----------------------------------------------------------------------
Date: Sat, 28 Jan 89 16:40:18 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8901282140.AA10503@void.ai.mit.edu>
Subject: Scheme semantics
Reply-To: jar@zurich.ai.mit.edu
Date: 26 Jan 89 21:18:32 GMT
From: schaefer!uhura!quale@csd4.milw.wisc.edu (Douglas E. Quale)
The R3RS section on formal semantics states that the semantic description
was machine generated from an executable specification in Scheme.
Are either of these programs still around?
Both Scheme semantic description and the translator might be of interest.
For the semantics, send a request to scheme-librarian@zurich.ai.mit.edu.
I think it's part of the MIT Scheme distribution, if you have that.
I wrote that fabled Scheme-to-TeX "uglyprinter", and it was far
from perfect. It didn't do a very good job of figuring out line
breaks or indentation, for example; I ended up doing almost all of
that by hand (took me several days). I think I let the program slip
into oblivion when the MIT AI lab's TOPS-20 system went away. You
could probably write a transliterator at least as good in an hour or
two.
------------------------------
Date: 31 Jan 89 20:36:48 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: xscheme distribution available
Message-Id: <6510@polya.Stanford.EDU>
Well, the xscheme distribution is now available for
anonymous ftp from labrea.stanford.edu (I'm not sure
what its numerical address is - if someone needs to know,
I can find out).
Login as anonymous, any password, cd pub and
get xscheme.tar.Z in binary mode.
If anyone manages to get a unix port working, please
let the rest of us know.
--ilan
caron@polya.stanford.edu
P.S. if you don't have ftp access, I don't mind mailing
out a uuencoded version.
------------------------------
End of Scheme Digest
********************
∂01-Feb-89 0622 @MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 06:22:02 PST
Received: from chamartin.ai.mit.edu (TCP 2212600253) by MC.LCS.MIT.EDU 1 Feb 89 09:12:45 EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
id AA05917; Wed, 1 Feb 89 08:46:38 EST
Date: Wed, 1 Feb 89 08:46:38 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902011346.AA05917@chamartin.ai.mit.edu>
To: gjs@ZOHAR.AI.MIT.EDU
Cc: cph@zurich.ai.mit.edu, wand@corwin.ccs.northeastern.edu,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Tue, 31 Jan 89 16:49:17 est <8901312149.AA12923@zohar>
Subject: Quoting vectors?
Reply-To: jinx@zurich.ai.mit.edu
I would rather that vectors (and all objects that cannot be confused
with expressions) not need quotes, as the only reason for quotes is to
distinguish expressions from their values.
You've all forgotten a little detail.
`#(foo ,bar baz ,@quux)
is legal. It would be REALLY strange if a constant vector did not
need to be quoted when a "quasi-constant" vector did.
∂01-Feb-89 0907 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 09:07:37 PST
Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 1 Feb 89 11:10:00 EST
Received: by ZOHAR.AI.MIT.EDU; Wed, 1 Feb 89 10:00:13 est
Date: Wed, 1 Feb 89 10:00:13 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8902011500.AA13458@zohar>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.EDU
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 31 Jan 89 18:31:49 PST <890131-183204-9404@Xerox>
Subject: Quoting vectors?
I would rather that ... all objects that cannot be confused
with expressions ... not need quotes ...
I assume that this includes (), since it also fits into this category.
Well, almost all, but I really don't care about the disposition of (),
I cannot remember ever trying to use bare () in a program.
... Well, hardly ever ...
The Captian of the Pinafore.
∂01-Feb-89 0920 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 09:20:09 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Feb 89 11:10:44 EST
Received: from Salvador.ms by ArpaGateway.ms ; 31 JAN 89 18:32:04 PST
Date: Tue, 31 Jan 89 18:31:49 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8901312149.AA12923@zohar>
To: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Cc: rrrs-authors@mc.lcs.mit.EDU
Message-ID: <890131-183204-9404@Xerox>
I would rather that ... all objects that cannot be confused
with expressions ... not need quotes ...
I assume that this includes (), since it also fits into this category.
Pavel
∂01-Feb-89 0932 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 09:31:57 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Feb 89 11:11:03 EST
Received: from Salvador.ms by ArpaGateway.ms ; 31 JAN 89 18:39:48 PST
Date: Tue, 31 Jan 89 18:39:37 PST
From: Pavel.pa@Xerox.COM
Subject: Re: truth of '()
In-reply-to: <8901311743.AA13348@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890131-183948-9423@Xerox>
I certainly support unspecifying the truth-value of the empty list. Unlike
Ken Dickey, I don't feel the need for an immediate change to specifying
that () is true, either. I'm perfectly willing to give implementations one
more bounce of the report to get switched over.
Morry Katz is strongly in favor of unspecifying the truth-values of
non-booleans. This has never appealed to me. Morry, could you provide
more extensive support for your view that the ``resulting code would ... be
much easier to read and less error prone''? I'm not convinced that the
status quo in this case is an example of ``traditionally poor semantics''.
Pavel
∂01-Feb-89 0944 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 09:44:31 PST
Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU 1 Feb 89 11:11:32 EST
Received: by kleph.ai.mit.edu (5.59/1.5)
id AA08769; Wed, 1 Feb 89 09:57:10 EST
Date: Wed, 1 Feb 89 09:57:10 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8902011457.AA08769@kleph.ai.mit.edu>
To: jinx@zurich.ai.mit.edu
Cc: gjs@ZOHAR.AI.MIT.EDU, wand@corwin.ccs.northeastern.edu,
rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 1 Feb 89 08:46:38 EST <8902011346.AA05917@chamartin.ai.mit.edu>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu
Date: Wed, 1 Feb 89 08:46:38 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
You've all forgotten a little detail.
`#(foo ,bar baz ,@quux)
is legal. It would be REALLY strange if a constant vector did not
need to be quoted when a "quasi-constant" vector did.
I don't believe this small bit of consistency is very important.
After all, even if quote is not required on vector constants, it is
still allowed.
As to its being REALLY strange, MIT Scheme does it just that way, and
aside from the fact that it is a completely natural implementation, I
don't think anyone has ever run into any confusion because of the lack
of that requirement.
∂01-Feb-89 1018 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 10:18:23 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 11:14:32 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 08:13:46 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:13:37 PDT
Date: Wed, 1 Feb 89 08:13:37 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011613.AA14233@fog.cs.uoregon.edu>
To: rrrs-authors@MC.LCS.MIT.EDU, wand@CORWIN.CCS.NORTHEASTERN.EDU
Subject: Re: Quoting vectors?
My recollection is that there were two principled positions (everything
must be explicitly quoted; or only lists and symbols must be quoted) and
that we chose to be close to the "everything must be explicitly quoted"
position, making exceptions for #T, #F, numbers, and strings (presumably
because of historical precedent not only in Lisp but in other
languages). Vectors were considered for self-evaluating status, but the
lack of historical precedent and their syntactic similarity to lists
successfully argued against.
Peace, Will
∂01-Feb-89 1207 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:07:17 PST
Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 1 Feb 89 13:14:12 EST
Received: by iuvax.cs.indiana.edu
Date: Wed, 1 Feb 89 10:38:46 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx@ZURICH.AI.MIT.EDU
Subject: Re: Quoting vectors?
Cc: rrrs-authors@mc.lcs.mit.edu
> I would rather that vectors (and all objects that cannot be confused
> with expressions) not need quotes, as the only reason for quotes is to
> distinguish expressions from their values.
>
>You've all forgotten a little detail.
>
>`#(foo ,bar baz ,@quux)
>
>is legal. It would be REALLY strange if a constant vector did not
>need to be quoted when a "quasi-constant" vector did.
I agree. It would be strange. However, we could look at this is an
opportunity to remove vectors from quasiquote...
∂01-Feb-89 1219 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:19:44 PST
Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 1 Feb 89 13:26:51 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA14758; Wed, 1 Feb 89 09:54:22 PST
Date: Wed, 1 Feb 89 09:54:22 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8902011754.AA14758@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Tue, 31 Jan 89 18:39:37 PST <890131-183948-9423@Xerox>
Subject: truth of '()
Date: Tue, 31 Jan 89 18:39:37 PST
From: Pavel.pa@Xerox.COM
I certainly support unspecifying the truth-value of the empty list. Unlike
Ken Dickey, I don't feel the need for an immediate change to specifying
that () is true, either. I'm perfectly willing to give implementations one
more bounce of the report to get switched over.
Morry Katz is strongly in favor of unspecifying the truth-values of
non-booleans. This has never appealed to me. Morry, could you provide
more extensive support for your view that the ``resulting code would ... be
much easier to read and less error prone''? I'm not convinced that the
status quo in this case is an example of ``traditionally poor semantics''.
Pavel
Currently, there are a lot of functions that do things like return a list or
nil, if no match is found. I think that it would be much clearer to the reader
if such a function were wrapped in a call to NULL? when used as a predicate.
Similar use of PAIR?, etc. forces the programmer to specify the types of values
he/she expects the given function to return and consequently informs the reader
of this information. I find such code mush easier to read. Maybe this is just
my hangup, but the use of all objects as boolean values seems to me a little
like a type error. My personal perspective is that asking whether '() and #f
are eq? is a little like asking whether (char? 13) returns #t. Types should
really be disjoint and this includes the boolean values #t and #f.
Morry Katz
katz@polya.stanford.edu
∂01-Feb-89 1235 @MC.LCS.MIT.EDU:gls@Think.COM Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:35:28 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 1 Feb 89 13:43:50 EST
Received: from fafnir.think.com by Think.COM; Wed, 1 Feb 89 12:48:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 1 Feb 89 12:54:03 EST
Received: by verdi.think.com; Wed, 1 Feb 89 12:53:36 EST
Date: Wed, 1 Feb 89 12:53:36 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902011753.AA14984@verdi.think.com>
To: jinx@zurich.ai.mit.edu
Cc: gjs@zohar.ai.mit.edu, cph@zurich.ai.mit.edu,
wand@corwin.ccs.northeastern.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Wed, 1 Feb 89 08:46:38 EST <8902011346.AA05917@chamartin.ai.mit.edu>
Subject: Quoting vectors?
Date: Wed, 1 Feb 89 08:46:38 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
I would rather that vectors (and all objects that cannot be confused
with expressions) not need quotes, as the only reason for quotes is to
distinguish expressions from their values.
You've all forgotten a little detail.
`#(foo ,bar baz ,@quux)
is legal. It would be REALLY strange if a constant vector did not
need to be quoted when a "quasi-constant" vector did.
I think there may be a confusion here between two distinct properties
of a data object: whether or not it self-evaluates, and whether or
not is has (Lisp) substructure.
It is hard to work from analogy, because all other self-evaluating items
happen also to have the property of having no substructure, so I cannot
give you a plausible example of, for example, a quasi-quoted integer.
In the context of Common Lisp I might offer the fact that the complex
number #c(0 1) does not require quotation, but `#c(0 ,x) might be a
reasonable thing to want to write (though in fact it is not permitted in
Common Lisp).
--Guy
∂01-Feb-89 1255 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 12:54:53 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 14:18:51 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 11:18:42 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 1319 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 13:18:52 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 14:44:22 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 10:18:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 1508 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 15:08:38 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 1 Feb 89 16:03:45 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa07115; 1 Feb 89 15:26 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25646; 1 Feb 89 15:20 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA20669; Wed, 1 Feb 89 11:54:46 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA06172; Wed, 1 Feb 89 11:53:41 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA11596; Thu, 2 Feb 89 11:55:50 pst
Message-Id: <8902021955.AA11596@bloom.LA.TEK.COM>
To: Mitchell Wand <wand@CORWIN.CCS.NORTHEASTERN.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: Quoting vectors?
In-Reply-To: Your message of Tue, 31 Jan 89 15:20:09 -0500.
<8901312020.AA17812@corwin.CCS.Northeastern.EDU>
Date: Thu, 02 Feb 89 11:55:47 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET
Mitch,
As I remember it, the reason given for quoting vectors is that a case could
be made for a Scheme dialect in which #(foo bar baz) is seen as a function
application analogous to (foo bar baz). In such a dialect there might, for
example, be a `rest' argument which was a vector.
E.g.:
((lambda (a b #. c) c) '(1 2 3 4 5 6)) ==> #(3 4 5 6)
etc.
I see no reason to force an implementation which experiments in this way not
be called Scheme on the basis of a single difference from a standard.
-Ken Dickey
∂01-Feb-89 1534 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 15:34:39 PST
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 1 Feb 89 17:32:47 EST
Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 170157; Wed 1-Feb-89 17:32:10 EST
Date: Wed, 1 Feb 89 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: truth of '()
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <890131-183948-9423@Xerox>
Message-ID: <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
My opinions:
1. I don't have any problem with leaving the boolean significance of ()
unspecified.
2. I am strongly in favor of retaining the fine Lisp tradition
of treating everything other than () and #F as truth.
My concern:
Date: Tue, 31 Jan 89 18:39:37 PST
From: Pavel.pa@Xerox.COM
I certainly support unspecifying the truth-value of the empty list. Unlike
Ken Dickey, I don't feel the need for an immediate change to specifying
that () is true, either. I'm perfectly willing to give implementations one
more bounce of the report to get switched over.
I don't recall that we have any consensus for eventually declaring that
implementations -must- have distinct () and #F objects. My understanding
is that making the boolean significance of () unspecified is to accommodate
implementations in which they are distinct, where it might be inconvenient
to arrange for () to be false. It is not my understanding that we are
doing this as a stepping stone on the way towards defining () to be true
(which would force () to be distinct from #F).
Please note that this concern of mine has no effect on the current
discussion about ().
∂01-Feb-89 1703 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 17:03:32 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 18:40:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 09:48:39 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 1716 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu apology for flamage concerning WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 17:16:30 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 19:18:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 16:18:45 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 16:13:23 PDT
Date: Wed, 1 Feb 89 16:13:23 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902020013.AA16093@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: apology for flamage concerning WITH-INPUT-FROM-PORT etc
Please disregard my earlier flamage concerning WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT. I was just moby confused, having somehow gotten it
deeply wedged into my brain that these procedures were replacing
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE when they are really
replacing WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE. The proposed
procedures are clearly superior to the ones they replace, and the only
possible question is whether this particular bit of functionality, which
was optional in R3RS, should go into the IEEE standard.
I certainly favor making this change in R4RS.
Please accept my apologies for thoughtlessly polluting this mailing list
with nonsense.
Peace, William Clinger
P.S. with regard to whether vector constants should have to be quoted:
As things stand now, implementations are free to allow unquoted vector
constants, and several do. Does the recent discussion mean that this
this feature is causing so many portability problems that it should be
required of all implementations?
∂01-Feb-89 1923 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 19:23:25 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Feb 89 19:38:47 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 14:55:51 PST
Date: Wed, 01 Feb 89 14:55:40 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8902011500.AA13458@zohar>
To: rrrs-authors@mc.lcs.mit.EDU
Message-ID: <890201-145551-11497@Xerox>
Sussman says that he ``cannot remember ever trying to use bare () in a
program''. The only explanation I can give for this is the fact that the
initial value of NIL is #f and that, in C-Scheme, #f and () are identical.
Thus, it might be that he never uses () because he always uses NIL in such
a case. I seem to remember seeing such cases in SICP.
Pavel
∂01-Feb-89 2015 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 20:15:42 PST
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 1 Feb 89 22:08:02 EST
Received: by void.ai.mit.edu (5.59/1.5)
id AA12400; Wed, 1 Feb 89 21:22:59 EST
Date: Wed, 1 Feb 89 21:22:59 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902020222.AA12400@void.ai.mit.edu>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: William Clinger's message of Wed, 1 Feb 89 08:13:37 PDT <8902011613.AA14233@fog.cs.uoregon.edu>
Subject: Quoting vectors?
Reply-To: jar@zurich.ai.mit.edu
My recollection agrees with Will's. Vectors should be quoted because
they look and feel like lists. Empty lists should be quoted for
consistency with other kinds of lists. When in doubt, quote.
I have made use of both restrictions. I would prefer that we be
conservative and not change the language in these cases.
∂01-Feb-89 2032 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 20:32:32 PST
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 1 Feb 89 22:08:22 EST
Received: by void.ai.mit.edu (5.59/1.5)
id AA12393; Wed, 1 Feb 89 21:09:06 EST
Date: Wed, 1 Feb 89 21:09:06 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902020209.AA12393@void.ai.mit.edu>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Wed, 1 Feb 89 17:32 EST <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: truth of '()
Reply-To: jar@zurich.ai.mit.edu
Date: Wed, 1 Feb 89 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
1. I don't have any problem with leaving the boolean significance of ()
unspecified.
Clarification: the Revised↑3 Report (section 6.1) does not leave the
boolean significance of () unspecified; it says explicitly that ()
must be treated as false. It was proposed last July (item 4.25 of
"Proposals for a Revised↑4 Scheme Report") that this be relaxed so
that () could be treated as either true or false. We ran out of time
before we could get around to considering this item. That is why I
brought it up again.
∂01-Feb-89 2056 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 20:56:00 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Feb 89 22:26:29 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 17:29:21 PST
Date: Wed, 01 Feb 89 17:28:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Quoting vectors?
In-reply-to: <8902021955.AA11596@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <890201-172921-11917@Xerox>
In reference to Ken Dickey's argument that vectors should be quoted in
order to allow experimentation with new dialects that want to use vectors
as some other kind of syntax:
I've never understood this point of view. Ken mentions the idea of #(foor
bar baz) being another syntax for application in a dialect in which one
could get a ``rest'' argument as a vector. Clearly, the data type used to
represent the expression need not have anything to do with the data types
used to implement the evaluation of that expression, so the availability of
vector ``rest'' arguments is completely orthogonal to the use of vectors as
a kind of expression.
I see no reason to force all Scheme programmers to write logically
unnecessary quotes in order to allow this obscure and, to my knowledge,
rarely if ever employed, avenue for experimentation.
Pavel
∂01-Feb-89 2107 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:07:24 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 1 Feb 89 22:26:45 EST
Received: from Salvador.ms by ArpaGateway.ms ; 01 FEB 89 17:06:17 PST
Date: Wed, 01 Feb 89 17:06:06 PST
From: Pavel.pa@Xerox.COM
Subject: Re: truth of '()
In-reply-to: <8902011754.AA14758@sesame.Stanford.EDU>
To: mkatz@sesame.stanford.edu (Morris Katz)
Cc: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890201-170617-11852@Xerox>
Morry says, ``use of PAIR?, etc. forces the programmer to specify the types
of values he/she expects the given function to return and consequently
informs the reader of this information''.
This is only true if the function is expected to return several different
kinds of values (otherwise, the test would not be necessary and thus would
not appear). The kinds of tests used now are precisely the same as this.
Every time I say (if (foo) (bar) (baz)), in your system I might just say
(if (false? (foo)) (baz) (bar)). This doesn't tell you any more than the
other. When I use PAIR?, you only know that pairs are one of the
possibilities; you have no notion of the other possibilities. In current
Scheme, when I say (if (foo) ...) you know that #f is one of the
possibilities. This seems symmetric to me. I see no reason to prefer the
type of pairs over the type containing only #f.
Pavel
∂01-Feb-89 2125 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu apology for flamage concerning WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:25:29 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 22:40:30 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 16:13:32 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 16:13:23 PDT
Date: Wed, 1 Feb 89 16:13:23 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902020013.AA16093@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: apology for flamage concerning WITH-INPUT-FROM-PORT etc
Please disregard my earlier flamage concerning WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT. I was just moby confused, having somehow gotten it
deeply wedged into my brain that these procedures were replacing
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE when they are really
replacing WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE. The proposed
procedures are clearly superior to the ones they replace, and the only
possible question is whether this particular bit of functionality, which
was optional in R3RS, should go into the IEEE standard.
I certainly favor making this change in R4RS.
Please accept my apologies for thoughtlessly polluting this mailing list
with nonsense.
Peace, William Clinger
P.S. with regard to whether vector constants should have to be quoted:
As things stand now, implementations are free to allow unquoted vector
constants, and several do. Does the recent discussion mean that this
this feature is causing so many portability problems that it should be
required of all implementations?
∂01-Feb-89 2136 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:35:46 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 22:43:34 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 10:48:42 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 2146 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:45:57 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 22:45:21 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 08:42:56 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 2156 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu WITH-INPUT-FROM-PORT etc
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:55:58 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 1 Feb 89 22:46:10 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Wed, 1 Feb 89 09:18:40 PDT
Received: by fog.cs.uoregon.edu; Wed, 1 Feb 89 08:42:49 PDT
Date: Wed, 1 Feb 89 08:42:49 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8902011642.AA14330@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
Subject: WITH-INPUT-FROM-PORT etc
Date: Tue, 31 Jan 89 13:46:07 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
I am uncomfortable with the proposed WITH-INPUT-FROM-PORT and
WITH-OUTPUT-TO-PORT procedures. One reason the R3RS did not specify a
way to change the default ports is that some people do not want them to
be changable. Furthermore the implementation-dependent behavior of
these new procedures is a serious problem because they muck with a
global resource: the default ports....
Date: Tue, 31 Jan 89 20:51:41 EST
From: cph@murren.ai.mit.edu (Chris Hanson)
This shouldn't be an issue. The procedures `with-input-from-file' and
`with-output-to-file' already do this kind of binding. What we're
suggesting isn't new functionality, but a subset of existing
functionality: we want the binding part of `with-...-file' separately
from the file-opening part.
Right. I was confused. But now that I'm not, I'm more concerned than
before. WITH-INPUT-FROM-FILE and WITH-OUTPUT-TO-FILE are not essential,
precisely because they are not well-defined. Historically, their presence
in R3RS at all was a grudging concession to MIT Scheme. On the other hand,
CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE are well-defined and essential.
I do not see why IEEE Scheme should drop well-defined, essential procedures in
favor of ill-defined procedures that don't even appear in R3RS, even if the
new procedures resemble two non-essential and ill-defined R3RS procedures.
Peace, Will
∂01-Feb-89 2209 @MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu with-input-from-file and co.
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 22:09:52 PST
Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 1 Feb 89 23:44:08 EST
Received: by iuvax.cs.indiana.edu
Date: Wed, 1 Feb 89 23:24:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: scheme-standard@wheaties.ai.mit.edu
Subject: with-input-from-file and co.
Cc: rrrs-authors@mc.lcs.mit.edu
I have never felt that "with-input-from-file" and "with-output-to-file"
were a good thing, and I would like to see them flushed from R4RS.
Whether or not this happens, I would certainly rather see them omitted
from the standard. This goes for the proposed "with-input-from-port"
and "with-output-to-port" procedures as well. I don't think that it is
a good idea to encourage rebinding of these ports, especially if we are
not going to specify what happens when an escape procedure is invoked.
It would mean that every independent subcomputation that may need to
read from or write to the original ports would have to stash a copy of
the port for itself to use explicitly. Bugs resulting from this sort
of problem are difficult to track down ... especially for those in the
habit of adding "print" statements for debugging purposes.
∂01-Feb-89 2230 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #59
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 22:30:14 PST
Date: 2 FEB 89 00:04:16 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #59
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #59 2 FEB 89 00:04:16 EST
Today's Topics:
Scheme pretty printer
xscheme again...
unix xscheme
----------------------------------------------------------------------
Date: Wed, 1 Feb 89 15:55:10 est
From: gjc%bucsf.BU.EDU@bu-it.bu.edu (George J. Carrette)
Message-Id: <8902012055.AA11642@bucsf>
Subject: Scheme pretty printer
Pace Willison actually did quite a nice scheme pretty printer while
at the now-defunct LispMachineInc. He was modeling the thing after
the famous ITS @ATSIGN program listing generator, and had it
generating cross references and bold fonts and everything.
I think the code produced a DVI file directly, and was written in
lispmachine lisp.
The purpose was to generate listings of the compiler from the Yale T system,
suitable for reading while in the head. It did a good job at that.
Maybe somebody can reach him at BBN and find out if he has a copy.
-gjc
------------------------------
Date: 1 Feb 89 19:58:03 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: xscheme again...
Message-Id: <6555@polya.Stanford.EDU>
I've had a numerous requests for documentation, explanation etc.
re xscheme. I suppose I should have included all standard
disclaimers in my original posting... well, here goes:
I am in no way involved in the development or support of
xscheme. I'm simply making it ftp available so that some
kind soul will do the unix port so that I can use it
on my unix machine. As far as I know, Dave Betz is the person
responsible - he's accessible via BYTE magazine or on BIX.
As to documentation, there seems to be nothing around.
A couple of people have already mailed me a unix compatibility source
file - I'll take a look and either bundle one of them with
xscheme.tar.Z or just include them all and let you decide.
--ilan
------------------------------
Date: 2 Feb 89 00:25:37 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: unix xscheme
Message-Id: <6573@polya.Stanford.EDU>
I've created a new xscheme.tar.Z for anonymous ftp on
labrea.stanford.edu. This one includes unix compatibility files that
originate with Dave Betz. Many thanks to David MacKenzie for sending
them to me.
I haven't tried them out yet - but he says they seem to work fine on
vanilla System V.
As to documentation, if someone wants to come up with at least a
brief functional description plus a list of procedure names, that
would be a Good Thing.
--ilan
P.S. I suppose I should say the MIT Cscheme is also available from
various locations, not least from MIT itself. I use it on machines
that already have it, but downloading a uuencoded version of it over a
slow phone line to my home box is not a viable proposition. (uucp is
a dirty word around here apparently).
------------------------------
End of Scheme Digest
********************
∂02-Feb-89 1054 @MC.LCS.MIT.EDU:andy@polya.Stanford.EDU Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 10:54:38 PST
Received: from polya.Stanford.EDU (TCP 4402000240) by MC.LCS.MIT.EDU 2 Feb 89 13:39:38 EST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA02726; Thu, 2 Feb 89 10:40:06 -0800
Date: Thu, 2 Feb 89 10:40:06 -0800
From: Andy Freeman <andy@polya.Stanford.EDU>
Message-Id: <8902021840.AA02726@polya.Stanford.EDU>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Pavel.pa@Xerox.COM's message of Wed, 01 Feb 89 17:28:09 PST <890201-172921-11917@Xerox>
Subject: Quoting vectors?
Pavel writes:
>I see no reason to force all Scheme programmers to write logically
>unnecessary quotes in order to allow this obscure and, to my knowledge,
>rarely if ever employed, avenue for experimentation.
It turns out that I defined and played with a parallel scheme that
used vectors instead of lists almost everywhere.
Another way of looking at this question is by counting the number of
rules required to figure out whether or not a quote is necessary. I
personally favor required quotes on all data objects with strings and
numbers as special cases because of historical reasons (and '" looks
dumb). This not only means that we can decide later how to determine
the value of something that currently only has a data syntax, but that
the rules for finding non-data, is it quoted, are quite simple.
Of course, one could argue that the opposite view, that quotation is a
hack to make up for the unfortunate fact that lists and symbols use
the same syntax as expressions and variables. I don't like this
because it makes quasi-quote into another hack, and I don't think that
either quasi-quote or quote are hacks. It also means that we're tied
into the current syntax for non-data and everything else is data,
which is a little more complicated than the current rule.
(BTW - I wonder if an individual's views on required quotes correlates
with their views on the truth values.)
-andy
∂02-Feb-89 1303 @MC.LCS.MIT.EDU,@LCS.MIT.EDU:cph@kleph.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 13:03:09 PST
Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Feb 89 15:38:44 EST
Received: from kleph.ai.mit.edu ([18.43.0.172]) by XX.LCS.MIT.EDU with TCP/SMTP; Thu 2 Feb 89 15:36:54-EST
Received: by kleph.ai.mit.edu (5.59/1.5)
id AA00381; Thu, 2 Feb 89 14:09:27 EST
Date: Thu, 2 Feb 89 14:09:27 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8902021909.AA00381@kleph.ai.mit.edu>
To: andy@polya.Stanford.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Andy Freeman's message of Thu, 2 Feb 89 10:40:06 -0800 <8902021840.AA02726@polya.Stanford.EDU>
Subject: Quoting vectors?
Reply-To: cph@zurich.ai.mit.edu
Date: Thu, 2 Feb 89 10:40:06 -0800
From: Andy Freeman <andy@polya.Stanford.EDU>
Of course, one could argue that the opposite view, that quotation is a
hack to make up for the unfortunate fact that lists and symbols use
the same syntax as expressions and variables. I don't like this
because it makes quasi-quote into another hack, and I don't think that
either quasi-quote or quote are hacks.
Actually, if you look into this a little (I'd suggest talking to John
Lamping) it becomes pretty obvious that they are both hacks. Fixing
it, unfortunately, requires some pretty serious changes to the
language.
∂02-Feb-89 1348 @MC.LCS.MIT.EDU,@LCS.MIT.EDU:jinx@chamartin.ai.mit.edu Quoting vectors?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 13:48:37 PST
Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Feb 89 16:36:45 EST
Received: from chamartin.ai.mit.edu by XX.LCS.MIT.EDU with TCP/SMTP; Thu 2 Feb 89 16:37:41-EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
id AA06704; Thu, 2 Feb 89 16:33:43 EST
Date: Thu, 2 Feb 89 16:33:43 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902022133.AA06704@chamartin.ai.mit.edu>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.EDU
In-Reply-To: Pavel.pa@Xerox.COM's message of Wed, 01 Feb 89 14:55:40 PST <890201-145551-11497@Xerox>
Subject: Quoting vectors?
Reply-To: jinx@zurich.ai.mit.edu
Sussman says that he ``cannot remember ever trying to use bare () in a
program''. The only explanation I can give for this is the fact that the
initial value of NIL is #f and that, in C-Scheme, #f and () are identical.
NIL is not bound by default in C-Scheme. GJS, like many other MIT
Scheme programmers, including myself, use "'()" or "#f" (even "'#f")
depending on intent. The C Scheme reader happens to read them as
the same object, but that does not mean that the user knowingly or
intentionally depended on that fact for his program to work.
∂02-Feb-89 1359 @MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 13:59:24 PST
Received: from chamartin.ai.mit.edu (TCP 2212600253) by MC.LCS.MIT.EDU 2 Feb 89 16:42:56 EST
Received: by chamartin.ai.mit.edu (5.59/1.5)
id AA06699; Thu, 2 Feb 89 16:28:34 EST
Date: Thu, 2 Feb 89 16:28:34 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902022128.AA06699@chamartin.ai.mit.edu>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Wed, 1 Feb 89 17:32 EST <19890201223223.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU>
Subject: truth of '()
Reply-To: jinx@zurich.ai.mit.edu
I don't recall that we have any consensus for eventually declaring that
implementations -must- have distinct () and #F objects. My understanding
is that making the boolean significance of () unspecified is to accommodate
implementations in which they are distinct, where it might be inconvenient
to arrange for () to be false.
I agree completely with Alan. I might encourage implementors and
dialect designers to distinguish () and #f. I might even distinguish
them myself if I were designing a new dialect, but I would never agree
to forcing them to be distinct.
∂02-Feb-89 1618 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu rrrs-authors vs. scheme-standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 16:18:03 PST
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 2 Feb 89 19:11:43 EST
Received: by void.ai.mit.edu (5.59/1.5)
id AA12855; Thu, 2 Feb 89 19:15:45 EST
Date: Thu, 2 Feb 89 19:15:45 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902030015.AA12855@void.ai.mit.edu>
To: andy@ads.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Andy Cromarty's message of Wed, 1 Feb 89 10:01:58 PST <8902011801.AA05206@ads.com>
Subject: rrrs-authors vs. scheme-standard
Reply-To: jar@zurich.ai.mit.edu
Date: Wed, 1 Feb 89 10:01:58 PST
From: Andy Cromarty <andy@ads.com>
... It seems that scheme-standard and rrrs-authors are being used
almost interchangeably; in fact, several discussions have seemed to
bleed over from one list to the other in mid-debate as if the
distinction does not exist. To the extent that you still are
active in managing the rrrs-authors list, can you comment (perhaps
publicly) on proper use of the lists or their composition? Perhaps
there's near-total overlap and it doesn't matter which we use, for
example (even that would be useful information).
Rrrs-authors is an informal anarchic non-public discussion of what is
supposed to go into the next Scheme report. Scheme-standard is for
discussing the IEEE Scheme standard, which is supposed to be "based on
the Scheme report". The IEEE group decided at its first meeting not
to do language design. In principle there should be no overlap
between the subject material for the two lists.
If the IEEE group wants to do anything other than subset the report,
then I expect it will submit its proposals to rrrs-authors for
discussion. People who would desire to add any kind of new feature
(to choose one example at random: allowing the empty list to be
considered true) to the IEEE dialect should direct their proposals to
rrrs-authors, not scheme-standard, so that they can be considered for
the language on which the IEEE document is supposed to be based. When
in doubt, send to rrrs-authors, or, if you're not on rrrs-authors, to
the Scheme list.
The editors of the IEEE draft standard have some small changes that
they would like to propose for the report. Not to worry; those
changes will be forwarded to the rrrs-authors list in due time.
Of course, subsetting discussions can be quite heated, as those who
are on the scheme-standard list have recently observed.
∂02-Feb-89 2126 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #60
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 21:26:19 PST
Date: 3 FEB 89 00:04:23 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #60
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #60 3 FEB 89 00:04:23 EST
Today's Topics:
emacs and xscheme
xscheme documentation
vgrind vgrindef and Scheme
----------------------------------------------------------------------
Date: 2 Feb 89 03:49:19 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: emacs and xscheme
Message-Id: <6576@polya.Stanford.EDU>
Well, xscheme compiles and runs at least on Ultrix and System V so far.
Now if someone could explain the mysteries of emacs inferior processes
and tell us how to get emacs to interact with xscheme.
M-x run-scheme in fact runs an xscheme subprocess - but fails to send
anything to it. My emacs has no such problem with Cscheme - hence
I suspect xscheme.
Any guesses?
--ilan
------------------------------
Date: 2 Feb 89 04:56:00 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: xscheme documentation
Message-Id: <6577@polya.Stanford.EDU>
David MacKenzie mailed me the canonic xscheme documentation, I've
bundled it up with xscheme.tar.Z on labrea.
A NOTE FROM THE AUTHOR
If you have any problems with XScheme, feel free to contact me
for help or advice. Please remember that since XScheme is
available in source form in a high level language, many users
have been making versions available on a variety of machines.
If you call to report a problem with a specific version, I may
not be able to help you if that version runs on a machine to
which I don't have access. Please have the version number of
the version that you are running readily accessible before
calling me.
If you find a bug in XScheme, first try to fix the bug yourself
using the source code provided. If you are successful in fixing
the bug, send the bug report along with the fix to me. If you
don't have access to a C compiler or are unable to fix a bug,
please send the bug report to me and I'll try to fix it.
Any suggestions for improvements will be welcomed. Feel free to
extend the language in whatever way suits your needs. However,
PLEASE DO NOT RELEASE ENHANCED VERSIONS WITHOUT CHECKING WITH ME
FIRST!! I would like to be the clearing house for new features
added to XScheme. If you want to add features for your own
personal use, go ahead. But, if you want to distribute your
enhanced version, contact me first.
I'm also posting Dave Betz's email address here under the assumption
that he really means it when he says: "...please send the bug report
to me and I'll try to fix it". It's: zinn!mipsmag!dbetz@decvax.dec.com
(If that's a faux pas then my hand is available for slapping).
--ilan
------------------------------
Date: 2 Feb 89 14:53:38 GMT
From: mailrus!pan!jal@ohio-state.arpa (Jason Leigh)
Subject: vgrind vgrindef and Scheme
Message-Id: <495@pan>
Does anyone know what all the weird symbols in the vgrindef file mean?
I want to write a definition for vgrind to process Scheme source
code. Any hints?
Also is there a Scheme pretty-printer that will maintain cases; the pp
on MIT-Scheme puts everything in Uppercase.
Thanks.
------------------------------
End of Scheme Digest
********************
∂04-Feb-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #61
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 89 21:22:01 PST
Date: 5 FEB 89 00:04:53 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #61
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #61 5 FEB 89 00:04:53 EST
Today's Topics:
emacs and xscheme
X11R3 for MIT C-Scheme 6.1?
----------------------------------------------------------------------
Date: Sat, 4 Feb 89 00:24:53 EST
From: jinx@chamartin.ai.mit.edu (Guillermo J. Rozas)
Message-Id: <8902040524.AA07309@chamartin.ai.mit.edu>
Subject: emacs and xscheme
Reply-To: jinx@zurich.ai.mit.edu
M-x run-scheme in fact runs an xscheme subprocess - but fails to send
anything to it. My emacs has no such problem with Cscheme - hence
I suspect xscheme.
If you are using GNU Emacs and a reasonably recent version of MIT
CScheme, the interface code in your Emacs may not work with anything
else but your version of CScheme. There is some form of handshake
between GNU Emacs and CScheme, which presumably is not implemented by
xscheme. This would probably prevent them from working together.
------------------------------
Date: 4 Feb 89 06:20:50 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!ists!mike@ohio-state.arpa (Mike Clarkson)
Subject: X11R3 for MIT C-Scheme 6.1?
Message-Id: <362@ists.ists.ca>
Does anyone have the patches for MIT C-Scheme to make it run
with X11 R3? If so, I'd appreciate getting a copy.
Many thanks in advance,
Mike.
--
Mike Clarkson mike@ists.UUCP
Institute for Space and Terrestrial Science mike@ists.ists.ca
York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3 +1 (416) 736-5611
------------------------------
End of Scheme Digest
********************
∂07-Feb-89 1319 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU truth of '()
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:19:43 PST
Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 7 Feb 89 16:12:24 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA01849; Tue, 7 Feb 89 12:34:35 PST
Date: Tue, 7 Feb 89 12:34:35 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8902072034.AA01849@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Wed, 01 Feb 89 17:06:06 PST <890201-170617-11852@Xerox>
Subject: truth of '()
Date: Wed, 01 Feb 89 17:06:06 PST
From: Pavel.pa@Xerox.COM
Morry says, ``use of PAIR?, etc. forces the programmer to specify the types
of values he/she expects the given function to return and consequently
informs the reader of this information''.
This is only true if the function is expected to return several different
kinds of values (otherwise, the test would not be necessary and thus would
not appear). The kinds of tests used now are precisely the same as this.
Every time I say (if (foo) (bar) (baz)), in your system I might just say
(if (false? (foo)) (baz) (bar)). This doesn't tell you any more than the
other. When I use PAIR?, you only know that pairs are one of the
possibilities; you have no notion of the other possibilities. In current
Scheme, when I say (if (foo) ...) you know that #f is one of the
possibilities. This seems symmetric to me. I see no reason to prefer the
type of pairs over the type containing only #f.
Pavel
The problem is that as things currently stand false is not a given object or
type, but actually a set composed of #f, '(), and maybe something else in some
implementations. Furthermore, I can only repeat my statement that TO ME it is
much clearer when code uses the NULL? and FALSE? predicates, then when it does
not. (I guess you just can't account for taste, but thats mine.)
Morry Katz
katz@polya.stanford.edu
∂07-Feb-89 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #62
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 21:54:29 PST
Date: 8 FEB 89 00:07:11 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #62
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #62 8 FEB 89 00:07:11 EST
Today's Topics:
Scheme object oriented support
----------------------------------------------------------------------
Date: 5 Feb 89 14:45:49 GMT
From: mailrus!pan!jal@ohio-state.arpa (Jason Leigh)
Subject: Scheme object oriented support
Message-Id: <502@pan>
Is there an object oriented support package (like CLOS) for Scheme
that is readily ftp-able?
Also the R↑3 MIT-Scheme manual does not seem to want to reveal
the use of macros on their system (for obvious reasons), does anyone
have any information on how to use them?
Thanks.
Jason Leigh
------------------------------
End of Scheme Digest
********************
∂08-Feb-89 2037 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com Portability
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 20:37:44 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 8 Feb 89 23:12:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa20621; 8 Feb 89 18:17 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa16772; 8 Feb 89 18:09 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA01162; Wed, 8 Feb 89 11:55:22 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA18580; Wed, 8 Feb 89 11:53:35 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA01156; Thu, 9 Feb 89 11:55:49 pst
Message-Id: <8902091955.AA01156@bloom.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Portability
Date: Thu, 09 Feb 89 11:55:47 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET
POSITION:
One of Scheme's many strengths is its clear definition. The use of
denotation semantics makes it possible to provably implement the same
semantics on very different CPU architectures. By its nature, Scheme
should be the most portable of languages. Indeed, standard Scheme
programs are typically ported between implementations with the same
source code and a small compaibility file.
The number of implementations is rapidly growing. Not having a
standard library interface and not having a way to define a single
compaibility file across a large number of implementations will
shortly be a major impediment to portability.
For a moderately large and complex `program' to be portable, there
must be a baseline functionality. Typically there will be a gap
between this baseline and the IEEE (minimalist) standard. In order to
be able to use definitions provided by an implementation, there needs
to be a way to query implementations about environmental differences
(eg: implementation+version, OS, FS, CPU, ...) and a way to
non-intrusively add definitions--including commonly used syntactic
idioms (when, unless, ...) and optimizations (define-constant <->
define; define-integrable <-> define; herald <-> comment; error <->
cerror; ...).
Let me give an example. Here is a definition which maps a
machine/implementation specific function to an implementation independent
one. Note that--as defined--all of this code gets compiled, although we
only need one of the lambda bindings. We can get around this using
syntax/macros, but that is currently not portable!
(define %draw-point ; args: (x y color)
(case <scheme-implementation>
((PCScheme) (lambda (x y color) (%graphics 1 x y color 0 0 0)))
((MacScheme) (lambda (x y ignored) (draw-point x y)))
((T) ...)
((CScheme) ...)
((Skim) ...)
((XScheme) (case <OS> ...) ...)
((AmigaScheme) ...)
...
(else (error "unrecognized scheme implementation"
<scheme-implementation>))
) )
In addition, there is the problem of augmenting what is absent in a
non-intrusive way. Something along the lines of:
(define-if-needed (foo . args) body)
==> (unless (defined? foo)
(define-in-enclosing-env (foo . args) body))
It would be nice to define an ERROR function for programatic recovery as
well as a special form (`CERROR' ?) which captures state for interactive
debugging. It would be helpful to have a suggested interface for functions
which may be implemented but are not required (e.g. TIME should--if defined--
return the clock time in the same format for all implementations).
Anyway, it seems to me that a lot of work needs to be done here. If done
well, we will get portable code. If not done, we can have a real mess.
I will be happy to track proposals in this area.
Comments? I'm sure there are comments!
-Ken kend@mrloog.LA.TEK.COM
∂08-Feb-89 2215 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #63
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 22:14:59 PST
Date: 9 FEB 89 00:10:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #63
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #63 9 FEB 89 00:10:32 EST
Today's Topics:
Scheme->C compiler tech report
Scheme mailing list
C-Scheme name completion for GNU Emacs
xscheme
----------------------------------------------------------------------
Message-Id: <8902072137.AA05739@saturn.pa.dec.com>
Subject: Scheme->C compiler tech report
Date: Tue, 07 Feb 89 13:37:35 -0800
From: bartlett@decwrl.dec.com
A tech report describing a Scheme-to-C compiler done at Digitial's Western
Research Laboratory is now available. To inspect the abstract or order a copy,
send a mail message to:
Digital E-net: DECWRL::WRL-TECHREPORTS
DARPA Internet: wrl-techreports@decwrl.dec.com
CSnet: wrl-techreports@decwrl.dec.com
UUCP: decwrl!wrl-techreports
Include the word "help" in the subject line and the server will return
instructions.
jfb
------------------------------
From: <gabriel@ATHENA.MIT.EDU>
Message-Id: <8902081849.AA00808@M11-113-3.MIT.EDU>
Subject: Scheme mailing list
Date: Wed, 08 Feb 89 13:49:34 EST
I have been receiving mail from a scheme mailing list directed to your
name. Would you be able to remove me from this mailing list (I'm
not sure how I got on it).
Thanks,
Rob Grace
------------------------------
Date: 7 Feb 89 18:30:46 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!ists!mike@csd4.milw.wisc.edu (Mike Clarkson)
Subject: C-Scheme name completion for GNU Emacs
Message-Id: <363@ists.ists.ca>
Loading this file gives C-Scheme command completion, so that M-TAB
completes the word before the cursor to a Scheme command. I usually
have this set for any Scheme-mode window, and I define the interactive
command scheme to set up the shell buffer ready for scheme.
It also sets up the tags-file-name to the TAGS file in my Scheme source
directory, so I can do M-. tags searches.
You will have to change the values of tags-file-name and shell-prompt-pattern
to suit you site.
;;; scheme-complete.el
;; Mike Clarkson (mike@ists.ists.ca) - January 1989
;;
;; I put something like
;
;; (autoload 'process-send-ca "scheme-complete" "Send a ↑C↑A in shell mode" t)
;; (autoload 'process-send-cg "scheme-complete" "Send a ↑C↑G in shell mode" t)
;; (autoload 'scheme-complete-symbol "scheme-complete"
;; "Complete a Scheme command in shell mode" t)
;;
;; (defun scheme ()
;; (interactive)
;; (setq tags-file-name "/usr1/ai/scheme/mit/TAGS")
;; (setq shell-prompt-pattern "↑[0-9]+ .*%[=---]+> ")
;; (shell)
;; (define-key shell-mode-map "\C-c\C-a" 'process-send-ca)
;; (define-key shell-mode-map "\C-c\C-g" 'process-send-cg)
;; (define-key shell-mode-map "\e\C-i" 'scheme-complete-symbol)
;; )
;;
;; (setq scheme-mode-hook
;; '(lambda ()
;; (define-key scheme-mode-map "\e\C-i" 'scheme-complete-symbol))
;; )
;;
;; in my ~/.emacs and say M-x scheme when I want to program
;
; in the shell buffer in scheme. This gives me scheme command completion,
;;;; and the ability to send ↑A or ↑G in the shell mode (using ↑C↑A and ↑C↑G).
;; It also adds scheme command completion to Scheme mode.
(defun process-send-ca ()
(interactive)
(process-send-string
(get-buffer-process (current-buffer)) "\C-a"))
(defun process-send-cg ()
(interactive)
(process-send-string
(get-buffer-process (current-buffer)) "\C-g"))
(defun scheme-complete-symbol ()
"Perform completion on the Scheme symbol preceding point.
That symbol is compared against the symbols that exist in the Scheme
obarray, and any additional characters determined by what is there
are inserted. All symbols with function definitions, values
or properties are considered."
(interactive)
(let* ((end (point))
(beg (save-excursion
(backward-sexp 1)
(while (= (char-syntax (following-char)) ?\')
(forward-char 1))
(point)))
(pattern (buffer-substring beg end))
(completion (try-completion pattern *scheme-obarray*)))
(cond ((eq completion t))
((null completion)
(message "Can't find completion for \"%s\"" pattern)
(ding))
((not (string= pattern completion))
(delete-region beg end)
(insert completion))
(t
(message "Making completion list...")
(let ((list (all-completions pattern *scheme-obarray*)))
(with-output-to-temp-buffer "*Help*"
(display-completion-list list)))
(message "Making completion list...%s" "done")))))
(setq *scheme-obarray*
(mapcar 'list '(
"%cd" "%exit" "%ge" "%gst" "%in" "%out" "%pwd" "%ve" "%ve-prompt" "%vst"
"&list-to-vector" "&pair-car" "&pair-cdr" "&pair-set-car!"
"&pair-set-cdr!" "&singleton-element" "&singleton-set-element!"
"&subvector-to-list" "&triple-first" "&triple-second" "&triple-set-first!"
"&triple-set-second!" "&triple-set-third!" "&triple-third"
"&typed-pair-cons" "&typed-singleton-cons" "&typed-triple-cons"
"&typed-vector-cons" "&vector-ref" "&vector-size" "&vector-to-list" "*"
"*args*" "*current-input-port*" "*current-output-port*" "*fluid-let-type*"
"*parser-radix*" "*parser-table*" "*proc*" "*rep-base-environment*"
"*rep-base-input-port*" "*rep-base-output-port*" "*rep-base-prompt*"
"*rep-base-syntax-table*" "*rep-current-environment*"
"*rep-current-input-port*" "*rep-current-output-port*"
"*rep-current-prompt*" "*rep-current-syntax-table*" "*rep-error-hook*"
"*rep-keyboard-map*" "*result*" "*the-non-printing-object*"
"*unparser-list-breadth-limit*" "*unparser-list-depth-limit*"
"*unparser-radix*" "+" "-" "-1+" "->pathname" "/" "1+" "2d-get"
"2d-get-alist-x" "2d-get-alist-y" "2d-put!" "2d-remove!" "<" "<=" "=" ">"
">=" "abort->nearest" "abort->previous" "abort->top-level"
"abort-to-nearest-driver" "abort-to-previous-driver"
"abort-to-top-level-driver" "abs" "access" "access-components"
"access-environment" "access-name" "access-type" "access\?" "acos"
"add-event-receiver!" "add-gc-daemon!" "add-secondary-gc-daemon!"
"add-system!" "add-to-population!" "advice" "advice-package"
"advise-entry" "advise-exit" "and" "angle" "append!" "append" "apply"
"ascii->char" "asin" "assignment-components"
"assignment-components-with-variable" "assignment-name" "assignment-type"
"assignment-value" "assignment-variable" "assignment\?" "assoc"
"association-procedure" "assq" "assv" "atan" "beep" "begin"
"bit-string->signed-integer" "bit-string->unsigned-integer"
"bit-string-allocate" "bit-string-and!" "bit-string-andc!"
"bit-string-append" "bit-string-append-reversed" "bit-string-clear!"
"bit-string-fill!" "bit-string-length" "bit-string-move!"
"bit-string-movec!" "bit-string-or!" "bit-string-ref" "bit-string-set!"
"bit-string-xor!" "bit-string-zero\?" "bit-string=\?" "bit-string\?"
"bit-substring" "bit-substring-find-next-set-bit"
"bit-substring-move-right!" "bkpt" "block-declaration-text"
"block-declaration\?" "boolean\?" "break" "break-both" "break-entry"
"break-exit" "breakpoint" "breakpoint-procedure" "breakpoint-prompt"
"caaaar" "caaadr" "caaar" "caadar" "caaddr" "caadr" "caar" "cadaar"
"cadadr" "cadar" "caddar" "cadddr" "caddr" "cadr"
"call-with-current-continuation" "call-with-input-file"
"call-with-output-file" "canonicalize-input-filename"
"canonicalize-output-filename" "car" "case" "cdaaar" "cdaadr" "cdaar"
"cdadar" "cdaddr" "cdadr" "cdar" "cddaar" "cddadr" "cddar" "cdddar"
"cddddr" "cdddr" "cddr" "cdr" "ceiling" "cell-contents" "cell-type"
"cell\?" "char->ascii" "char->digit" "char->integer" "char->name"
"char->string" "char-alphabetic\?" "char-alphanumeric\?" "char-ascii\?"
"char-bits" "char-bits-limit" "char-ci->integer" "char-ci<=\?"
"char-ci<\?" "char-ci=\?" "char-ci>=\?" "char-ci>\?" "char-code"
"char-code-limit" "char-downcase" "char-graphic\?" "char-integer-limit"
"char-lower-case\?" "char-numeric\?" "char-ready\?" "char-set"
"char-set-difference" "char-set-intersection" "char-set-invert"
"char-set-member\?" "char-set-members" "char-set-predicate"
"char-set-union" "char-set:alphabetic" "char-set:alphanumeric"
"char-set:graphic" "char-set:lower-case" "char-set:not-whitespace"
"char-set:numeric" "char-set:standard" "char-set:upper-case"
"char-set:whitespace" "char-set\?" "char-standard\?" "char-upcase"
"char-upper-case\?" "char-whitespace\?" "char:newline" "char<=\?"
"char<\?" "char=\?" "char>=\?" "char>\?" "char\?" "chars->ascii"
"circular-list" "close-all-open-files" "close-input-port"
"close-output-port" "code->char" "coerce-to-environment"
"combination-components" "combination-operands" "combination-operator"
"combination-size" "combination-type" "combination\?" "comment-components"
"comment-expression" "comment-text" "comment-type" "comment\?"
"common-lisp-fluid-let!" "compiled-code-address->block"
"compiled-code-address\?" "compiled-code-block/environment"
"compiled-procedure-entry" "compiled-procedure-environment"
"compiled-procedure-type" "compiled-procedure\?" "complex\?"
"compound-procedure-type" "compound-procedure\?" "cond"
"conditional-alternative" "conditional-components" "conditional-consequent"
"conditional-predicate" "conditional-type" "conditional\?" "cons" "cons*"
"cons-stream" "console-input-port" "console-output-port"
"continuation-annotation" "continuation-dynamic-state"
"continuation-environment" "continuation-evaluated-object-value"
"continuation-evaluated-object\?" "continuation-expression"
"continuation-fluid-bindings" "continuation-next-continuation"
"continuation-package" "continuation-reductions" "continuation-return-code"
"continuation-type" "continuation-undefined-environment\?"
"continuation-undefined-expression\?" "continuation\?" "continue-rep"
"copy-file" "copy-pathname" "copy-syntax-table" "cos"
"current-dynamic-state" "current-input-port" "current-output-port"
"current-unsyntax-table" "date" "date->string" "debug" "debugger-package"
"declaration-components" "declaration-expression" "declaration-text"
"declaration-type" "declaration\?" "declare" "deep-fluid-let!" "define"
"define-macro" "define-syntax" "definition-components" "definition-name"
"definition-type" "definition-value" "definition\?" "defstruct-package"
"del-assoc!" "del-assoc" "del-assq!" "del-assq" "del-assv!" "del-assv"
"delay" "delay-components" "delay-expression" "delay-type" "delay\?"
"delayed-evaluation-environment" "delayed-evaluation-expression"
"delayed-evaluation-forced\?" "delayed-evaluation-value" "delayed\?"
"delete!" "delete" "delete-association-procedure" "delete-file"
"delete-member-procedure" "delq!" "delq" "delv!" "delv" "digit->char"
"disable-scan-defines!" "disjunction-alternative" "disjunction-components"
"disjunction-predicate" "disjunction-type" "disjunction\?" "disk-restore"
"disk-save" "display" "do" "dump-world" "dynamic-wind" "eighth"
"emacs-interface-package" "empty-stream\?" "enable-scan-defines!"
"entry-advice" "environment-arguments" "environment-bindings"
"environment-extension-aux-list" "environment-extension-procedure"
"environment-extension\?" "environment-has-parent\?"
"environment-package" "environment-parent" "environment-procedure"
"environment-type" "environment-warning-hook" "environment\?" "eof-object"
"eof-object\?" "eq\?" "equal\?" "eqv\?" "error"
"error-combination-type" "error-from-compiled-code" "error-irritant"
"error-message" "error-procedure" "error-prompt" "error-system" "eval"
"even\?" "event-distributor\?" "event:after-restart"
"event:after-restore" "exact->inexact" "exact\?" "except-last-pair!"
"except-last-pair" "execute-at-new-state-point" "exists-an-inhabitant\?"
"exit-advice" "exp" "expt" "extend-syntax-table" "false" "false-procedure"
"false-type" "false\?" "fasdump" "fasload" "fifth" "file-exists\?"
"final-segment" "first" "fix:*" "fix:+" "fix:-" "fix:-1+" "fix:1+" "fix:<"
"fix:=" "fix:>" "fix:divide" "fix:gcd" "fix:negative\?" "fix:positive\?"
"fix:quotient" "fix:remainder" "fix:zero\?" "fixed-objects-vector-slot"
"floor" "fluid-let" "for-all-inhabitants\?" "for-all\?" "for-each"
"force" "format" "fourth" "full-quit" "future\?"
"garbage-collector-package" "gc-flip" "gc-history-mode" "gc-statistics"
"gc-statistics-package" "gcd" "gctime" "general-car-cdr"
"generate-uninterned-symbol" "get-fixed-objects-vector" "hash" "head"
"history-package" "home-directory-pathname" "identify-system"
"identify-world" "identity-procedure" "if" "imag-part"
"implementation-dependencies" "implemented-primitive-procedure\?"
"impurify" "in-package" "in-package-components" "in-package-environment"
"in-package-expression" "in-package-type" "in-package\?" "inexact->exact"
"inexact\?" "init-file-pathname" "initial-segment" "input-port-tag"
"input-port\?" "integer->char" "integer-divide" "integer-divide-quotient"
"integer-divide-remainder" "integer-expt" "integer\?" "interrupt-mask-all"
"interrupt-mask-gc-ok" "interrupt-mask-none" "interrupt-system"
"keyboard-interrupt-dispatch-table" "lambda" "lambda-body" "lambda-bound"
"lambda-components" "lambda-components*" "lambda-components**"
"lambda-package" "lambda-pattern/name" "lambda-pattern/optional"
"lambda-pattern/required" "lambda-pattern/rest"
"lambda-tag:common-lisp-fluid-let" "lambda-tag:deep-fluid-let"
"lambda-tag:let" "lambda-tag:make-environment"
"lambda-tag:shallow-fluid-let" "lambda-tag:unnamed" "lambda-type"
"lambda\?" "last-pair" "lcm" "length" "let" "let*" "let-syntax" "letrec"
"lexical-assignment" "lexical-reference" "lexical-unassigned\?"
"lexical-unbound\?" "lexical-unreferenceable\?" "list" "list->string"
"list->vector" "list-copy" "list-deletor!" "list-deletor" "list-ref"
"list-search-negative" "list-search-positive" "list-tail"
"list-transform-negative" "list-transform-positive" "list\?" "load"
"load-noisily" "load-noisily\?" "load-system!" "local-assignment"
"local-declare" "log" "macro" "macro-spreader" "magnitude" "make-access"
"make-assignment" "make-assignment-from-variable" "make-bit-string"
"make-block-declaration" "make-cell" "make-char" "make-combination"
"make-command-loop" "make-comment" "make-conditional" "make-declaration"
"make-definition" "make-delay" "make-disjunction" "make-environment"
"make-event-distributor" "make-false" "make-in-package"
"make-initialized-vector" "make-interned-symbol"
"make-keyboard-interrupt-dispatch-table" "make-lambda" "make-lambda*"
"make-lambda**" "make-list" "make-name-generator" "make-named-tag"
"make-non-pointer-object" "make-null" "make-open-block" "make-pathname"
"make-polar" "make-population" "make-primitive-procedure" "make-quotation"
"make-rectangular" "make-rep" "make-return-address" "make-sequence"
"make-state-space" "make-string" "make-sub-type" "make-symbol"
"make-syntax-table" "make-the-environment" "make-true"
"make-type-dispatcher" "make-unassigned-object" "make-unassigned\?"
"make-unbound-object" "make-unbound\?" "make-union-type"
"make-unsyntax-table" "make-variable" "make-vector" "map" "map*"
"map-over-population!" "map-over-population" "map-reference-trap" "mapc"
"mapcan" "mapcan*" "mapcar" "mapcar*" "max" "max-reductions"
"max-subproblems" "measure-interval" "member" "member-procedure" "memq"
"memv" "merge-pathnames" "microcode-error" "microcode-identification-item"
"microcode-return" "microcode-system" "microcode-termination"
"microcode-termination-name" "microcode-type" "microcode-type-name"
"microcode-type-object" "microcode-type-predicate" "min" "modulo"
"name->char" "named-lambda" "negative-list-searcher"
"negative-list-transformer" "negative\?" "newline" "non-printing-object\?"
"non-reentrant-call-with-current-continuation" "not" "null-continuation\?"
"null-procedure" "null-type" "null\?" "number->string"
"number-of-external-primitive-procedures"
"number-of-internal-primitive-procedures" "number-of-microcode-errors"
"number-of-microcode-returns" "number-of-microcode-terminations"
"number-of-microcode-types" "number-parser-package" "number-type"
"number-unparser-package" "number\?" "object-hash" "object-type"
"object-unhash" "odd\?" "open-block-components" "open-block-type"
"open-block\?" "open-input-file" "open-output-file" "or" "output-port-tag"
"output-port\?" "pa" "package/scode-optimizer" "pair\?" "parse-pathname"
"parser-package" "parser-table-copy" "parser-table-entry"
"pathname->absolute-pathname" "pathname->input-truename"
"pathname->output-truename" "pathname->string" "pathname-absolute\?"
"pathname-as-directory" "pathname-components" "pathname-device"
"pathname-directory" "pathname-directory-path" "pathname-directory-string"
"pathname-extract" "pathname-extract-string" "pathname-name"
"pathname-name-path" "pathname-name-string" "pathname-new-device"
"pathname-new-directory" "pathname-new-name" "pathname-new-type"
"pathname-new-version" "pathname-newest" "pathname-type" "pathname-unparse"
"pathname-unparse-name" "pathname-version" "pathname\?" "peek-char"
"population\?" "positive-list-searcher" "positive-list-transformer"
"positive\?" "pp" "predicate->char-set" "primitive-datum" "primitive-io"
"primitive-procedure-arity" "primitive-procedure-name"
"primitive-procedure-type" "primitive-procedure\?" "primitive-set-type"
"primitive-type" "primitive-type\?" "print-gc-statistics"
"printer-history" "procedure-components" "procedure-environment"
"procedure-lambda" "procedure-package" "procedure-type" "procedure\?"
"proceed" "promise-type" "purify" "push-command-hook" "push-command-loop"
"push-rep" "quasiquote" "quit" "quotation-expression" "quotation-type"
"quotation\?" "quote" "quotient" "random" "randomize" "rational\?"
"raw-continuation->continuation" "raw-continuation\?" "read" "read-bits!"
"read-char" "read-char-no-hang" "read-eval-print" "read-file" "read-string"
"reader-history" "real-part" "real\?" "reference-trap-kind"
"reference-trap-kind-name" "reference-trap\?" "remainder"
"remove-event-receiver!" "remove-from-population!" "rename-file"
"rep-base-environment" "rep-base-prompt" "rep-base-syntax-table"
"rep-continuation" "rep-environment" "rep-input-port" "rep-level"
"rep-message-hook" "rep-output-port" "rep-prompt" "rep-prompt-hook"
"rep-state" "rep-syntax-table" "rep-value-hook" "replace-rep!"
"reset-keyboard-interrupt-dispatch-table!" "return-address-code"
"return-address-name" "return-address\?" "reverse!" "reverse" "round"
"runtime" "runtime-system" "save-world" "scan-defines"
"scheme-pretty-printer" "scode-constant\?" "scode-eval" "scode-quote"
"screen-clear" "second" "sequence" "sequence-actions" "sequence-components"
"sequence-type" "sequence\?" "set!" "set-assignment-value!"
"set-assignment-variable!" "set-car!" "set-cdr!" "set-cell-contents!"
"set-comment-expression!" "set-comment-text!"
"set-current-dynamic-state!" "set-current-unsyntax-table!"
"set-declaration-expression!" "set-declaration-text!"
"set-default-gc-safety-margin!" "set-definition-name!"
"set-definition-value!" "set-environment-extension-parent!"
"set-interrupt-enables!" "set-keyboard-interrupt-dispatch-table!"
"set-lambda-body!" "set-parser-table-entry!" "set-rep-base-environment!"
"set-rep-base-prompt!" "set-rep-base-syntax-table!"
"set-rep-environment!" "set-rep-prompt!" "set-rep-syntax-table!"
"set-string-length!" "set-symbol-global-value!"
"set-working-directory-pathname!" "seventh" "sf"
"sf/add-file-declarations!" "sf/set-file-syntax-table!" "sfu\?"
"shallow-fluid-let!" "signed-integer->bit-string" "simplify-directory"
"sin" "sixth" "sort" "special-name\?" "sqrt" "standard-rep-message"
"standard-rep-prompt" "stickify-input-filenames" "string->input-port"
"string->list" "string->number" "string->pathname" "string->symbol"
"string->uninterned-symbol" "string-allocate" "string-append"
"string-capitalize!" "string-capitalize" "string-capitalized\?"
"string-ci<=\?" "string-ci<\?" "string-ci=\?" "string-ci>=\?"
"string-ci>\?" "string-compare" "string-compare-ci" "string-copy"
"string-downcase!" "string-downcase" "string-fill!"
"string-find-next-char" "string-find-next-char-ci"
"string-find-next-char-in-set" "string-find-previous-char"
"string-find-previous-char-ci" "string-find-previous-char-in-set"
"string-hash" "string-length" "string-lower-case\?"
"string-match-backward" "string-match-backward-ci" "string-match-forward"
"string-match-forward-ci" "string-maximum-length" "string-null\?"
"string-output-port" "string-pad-left" "string-pad-right"
"string-prefix-ci\?" "string-prefix\?" "string-ref" "string-replace!"
"string-replace" "string-set!" "string-trim" "string-trim-left"
"string-trim-right" "string-upcase!" "string-upcase" "string-upper-case\?"
"string<=\?" "string<\?" "string=\?" "string>=\?" "string>\?"
"string\?" "substring" "substring->list" "substring-capitalized\?"
"substring-ci<\?" "substring-ci=\?" "substring-downcase!"
"substring-fill!" "substring-find-next-char" "substring-find-next-char-ci"
"substring-find-next-char-in-set" "substring-find-previous-char"
"substring-find-previous-char-ci" "substring-find-previous-char-in-set"
"substring-lower-case\?" "substring-match-backward"
"substring-match-backward-ci" "substring-match-forward"
"substring-match-forward-ci" "substring-move-left!"
"substring-move-right!" "substring-prefix-ci\?" "substring-prefix\?"
"substring-replace!" "substring-replace" "substring-upcase!"
"substring-upper-case\?" "substring<\?" "substring=\?" "subvector->list"
"subvector-fill!" "subvector-move-left!" "subvector-move-right!"
"suspend-world" "symbol->pathname" "symbol->string" "symbol-append"
"symbol-global-value" "symbol-hash" "symbol-print-name" "symbol-type"
"symbol\?" "syntax" "syntax*" "syntax-table-define" "syntax-table-ref"
"syntax-table-shadow" "syntax-table-undefine" "syntax-table\?"
"syntaxer-package" "system-clock" "system-global-environment"
"system-global-syntax-table" "system-hunk3-cons" "system-hunk3-cxr0"
"system-hunk3-cxr1" "system-hunk3-cxr2" "system-hunk3-set-cxr0!"
"system-hunk3-set-cxr1!" "system-hunk3-set-cxr2!" "system-list-to-vector"
"system-pair-car" "system-pair-cdr" "system-pair-cons"
"system-pair-set-car!" "system-pair-set-cdr!" "system-pair\?"
"system-state-space" "system-subvector-to-list" "system-vector-ref"
"system-vector-set!" "system-vector-size" "system-vector\?" "tail" "tan"
"the-empty-stream" "the-environment" "the-environment-type"
"the-environment\?" "there-exists\?" "third" "time" "time->string"
"timer-interrupt" "toggle-gc-notification!" "trace" "trace-both"
"trace-entry" "trace-exit" "transcript-off" "transcript-on"
"transform-type-dispatcher" "translate-to-state-point" "true"
"true-procedure" "true-type" "truncate" "type-object-name"
"type-object-predicate" "type-object-type" "type-object\?" "type-system"
"unadvise" "unadvise-entry" "unadvise-exit" "unassigned-object\?"
"unassigned-type" "unassigned\?" "unassigned\?-components"
"unassigned\?-name" "unassigned\?-type" "unassigned\?\?"
"unbound-object\?" "unbound-reference-trap\?" "unbound-type" "unbound?"
"unbound\?-components" "unbound\?-name" "unbound\?-type" "unbound\?\?"
"unbreak" "unbreak-entry" "unbreak-exit" "undefined-conditional-branch"
"unhash" "unparse-with-brackets" "unparser-package"
"unparser-special-object-type" "unscan-defines"
"unsigned-integer->bit-string" "unsyntax" "unsyntax-lambda-list"
"unsyntax-table\?" "unsyntaxer-package" "untrace" "untrace-entry"
"untrace-exit" "user-initial-environment" "user-initial-prompt"
"user-initial-prompt-string" "user-initial-syntax-table" "using-syntax"
"valid-hash-number\?" "variable-components" "variable-name"
"variable-type" "variable\?" "vector" "vector-8b-fill!"
"vector-8b-find-next-char" "vector-8b-find-next-char-ci"
"vector-8b-find-previous-char" "vector-8b-find-previous-char-ci"
"vector-8b-ref" "vector-8b-set!" "vector->list" "vector-cons"
"vector-copy" "vector-eighth" "vector-fifth" "vector-fill!" "vector-first"
"vector-fourth" "vector-grow" "vector-length" "vector-map" "vector-ref"
"vector-second" "vector-set!" "vector-seventh" "vector-sixth"
"vector-third" "vector\?" "wait-interval" "where"
"with-external-interrupts-handler" "with-history-disabled"
"with-input-from-file" "with-input-from-port" "with-input-from-string"
"with-interrupt-mask" "with-interrupts-reduced"
"with-keyboard-interrupt-dispatch-table" "with-new-history"
"with-output-to-file" "with-output-to-port" "with-output-to-string"
"with-output-to-truncated-string" "with-proceed-point"
"with-rep-continuation" "with-scan-defines-disabled"
"with-scan-defines-enabled" "with-standard-proceed-point"
"with-threaded-continuation" "with-unsyntax-table" "within-continuation"
"without-interrupts" "working-directory-package"
"working-directory-pathname" "write" "write-bits!" "write-char"
"write-line" "write-string" "write-to-string" "zero\?"
)))
--
Mike Clarkson mike@ists.UUCP
Institute for Space and Terrestrial Science mike@ists.ists.ca
York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3 +1 (416) 736-5611
------------------------------
Date: 9 Feb 89 00:36:48 GMT
From: polya!caron@labrea.stanford.edu (Ilan G. Caron)
Subject: xscheme
Message-Id: <6738@polya.Stanford.EDU>
I've had lots of requests for xscheme, which I've attempted
to answer promptly etc. etc. Unfortunately I stepped on my
mail file so I've (possibly) lost some of those requests.
If you've asked for xscheme and you don't get anything say
by next Monday (13/2) - please ask again.
BTW, maybe we should setup a comp.lang.scheme.x newsgroup...
anyone know what the canonic way of doing that is?
--ilan
caron@polya.stanford.edu
------------------------------
End of Scheme Digest
********************
∂10-Feb-89 2128 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #64
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 21:28:42 PST
Date: 11 FEB 89 00:06:24 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #64
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #64 11 FEB 89 00:06:24 EST
Today's Topics:
Scheme mailing list
----------------------------------------------------------------------
Date: 9 Feb 89 15:56:08 GMT
From: att!alberta!calgary!cpsc!jameson@bloom-beacon.mit.edu (Kevin Jameson)
Subject: Re: Scheme mailing list
Message-Id: <680@cs-spool.calgary.UUCP>
Would someone please be kind enough to post (or email to
jameson@cpsc.UCalgary.CA) the sources and documentation for David Betz's
XSCHEME? I have been trying for months to obtain a copy, and have
been unsuccessful in all attempts, including
-mailing a disk to Dave Betz
-asking for mailings from two others on the net who had it.
Here in Canada we can't ftp it off the internet, but we can reach
SIMTEL20 if someone can get it to Keith Peterson.
Please help if you can. Thank you.
Kevin
------------------------------
End of Scheme Digest
********************
∂11-Feb-89 2134 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #65
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 89 21:34:08 PST
Date: 12 FEB 89 00:06:17 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #65
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #65 12 FEB 89 00:06:17 EST
Today's Topics:
xscheme
----------------------------------------------------------------------
Date: 10 Feb 89 21:51:30 GMT
From: att!alberta!calgary!cpsc!jameson@bloom-beacon.mit.edu (Kevin Jameson)
Subject: Re: xscheme
Message-Id: <692@cs-spool.calgary.UUCP>
If anyone was considering mailing me a copy of xscheme, please save
your effort. The disk which I had sent to Dave Betz showed up today
(without postage, torn somewhat, but with readable goods inside).
Thank you David Betz.
------------------------------
End of Scheme Digest
********************
∂13-Feb-89 2125 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #66
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 21:25:14 PST
Date: 14 FEB 89 00:05:13 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #66
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #66 14 FEB 89 00:05:13 EST
Today's Topics:
Combinator reduction applications?
----------------------------------------------------------------------
Date: 13 Feb 89 16:09:03 GMT
From: a.gp.cs.cmu.edu!koopman@pt.cs.cmu.edu (Philip Koopman)
Subject: Combinator reduction applications?
Message-Id: <4263@pt.cs.cmu.edu>
I am studying combinator graph reduction techniques for implementing
functional programming languages. My question is, if very fast
implementations became available, what applications would they find?
Specifically:
-- What applications for functional programming languages
-- What applications for combinator graph reduction in general
If possible, estimate the performance level on a workstation platform
required to make your favorite application run reasonably fast to the
nearest order of magnitude:
-- 10,000 reduction applications per second (MIRANDA speed)
-- 100,000 reduction applications per second (SKIM, NORMA, special-purpose
hardware type speeds)
-- 1,000,000 reduction applications per second
... etc ...
If I get a reasonable response, I will summarize results. By the way,
yes I have read about TIM, so any input on closure reducer applications
as well as graph reducer applications is appreciated.
Thanks,
Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet
5551 Beacon St.
Pittsburgh, PA 15217
PhD student at CMU.
--
------------------------------
End of Scheme Digest
********************
∂14-Feb-89 2127 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #67
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 21:27:09 PST
Date: 15 FEB 89 00:05:15 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #67
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #67 15 FEB 89 00:05:15 EST
Today's Topics:
Please delete me.
CLISP
----------------------------------------------------------------------
Date: 13 Feb 89 22:10:40 PST (Monday)
Subject: Please delete me.
From: "Adolfo_G._Pacheco.ESXC15"@Xerox.COM
Message-ID: <890213-221104-8579@Xerox>
Please delete me from your list
thanks,agp I am leaving Xerox
------------------------------
Date: Tue, 14 Feb 89 17:10:06 EST
From: yadav@andromeda.rutgers.edu (Ashish Yadav)
Message-Id: <8902142210.AA21833@andromeda.rutgers.edu>
Subject: CLISP
Hi,
I'd like to download CLISP for our pyramid machine. Could you let me
know which file I should download from /scheme. Also if you could put me
onto the mailing lists. Hope to hear from you soon.
Ash.
------------------------------
End of Scheme Digest
********************
∂17-Feb-89 2200 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #68
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 22:00:30 PST
Date: 18 FEB 89 00:06:41 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #68
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #68 18 FEB 89 00:06:41 EST
Today's Topics:
Process modes for gnu emacs
----------------------------------------------------------------------
Date: Fri, 17 Feb 89 00:50:44 EST
From: Olin.Shivers@CENTRO.SOAR.CS.CMU.EDU
Subject: Process modes for gnu emacs
---
I have some new process modes for interacting with T and Scheme (and
shell, TeX, and Lisp) processes in gnu emacs. A description of these modes is
appended to this msg. The package itself is too large to be shipped out with
this msg -- the compressed shar file is 50kb. If you would like to try the
modes out, you may retrieve the file by anonymous ftp from zurich.ai.mit.edu
(18.26.0.176):
- log in with user id "anonymous"
- Set the transfer type to image or binary (command "binary" or somesuch).
- get pub/cmu/cmuproc.shar.Z
- leave ftp, uncompress & de-shar the file.
MIT CScheme users may prefer to remain with xscheme.el mode. See the
discussion about this is the notes below.
-Olin
------ Notes follow ------
I have written new gnu-emacs packages that provide shell, inferior lisp,
inferior scheme, and inferior T modes. These packages have the following
advantages over the standard released gnu packages:
- Input history is kept in all modes, traversed with M-p and M-n, just
like on LispM's and various fancy shells.
- Filename completion and query is available in all modes.
- Keybindings are cross-compatible among all modes.
- Keybindings are compatible with Zwei and Hemlock.
- Directory tracking is more robust in shell mode, and is *only* active in
shell mode. (Try entering "cd /" to an inferior lisp in the old package:
Lisp barfs, but the inferior lisp mode goes ahead and changes the
buffer's directory.)
- Non-echoed text entry (for entering passwords) is available in all modes.
- Shell and inferior Lisp modes are backwards compatible with the standard
gnu modes.
- One source for the inferior Lisp mode works in both emacs releases 18.4x and
18.5x. This has been the cause of confusing bugs for users who unwittingly
tried to use an 18.4x version inferior Lisp mode in an 18.5x version emacs,
and vice-versa.
- A full set of eval/compile-region/defun commands for the inferior Lisp,
Scheme, and T modes.
- New modes are easily created for new types of processes.
===============================================================================
THE BAD NEWS:
It would be nice if the shell & inferior lisp package, cmushell.el, was
completely plug-compatible with the old package in shell.el -- if you could
just name the new version shell.el, and have it transparently replace the old
one. But you can't. Several other packages (tex-mode, background, dbx, gdb,
kermit, monkey, prolog, telnet) are also clients of shell mode. These packages
assume detailed knowledge of shell mode internals in ways that are
incompatible with the new mode (mostly because of the new mode's greater
functionality). So, unless we are willing to port all of these packages, we
can't have the new shell package be a complete replacement for shell.el --
that is, we can't name the file shell.el, and its main entry point (shell),
because dbx.el will break when it loads it in and tries to use it.
There are two ways to fix this. One: rewrite these other modes to use the
new package. This is a win, but can't be assumed. The other, backwards
compatible route, is to make this package non-conflict with shell.el, so
both files can be loaded in at the same time. This is what I have
done. So the mode names and major functions have different names, e.g:
shell.el cmushell.el
-------- ----------
M-x shell M-x cmushell -- Fire up a shell
M-x run-lisp M-x cmulisp -- Fire up a lisp
shell-mode-map cmushell-mode-map -- Keybindings for [cmu]shell mode
All the names have been carefully chosen so that shell.el and cmushell.el
won't tromp on each other -- that way dbx.el and friends can happily load
in shell.el without breaking the cmushell.el package, and vice versa.
With the exception of M-x cmushell and M-x cmulisp, however, most of the name
changes are invisible to the user. Further, most of the customising
variables that are common in functionality have the same name:
inferior-lisp-program, explicit-shell-file-name, et al.
Hook variables are different, so you can customise shell-mode and
cmushell-mode differently, for instance.
By the way, it is rather easy to port the shell.el-dependent packages to use
the new stuff. There are fairly complete comments in the relevant source
files showing how to do this. Note that this backwards-compatibility hassle
*only* affects shell and inferior lisp mode; the other process-in-a-buffer
modes (Scheme, T, etc.) do not have this problem.
===============================================================================
GENERALIA:
The implementation strategy was to factor common process functionality
into a general command interpreter mode -- comint mode -- and then to
build all the specific modes on top. This provides uniform, integrated
functionality and interface across all the derived modes. Comint mode
provides the input history, filename completion and query,
non-echoed text entry, input editing, and process signalling
(e.g., ↑z, ↑c, ...) commands. *Any* mode built on comint mode gets
all this stuff automatically. Additionally, comint mode has general
hooks for customising it to specific command interpreters, such as
Lisp, Scheme, csh, ML, etc..
This release includes the following files:
- comint.el comint mode
- cmushell.el cmushell and cmulisp modes, built on comint mode.
- cmuscheme.el inferior Scheme mode, built on comint mode.
- tea.el inferior T mode, built on comint mode.
- tea2.el Variant of tea.el
- cmutex.el tex-mode.el with rewritten process interaction code.
Some bugs also fixed.
These packages have been in daily use by a user community of about 10-20
at CMU since August; most bugs have been shaken out. cmutex.el is less
tested. Please notify me of bugs.
The files are *extensively* commented; this should serve as sufficient
documentation. Each file includes suggestions for your .emacs file
in comments at the top. On-line documentation (C-h C-m, C-h C-f, C-h C-v)
is available for modes, commands, and variables.
This source is available on an FSF-style basis: use it any way you like
as long as you don't charge money for it or change the basis of its
availability; I assume no liability for its use.
===============================================================================
INPUT HISTORY:
There are actually two different ways to retrieve old commands for
resubmission to a process. The standard way is to use the input history
mechanism. An internal list is kept in each process buffer of the last n
inputs (default: 30). The commands M-p and M-n move through this list. This
is similar in functionality to the input history mechanisms provided by the
LispM, Hemlock, and various fancy shells (tcsh, cmucsh, ksh,...). There is
also a command, bound to C-c r, which searches backwards through the input
history looking for a substring match.
RMS doesn't like this mechanism. He has suggested an input history mechanism
that operates by searching backwards (and forwards) through the buffer for
occurrences of the prompt. The user can then resubmit the input by hitting
return.
I do not like this mechanism. If the prompt changes dynamically, you can miss
a command. False positives are also annoying. The screen jumps around a lot as
you scroll through your history. If you run a subprogram that has a null
prompt (like dc), prompt search will miss all its inputs. Etc.
However, you may try either of these mechanisms, and go with the style you
prefer. The RMS-style prompt-search stuff is available on M-N and M-P
(meta-shift-n and meta-shift-P); C-c R is bound to a command that searches for
specific commands (analogous to C-c r). If you use this stuff, you will
probably want to sharpen up the regular expression used to match the prompt in
each mode to match your particular prompt -- the default, general regexp used
in shell mode generates too many annoying false positives. (It's local
variable comint-prompt-regexp -- you should set it in a hook).
===============================================================================
MIT CSCHEME, XSCHEME.EL AND CMUSCHEME.EL:
MIT Cscheme, when invoked with the -emacs flag, has a special user interface
that communicates process state back to the superior emacs by outputting
special control sequences. The gnumacs package, xscheme.el, has lots and lots
of special purpose code to read these control sequences, and so is very
tightly integrated with the cscheme process. The cscheme interrupt handler and
debugger read single character commands in cbreak mode; when this happens,
xscheme.el switches to special keymaps that bind the single letter command
keys to emacs functions that directly send the character to the scheme
process. Cmuscheme mode does *not* provide this functionality. If you are a
cscheme user, you may prefer to use the xscheme.el/cscheme -emacs interaction.
Here's a summary of the pros and cons, as I see them.
xscheme: Tightly integrated with inferior cscheme process! A few commands not
in cmuscheme. But. Integration is a bit of a hack. Input history
only keeps the immediately prior input. Bizarre keybindings.
cmuscheme: Not tightly integrated with inferior cscheme process.
But. Carefully integrated functionality with the entire suite of
comint-derived CMU process modes. Keybindings reminiscent of Zwei
and Hemlock. Good input history. A few commands not in xscheme.
It's a tradeoff. Pay your money; take your choice. If you use a Scheme
that isn't Cscheme, of course, there isn't a choice. Xscheme.el is *very*
Cscheme-specific; you must use cmuscheme.el.
It would definitely be possible to stick the winning bits of cmuscheme.el into
xscheme.el, or vice-versa. The friendly folks at Cscheme Central may be moved
to do the former (I haven't discussed it with them). Interested parties are
invited to do the latter. I am not a Cscheme user, so I won't be doing it
myself.
-Olin
------------------------------
End of Scheme Digest
********************
∂18-Feb-89 1808 @MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 89 18:08:48 PST
Received: from iuvax.cs.indiana.edu (TCP 20123777300) by MC.LCS.MIT.EDU 18 Feb 89 21:02:06 EST
Received: by iuvax.cs.indiana.edu
Date: Sat, 18 Feb 89 21:01:37 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: ... should be a peculiar identifier
At the last R*RS meeting the syntactic extension committee was
strongly encouraged to come up with a proposal that provided the
functionality of extend-syntax. Ellipsis is fundamental to that
functionality, and extend-syntax uses the standard ellipsis notation
in a way the many find highly satisfying. Yet according to the R3RS
syntax, ... IS NOT AN IDENTIFIER. Thus the option of providing
extend-syntax as an extension of the standard syntax is closed (unless
the property that programs parse as data is forfeited, which no one
wants to see). I've tried to think of a presently legal identifier
that could serve in place of ..., but without luck. Compatibility
with the existing extend-syntax is also worth something, though not
essential.
The syntactic category <peculiar identifier> has already been provided
to make exceptions of + and -. The problem could be fixed by simply
adding ... to the list. This was considered and voted down at
Brandeis, but at that time the community of extend-syntax users was
much smaller and the feeling that some sort of syntactic extension
mechanisms belonged in Scheme had much less support than it does now.
I think we should reconsider this issue now so the syntactic extension
committee isn't faced with an awkward problem in the future.
If consensus can be reached over the net in next the couple of months, it
could even improve the IEEE standard. Comments?
Chris Haynes
Dan Friedman
Mitch Wand
∂18-Feb-89 2155 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #69
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 89 21:55:12 PST
Date: 19 FEB 89 00:07:01 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #69
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #69 19 FEB 89 00:07:01 EST
Today's Topics:
Scheme mailing list
Binary files
----------------------------------------------------------------------
Date: 18 Feb 89 06:31:26 GMT
From: portal!cup.portal.com!HyperDriven@uunet.uu.net (Joseph C McDonald)
Subject: Re: Scheme mailing list
Message-Id: <14776@cup.portal.com>
I have an idea,
how about if the holder of the source to XSCHEME post it on ****.sources and
then post to tell everyone where it is postedOr if the source is not
available how about if they just post it in ****.binaries.
Even if the Docs are very limited I am sure that with enough people playing
around with this thing a lot of information will be posting on the net.
This is just an idea, and maybe a poor one, I don't know. I don't even
know what SCHEME is! I sure would like to find out though. Would anyone
like to give me a brief synopsis on this thing?
Thanks
-=Joseph=-
HyperDriven@cup.portal.com
I think sometimes I think I think sometimes..... - Ron Greeny
------------------------------
Date: Sat, 18 Feb 89 17:47 EST
From: Edmund Lai <munnari!swanee.oz.au!edmund@uunet.UU.NET>
Subject: Binary files
Message-ID: <19890218224724.0.SCHREQ@MICKEY-MOUSE.LCS.MIT.EDU>
From: Edmund Lai <munnari!swanee.oz.au!edmund@uunet.UU.NET>
To: Scheme-Request@mc.lcs.mit.edu
Date: Tue, 7 Feb 89 15:39:33 WST
Subject: Binary files
I am using TI's PC-Scheme v.3 and have come across one problem
recently which I hope someone would be able to help.
I have some binary data files -- in fact they are 12-bit binary
digitized speech sample data -- I need to read. Is there any
way of doing this with scheme? Seems to me that it can only read
ASCII files.
Edmund Lai
Department of Electrical & Electronic Engineering
University of Western Australia
Nedlands
Western Australia 6009
<edmund@swanee.oz>
------------------------------
End of Scheme Digest
********************
∂20-Feb-89 1050 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com Re: ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 10:50:51 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 20 Feb 89 13:39:34 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae27758; 20 Feb 89 12:52 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa25794; 20 Feb 89 12:48 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA06260; Mon, 20 Feb 89 09:40:33 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA15658; Mon, 20 Feb 89 09:41:01 PST
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
id AA10143; Tue, 21 Feb 89 09:42:45 pst
Message-Id: <8902211742.AA10143@bloom.LA.TEK.COM>
To: Chris Haynes <chaynes@IUVAX.CS.INDIANA.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU, kend@bloom.la
Subject: Re: ... should be a peculiar identifier
In-Reply-To: Your message of Sat, 18 Feb 89 21:01:37 -0500.
<8902190215.AA25029@tektronix.TEK.COM>
Date: Tue, 21 Feb 89 09:42:42 PST
From: kend%bloom.la.tek.com@RELAY.CS.NET
I have used ***, but I find ... more aesthetically pleasing.
Given the backquote and number syntax, the parsing work to
recognize ... is minor. I support ... as a peculiar identifier.
-Ken Dickey
∂20-Feb-89 1141 @MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 11:41:31 PST
Received: from zohar (TCP 2212600256) by MC.LCS.MIT.EDU 20 Feb 89 14:23:36 EST
Received: by ZOHAR.AI.MIT.EDU; Mon, 20 Feb 89 14:26:32 est
Date: Mon, 20 Feb 89 14:26:32 est
From: gjs@ZOHAR.AI.MIT.EDU (Gerald Jay Sussman)
Message-Id: <8902201926.AA04455@zohar>
To: chaynes@iuvax.cs.indiana.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Haynes's message of Sat, 18 Feb 89 21:01:37 -0500
Subject: ... should be a peculiar identifier
I strongly agree with this proposal.
I also believe that the peculiar identifiers list should be extensible
in this and in any other useful direction. Users should be free to
pick identifiers so long as they do not conflict with other types. It
is unnecessary (and unpleasant) for us to PREVENT any exotic features
from being developed that may need identifiers that CANNOT BE confused
with any other syntatic type.
∂20-Feb-89 1158 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 11:58:45 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 20 Feb 89 14:42:50 EST
Received: from Semillon.ms by ArpaGateway.ms ; 20 FEB 89 11:39:00 PST
Date: Mon, 20 Feb 89 11:38:46 PST
From: Pavel.pa@Xerox.COM
Subject: Re: ... should be a peculiar identifier
In-reply-to: "chaynes@iuvax.cs.indiana.edu's message of Sat, 18 Feb 89
21:01:37 -0500"
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890220-113900-10189@Xerox>
I strongly support this proposal, though I might go further and allow ``.''
as a normal constituent character, disallowing only the name ``.'' for
symbols.
Pavel
∂20-Feb-89 1244 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 12:43:56 PST
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 20 Feb 89 15:37:44 EST
Received: by void.ai.mit.edu (5.59/1.5)
id AA02864; Mon, 20 Feb 89 15:43:30 EST
Date: Mon, 20 Feb 89 15:43:30 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8902202043.AA02864@void.ai.mit.edu>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 20 Feb 89 11:38:46 PST <890220-113900-10189@Xerox>
Subject: ... should be a peculiar identifier
Reply-To: jar@zurich.ai.mit.edu
Date: Mon, 20 Feb 89 11:38:46 PST
From: Pavel.pa@Xerox.COM
I strongly support this proposal, though I might go further and allow ``.''
as a normal constituent character, disallowing only the name ``.'' for
symbols.
In effect, this is already the case, since . + - are "special
subsequents" according to the grammar in section 7.1.1 of the
Revised↑3 Report. The grammar thus allows identifiers like A..B,
SET-CAR!, and so on. The text in section 2.1 is in error in not
describing this possibility. In my opinion it is section 7.1.1 that
reflects current practice and the consensus of the authors, not
section 2.1. Sorry for getting it wrong. I would like to direct the
editors of the Revised↑4 Report and the IEEE Draft Standard to fix
section 2.1. I think it would suffice to add + - . to the list of
extended alphabetic characters.
My opinion on the "..." question is that I would like to see
incompatibilities with Common Lisp, as well as differences between the
↑3 and ↑4 reports, minimized, and thus leave "..." as it stands, namely
not generated by the grammar. I suggest the alternative "---" for use
in pattern languages. But I may have used up my opinion quota on the
last report.
∂20-Feb-89 1441 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%coconut@cs.brandeis.edu ... should be a peculiar identifier
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 14:40:52 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 20 Feb 89 17:33:36 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag01534; 20 Feb 89 17:01 EST
Received: from cs.brandeis.edu by RELAY.CS.NET id af27950; 20 Feb 89 16:57 EST
Received: from coconut (peanut.cs.brandeis.edu) by cs.brandeis.edu (13.1/6.0.GT)
id AA09594; Mon, 20 Feb 89 09:15:08 est
Posted-Date: Mon, 20 Feb 89 09:18:32 est
Received: by coconut (13.1/4.7)
id AA16549; Mon, 20 Feb 89 09:18:32 est
Date: Mon, 20 Feb 89 09:18:32 est
From: Jim Miller <jmiller%coconut%cs.brandeis.edu@RELAY.CS.NET>
Message-Id: <8902201418.AA16549@coconut>
To: chaynes%iuvax.cs.indiana.edu%coconut%cs.brandeis.edu@RELAY.CS.NET
Cc: rrrs-authors%mc.lcs.mit.edu%relay.cs.net%coconut%cs.brandeis.edu@RELAY.CS.NET
In-Reply-To: Chris Haynes's message of Sat, 18 Feb 89 21:01:37 -0500 <8902190205.AA08909@ZURICH.AI.MIT.EDU>
Subject: ... should be a peculiar identifier
Reply-To: JMiller%cs.Brandeis.edu@RELAY.CS.NET
I heartily endorse your suggestion, but for a slightly different
(selfish) reason. I often distribute code for problem sets to
students and I like to put these same ellises ("...") into that code
to indicate the parts that they should fill in. I, too, have been
bitten by the fact that it's not an identifier since the code can't
even be loaded (let alone executed) when they are present.
--Jim
∂20-Feb-89 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #70
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 21:41:55 PST
Date: 21 FEB 89 00:08:22 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #70
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #70 21 FEB 89 00:08:22 EST
Today's Topics:
R↑4 Report?
----------------------------------------------------------------------
Date: 20 Feb 89 14:36:10 GMT
From: mcvax!hp4nl!botter!star.cs.vu.nl!roelw%cs.vu.nl@uunet.uu.net
Subject: R↑4 Report?
Message-Id: <2065@star.cs.vu.nl>
Does anyone know whether there is a R↑4 Report on Scheme in preparation
or currently available?
Roel Wieringa
------------------------------
End of Scheme Digest
********************
∂21-Feb-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #71
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:29:57 PST
Date: 22 FEB 89 00:08:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #71
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #71 22 FEB 89 00:08:32 EST
Today's Topics:
R↑4 Report?
pattern matching and read tables question
----------------------------------------------------------------------
Date: 21 Feb 89 22:36:42 GMT
From: uoregon!will@beaver.cs.washington.edu (William Clinger)
Subject: Re: R↑4 Report?
Message-Id: <3906@uoregon.uoregon.edu>
>Does anyone know whether there is a R↑4 Report on Scheme in preparation
>or currently available?
I am editing the R4RS. A draft labelled R↑3.9RS was distributed for
the recent IEEE/MSC/P1178 meeting. A draft labelled R↑3.95RS will be
available via ftp for proof-reading in about a week. The R4RS should
be essentially the same as that draft, except for typos and oversights.
William Clinger
------------------------------
Date: 20 Feb 89 22:59:05 GMT
From: hefley@rand-unix.arpa (Charlene Hefley)
Subject: pattern matching and read tables question
Message-Id: <1889@randvax.UUCP>
Hi,
I have a pattern matcher (written in Scheme) that I would like to give the
capability of stripping prefix characters from words. For example, I
would like to pass the pattern matcher something like:
+variable
and change it to be:
+ variable
The "+", of course, will not be present on all words in the pattern.
The most obvious solution is to use explode and implode, but I'm looking
for something much more efficient. I would guess that altering the read
table would be the way to go. Then I wouldn't have to do the "explosion"
inside the pattern matcher at all. At least, I think that's possible; I
really don't know much about read tables.
Any advice on how to solve this problem (with read tables or otherwise)
would be most appreciated. You may reply directly to me.
Thanks in advance,
Charlene Hefley
inet: rand-unix.arpa
uucp: ...!randvax!hefley
------------------------------
End of Scheme Digest
********************
∂23-Feb-89 2154 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #72
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 21:54:43 PST
Date: 24 FEB 89 00:12:42 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #72
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #72 24 FEB 89 00:12:42 EST
Today's Topics:
need R3RS code to test my new generational gc
----------------------------------------------------------------------
Date: 23 Feb 89 23:42:18 GMT
From: polya!carcoar.Stanford.EDU!wilson@labrea.stanford.edu (Paul Wilson)
Subject: need R3RS code to test my new generational gc
Message-Id: <7140@polya.Stanford.EDU>
I'm looking for a few good programs to test my new generational
gc on. The gc is for Scheme-48, which is pretty much bare-bones
R3RS.
At the moment, I'm looking for programs that won't take much porting,
preferably none. (The debugging cycle is abysmally long at the
moment, and there are no debugging tools.)
I believe I heard somewhere that the programs from Abelson & Sussman's
_Structure_and_Interpretation_of_Computer_Programs_ are available
in machine-readable format via ftp. Could anybody tell me how to
get them? And maybe the Scheme versions of the Gabriel benchmarks?
I'm looking for all sizes and kinds of programs. (At the moment, even
little ones will help me test the system; later I'll want large ones
for gathering serious gc statistics.) Assuming I get the SICP
code, I shouldn't need any more of the ubiquitous Scheme-in-Scheme
programs. (I've already run one.) Other than that, though, the
field is wide open. The more "real" the program, the better.
Thanks prematurely,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory lab ph.: (312) 413-0042
U. of Illin. at C. EECS Dept. (M/C 154) wilson@carcoar.stanford.edu
Box 4348 Chicago,IL 60680
Paul R. Wilson
Human-Computer Interaction Laboratory lab ph.: (312) 413-0042
U. of Ill. at Chi. EECS Dept. (M/C 154)
Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu
------------------------------
End of Scheme Digest
********************
∂24-Feb-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #73
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 21:39:55 PST
Date: 25 FEB 89 00:12:47 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #73
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #73 25 FEB 89 00:12:47 EST
Today's Topics:
need R3RS code to test my new generational gc
got SICP code (don't send more) ... still need other R3RS code
need R3RS code to test my new generational gc
----------------------------------------------------------------------
Date: Fri, 24 Feb 89 01:00:50 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8902240600.AA08130@kleph.ai.mit.edu>
Subject: need R3RS code to test my new generational gc
Reply-To: cph@zurich.ai.mit.edu
Date: 23 Feb 89 23:42:18 GMT
From: polya!carcoar.Stanford.EDU!wilson@labrea.stanford.edu (Paul Wilson)
I believe I heard somewhere that the programs from Abelson & Sussman's
_Structure_and_Interpretation_of_Computer_Programs_ are available
in machine-readable format via ftp. Could anybody tell me how to
get them? And maybe the Scheme versions of the Gabriel benchmarks?
All of these programs are available via anonymous ftp from
"zurich.ai.mit.edu". Get the following files:
pub/6.001/examples.tar
pub/gabriel.bench/gabriel.1
pub/gabriel.bench/gabriel.2
pub/gabriel.bench/gabriel.3
pub/gabriel.bench/gabriel.4
------------------------------
Date: 24 Feb 89 05:39:52 GMT
From: polya!carcoar.Stanford.EDU!wilson@labrea.stanford.edu (Paul Wilson)
Subject: got SICP code (don't send more) ... still need other R3RS code
Message-Id: <7159@polya.Stanford.EDU>
I've already got the Abelson & Sussman code. (And now I know it's part
of the MIT Scheme distribution.)
I'm still looking for more R3RS programs to test my system.
thanks,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory lab ph.: (312) 413-0042
U. of Ill. at Chi. EECS Dept. (M/C 154)
Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu
------------------------------
Date: Fri, 24 Feb 89 15:36:59 est
From: jems@ZOHAR.AI.MIT.EDU (Julie Sussman)
Message-Id: <8902242036.AA06702@zohar>
Subject: need R3RS code to test my new generational gc
I don't know if someone has put the SICP code in a place you can
get it with ftp, but I can send it to you in messages, if you like.
Let me know if you want that.
Julie Sussman
------------------------------
End of Scheme Digest
********************
∂26-Feb-89 2224 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #74
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 89 22:23:56 PST
Date: 27 FEB 89 00:14:20 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #74
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #74 27 FEB 89 00:14:20 EST
Today's Topics:
looking for pub domain OPS
macros in XSCHEME
----------------------------------------------------------------------
Date: Sun, 26 Feb 89 16:43 EST
From: John Lundin Jr <LUNDIN%URVAX.BITNET@MITVMA.MIT.EDU>
Subject: looking for pub domain OPS
(Yes, there is some tie-in to the list :-)
For the last five years or so, off and on, I've been hearing about a public
domain OPS-5. Does anyone know where to find this mythical release? The
original was said to have been in a MacLisp dialect, but rumor has claimed
that other PD translations existed, Scheme among them. So...
Does anyone know of a version in any or all of:
-Scheme -Common Lisp
-MacLisp dialect -Other high level language
-VAX/VMS whatever -MS-Dos whatever (ugh)
or at least of a PD, HLL version of the resolution mechanism? Documentation?
Since this isn't properly a Scheme topic, please post responses to me and I
will summarize to interested parties (or to the list if enough interest).
Thank you all, -john
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
John Lundin, Jr. lundin@urvax.bitnet "Immature programmers imitate,
University of Richmond lundin@urvax.urich.edu mature programmers steal"
------------------------------
Date: 26 Feb 89 19:49:06 GMT
From: phoenix!crabb@princeton.edu (David W Crabb)
Subject: macros in XSCHEME
Message-Id: <6661@phoenix.Princeton.EDU>
Below is a commented version of the MACROS.S file which is part of the
xscheme package. Please let me have comments on the comments
(meta-comments ??) .
------------------------------------------------------------------------
; comments by DWC
; this will become the universal argument to COMPILE
(define (%expand-macros expr)
(if (pair? expr)
(if (symbol? (car expr))
(let ((expander (get (car expr) '%syntax))) ; prop is put below (2)
(if expander
(expander expr) ; <-- THEN clause for defined macros
(let ((expander (get (car expr) '%macro))) ; prop is put at (1)
(if expander
(%expand-macros (expander expr)) ; <-- THEN clause for "macro"
(cons (car expr) (%expand-list (cdr expr))))))) ; default
(%expand-list expr)) ; compound arguments like COND and LET
expr)) ; evaluate the atom
(define (%expand-list lyst) ; a helper function for the universal arg
(if (pair? lyst)
(cons (%expand-macros (car lyst)) (%expand-list (cdr lyst)))
lyst))
(define %compile compile) ; was at the top
; Note the destructive re-define following :
(define (compile expr #!optional env)
(if (default-object? env)
(%compile (%expand-macros expr)) ; action of the old compile
(%compile (%expand-macros expr) env)))
; ** as of now, everything passed to COMPILE will be of the new form.
(put 'macro '%macro
(lambda (form)
(list 'put
(list 'quote (cadr form))
(list 'quote '%macro) ; (1)
(caddr form))))
(macro compiler-syntax
(lambda (form)
(list 'put
(list 'quote (cadr form))
(list 'quote '%syntax) ; (2)
(caddr form))))
(macro syntax
(lambda (form)
#f)) ; i.e., not implemented
; ******* This completes the re-integration of COMPILE into
; MACRO or COMPILER-SYNTAX or default. Implementation begins here:
(compiler-syntax quote
(lambda (form) form))
(compiler-syntax lambda
(lambda (form)
(cons
'lambda
(cons
(cadr form)
(%expand-list (cddr form))))))
(compiler-syntax define
(lambda (form)
(cons
'define
(cons
(cadr form)
(%expand-list (cddr form))))))
(compiler-syntax set!
(lambda (form)
(cons
'set!
(cons
(cadr form)
(%expand-list (cddr form))))))
(define (%cond-expander lyst) ; a helper function for what follows immediately
(cond ; coincidentally the unexpanded COND
((pair? lyst)
(cons
(if (pair? (car lyst))
(%expand-list (car lyst))
(car lyst))
(%cond-expander (cdr lyst))))
(else lyst)))
(compiler-syntax cond
(lambda (form)
(cons 'cond (%cond-expander (cdr form)))))
;; the folowing comment block is in the original:
; The following code for expanding let/let*/letrec was donated by:
;
; Harald Hanche-Olsen
; The University of Trondheim
; The Norwegian Institute of Technology
; Division of Mathematics
; N-7034 Trondheim NTH
; Norway
(define (%expand-let-assignment pair) ; a mapper in what follows immediately
(if (pair? pair)
(cons
(car pair)
(%expand-macros (cdr pair)))
pair))
(define (%expand-let-form form) ;
(cons
(car form) ; let/let*/letrec
(cons
(let ((lyst (cadr form))) ; coincidentally the unexpanded LET
(if (pair? lyst)
(map %expand-let-assignment lyst)
lyst))
(%expand-list (cddr form)))))
(compiler-syntax let %expand-let-form)
(compiler-syntax let* %expand-let-form)
(compiler-syntax letrec %expand-let-form)
(macro define-integrable
(lambda (form)
(cons 'define (cdr form))))
(macro declare
(lambda (form) #f)) ; i.e., not implemented
-------------------------------------------------------------------------
David Crabb
crabb@phoenix.princeton.edu
------------------------------
End of Scheme Digest
********************
∂27-Feb-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #75
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 21:32:49 PST
Date: 28 FEB 89 00:14:37 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #75
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #75 28 FEB 89 00:14:37 EST
Today's Topics:
Request for Addition to SCHEME Mailing List
Request for Addition to SCHEME Mailing List
----------------------------------------------------------------------
Date: Sat, 25 Feb 89 11:18 EST
From: POlsen@DOCKMASTER.ARPA
Subject: Request for Addition to SCHEME Mailing List
Message-ID: <890225161858.324594@DOCKMASTER.ARPA>
Please add me to the SCHEME information mailing list. Thank you.
------------------------------
Date: 27 Feb 89 19:13:40 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Request for Addition to SCHEME Mailing List
Message-Id: <2701@kalliope.rice.edu>
In article <890225161858.324594@DOCKMASTER.ARPA> POlsen@DOCKMASTER.ARPA writes:
>Please add me to the SCHEME information mailing list. Thank you.
Me too. Thanks.
--dorai
------------------------------
End of Scheme Digest
********************
∂01-Mar-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #76
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 21:36:01 PST
Date: 2 MAR 89 00:15:08 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #76
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #76 2 MAR 89 00:15:08 EST
Today's Topics:
Removal from Mailing List
----------------------------------------------------------------------
Date: 1 Mar 89 17:19:48 GMT
From: mcdchg!n8ino!craig@rutgers.edu (R. Craig Peterson )
Subject: Removal from Mailing List
Message-Id: <178@n8ino.UUCP>
Please remove my old account (craig@ncrcpx) from the scheme digest
mailing list. I've tried to send mail to the -request mailbox, but
haven't been successful!
Thanks.
--
R. Craig Peterson (N8INO)
mcdchg!n8ino!craig craig@n8ino.UUCP
------------------------------
End of Scheme Digest
********************
∂02-Mar-89 2139 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #77
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 21:39:10 PST
Date: 3 MAR 89 00:00:29 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #77
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #77 3 MAR 89 00:00:29 EST
Today's Topics:
LETREC + CALL/CC = SET! even in a limited setting
Request for Addition to SCHEME Mailing List
vanilla Scheme code now or in future?
Request for Addition to SCHEME Mailing List
Request for Addition to SCHEME Mailing List
----------------------------------------------------------------------
Date: Thu, 2 Mar 89 11:27 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: LETREC + CALL/CC = SET! even in a limited setting
Message-ID: <19890302162742.4.ALAN@PIGPEN.AI.MIT.EDU>
The following function, which I mailed out to this last last February, was
intended to demonstrate how CALL-WITH-CURRENT-CONTINUATION could be used to
expose the SET! hidden in the definition of LETREC:
(define (make-cell)
(call-with-current-continuation
(lambda (return-from-make-cell)
(letrec ((state
(call-with-current-continuation
(lambda (return-new-state)
(return-from-make-cell
(lambda (op)
(case op
((set)
(lambda (value)
(call-with-current-continuation
(lambda (return-from-access)
(return-new-state
(list value return-from-access))))))
((get) (car state)))))))))
((cadr state) 'done)))))
Here is another way to do it that has an additional interesting property:
(define (make-cell initial-value)
(letrec ((state (call-with-current-continuation
(lambda (return-new-state)
(list initial-value return-new-state #F)))))
(if (caddr state)
((caddr state) 'done)
(lambda (op)
(case op
((get) (car state))
((set)
(lambda (new-value)
(call-with-current-continuation
(lambda (return-from-set)
((cadr state)
(list new-value (cadr state) return-from-set)))))))))))
Notice that the variable STATE does not occur anywhere in the right hand
side of its own definition in the LETREC. Thus you might think that you
could optimize this into an instance of LET. But that optimization would
be incorrect (assuming that the expansion of LETREC given in R↑3RS really
-is- its definition), because then this code will stop producing
side-effectable cells.
A simpler case of this peculiarity of LETREC:
(define (test)
(letrec ((x (call-with-current-continuation
(lambda (c)
(list #T c)))))
(if (car x)
((cadr x) (list #F (lambda () x)))
(eq? x ((cadr x))))))
(TEST) should return #T. If you replace the LETREC with LET (you might be
tempted because X does not appear anywhere in the right hand side of the
definition!), then (TEST) will return #F.
I wonder if any real compilers make this mistaken optimization?
------------------------------
Date: 2 Mar 89 14:42:04 GMT
From: phoenix!crabb@princeton.edu (David W Crabb)
Subject: Re: Request for Addition to SCHEME Mailing List
Message-Id: <6774@phoenix.Princeton.EDU>
In article <890225161858.324594@DOCKMASTER.ARPA> POlsen@DOCKMASTER.ARPA writes:
>Please add me to the SCHEME information mailing list. Thank you.
Me, too .
David Crabb
crabb@phoenix.princeton.edu
------------------------------
Date: 2 Mar 89 18:28:26 GMT
From: shelby!polya!carcoar.Stanford.EDU!wilson@decwrl.dec.com (Paul Wilson)
Subject: vanilla Scheme code now or in future?
Message-Id: <7336@polya.Stanford.EDU>
The response to my request for vanilla Scheme code was less than
overwhelming. Other than the Gabriel benchmarks (translated by Will
Clinger) and the examples from Abelson and Sussman (with Sussman),
I only got one other program.
(By the way, thanks to the several people who offered to send me
the SICP & Gabriel code. I responded to everybody by mail, but some
of the mail seems to have bounced.)
There doesn't seem to be much vanilla (e.g., unextended R3RS) Scheme
code out there, so now I need to assess my options for gathering
statistics. I can port code from other Schemes, wait for more vanilla
code to become available, or stick my gc into another language processor
such as Kyoto CL or T.
Naturally, I'd rather just wait for code to pop up if it won't be too
long. Is anybody working on large programs that will be available
within the next year or so? Are there projects to produce important
pieces of code in portable Scheme, the way there are for Common Lisp
(e.g., REDUCE, OPS5)?
Does anybody have any serious programs written in something *close*
to vanilla Scheme? I might write some compatibilty macros, etc.,
and try to run some PC/Mac/Chez Scheme or T code, but I wouldn't
want to work too hard at that. (If it's too hairy, I'll just use
a different language/processor.)
Any comments or advice on this?
Thanks,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory lab ph.: (312) 413-0042
U. of Ill. at Chi. EECS Dept. (M/C 154)
Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu
Paul R. Wilson
Human-Computer Interaction Laboratory lab ph.: (312) 413-0042
U. of Ill. at Chi. EECS Dept. (M/C 154)
Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu
------------------------------
Date: 2 Mar 89 20:04:45 GMT
From: spot!daniel@boulder.colorado.edu (DANIEL KEN)
Subject: Re: Request for Addition to SCHEME Mailing List
Message-Id: <7069@boulder.Colorado.EDU>
Please add me to the scheme mailing list also.
#####################################################################
# daniel@spot.colorado.edu | I am Elmer J Fudd, millionare, I #
# own a mansion and a yacht #
#####################################################################
------------------------------
Date: 3 Mar 89 00:12:32 GMT
From: nic.MR.NET!srcsip!rd-atlas!nathani@csd4.milw.wisc.edu (Jayesh Naithani)
Subject: Re: Request for Addition to SCHEME Mailing List
Message-Id: <431@rd-atlas.UUCP>
Please add me to the SCHEME Mailing list.
- Jayesh Naithani
==========================================================================
== Jayesh Naithani ==
== --------------- ==
== INTERNET: nathani%rd-atlas@src.honeywell.com ==
== UUCP : {rutgers,ucbvax,...}!srcsip!rd-atlas!nathani ==
==========================================================================
------------------------------
End of Scheme Digest
********************
∂03-Mar-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #78
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 21:20:57 PST
Date: 4 MAR 89 00:00:44 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #78
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #78 4 MAR 89 00:00:44 EST
Today's Topics:
Stop sending addition/removal requests to the list!
----------------------------------------------------------------------
Date: Fri, 3 Mar 89 12:34:24 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8903031734.AA07322@void.ai.mit.edu>
Subject: Stop sending addition/removal requests to the list!
Reply-To: jar@zurich.ai.mit.edu
Attention usenet readers: the Internet Scheme mailing list is
identical to the comp.lang.scheme newsgroup, so if you're already
reading comp.lang.scheme, you don't need to be on the Internet list.
Anyone who wants to be added to or removed from the Internet list
should send mail to Scheme-Request@mc.lcs.mit.edu, NOT to the list
itself. This principle holds generally for all Internet mailing
lists: send to foo-request@hostname, not foo@hostname. Tell all your
friends. Help minimize junk mail traffic.
- Moderator.
------------------------------
End of Scheme Digest
********************
∂05-Mar-89 1344 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@LCS.MIT.EDU Wired numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Mar 89 13:44:50 PST
Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 5 Mar 89 16:38:04 EST
Received: from RTS-8.LCS.MIT.EDU by LCS.MIT.EDU via Chaosnet; 5 Mar 89 16:37-EST
Message-Id: <2814125888-4779862@RTS-8>
Sender: ziggy@RTS-8
Date: Sun, 5 Mar 89 16:38:08 EST
From: "Michael R. Blair" <ziggy@vx.lcs.mit.edu>
To: rrrs-authors@mc
Subject: Wired numeric predicates?
The R↑3 Report mentions multiple argument variations on the numeric
predicates (like =, <, et al) which test (resp) numeric equality,
monotonically increasing numeric sequence, ...
May some implementations implement these as left-to-right special forms
(derived expressions) where once a #F result is established the remaining
terms are not evaluated? If so, the manual should be careful not to call
these ``procedures'', or at least to mention that some implementations allow
them to not be procedures.
I ask because it seemed natural to think of (say) < as being:
(< <x1> <x2> <x3>...) = (let* ((temp1 <x1>) ; Preserve L->R eval while
(temp2 <x2>)) ; avoiding evaling <x2> twice
(and (< temp1 temp2) (< temp2 <x3>...)))
For example, (= 1 2 (diverge)) ==> #F
Or maybe different names should be used for the wired versions? Like putting
a `?' in there names (or maybe better for wired predicates to NOT have `?'s
and non-wired ones TO have them).
Regards,
~Ziggy
∂07-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #79
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 21:37:48 PST
Date: 8 MAR 89 00:13:27 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #79
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #79 8 MAR 89 00:13:27 EST
Today's Topics:
dynamic-wind
Request for Addition to SCHEME Mail
----------------------------------------------------------------------
Date: Tue, 7 Mar 89 13:41:43 PST
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8903072141.AA06887@sesame.Stanford.EDU>
Subject: dynamic-wind
ciao,
I am looking for a portable version of 'dynamic-wind' (as documented in
MIT C Scheme), I know that Christopher Haynes reported on an implementation in
a paper entitled 'Constraining Control,' but I have not been able to find the
publication, so I would like to try and find a machine readable version.
As a side question are the issues that are preventing this from being
part of standard Scheme?
(peace chance)
mas
------------------------------
Date: 7 Mar 89 03:06:00 GMT
From: uxg.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!kwang@uxc.cso.uiuc.edu
Subject: Re: Request for Addition to SCHEME Mail
Message-Id: <16800017@uicsrd.csrd.uiuc.edu>
Please add me to the scheme mailing list also.
kwang@uicsrd.uiuc.edu
thankyou.
------------------------------
End of Scheme Digest
********************
∂08-Mar-89 2133 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #80
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 21:33:37 PST
Date: 9 MAR 89 00:13:32 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #80
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #80 9 MAR 89 00:13:32 EST
Today's Topics:
Relative Merits of Common Lisp and Scheme?
----------------------------------------------------------------------
Date: 8 Mar 89 22:41:14 GMT
From: ccncsu!olender@boulder.colorado.edu (Kurt Olender)
Subject: Relative Merits of Common Lisp and Scheme?
Message-Id: <OLENDER.89Mar8154114@rachmaninov.cs.colostate.edu>
Can someone briefly summarize the difference between Common Lisp and
<some implementation of> Scheme? If I were going to implement a
fairly large scale system in one or the other, what factors would
I have to consider to choose between them.
--
================================================================================
|| Kurt Olender | Internet: olender@cs.colostate.edu ||
|| Phone: (303) 491-7015 | UUCP: hao!handel!olender ||
================================================================================
------------------------------
End of Scheme Digest
********************
∂09-Mar-89 2206 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #81
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 22:05:48 PST
Date: 10 MAR 89 00:14:16 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #81
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #81 10 MAR 89 00:14:16 EST
Today's Topics:
Unknown book reference
vanilla Scheme code now or in future?
vanilla Scheme code now or in future?
Unknown book reference
----------------------------------------------------------------------
Date: 9 Mar 89 08:21:29 GMT
From: pasteur!agate!saturn!saturn.ucsc.edu!kjell@ames.arpa (Kjell Post)
Subject: Unknown book reference
Message-Id: <6640@saturn.ucsc.edu>
In the bibliography in TI-Scheme Language Reference Manual they mention
[6] Friedman, Haynes, Kohlbecker, and Wand. "Fundamental Abstractions
of Programming Languages and Their Implementation."
Programming Language: Abstractions and Their Implementations.
To appear.
Is this a book? When is it available?
------------------------------
Date: 3 Mar 89 15:05:02 GMT
From: mit-vax!jouvelot@bloom-beacon.mit.edu (Pierre Jouvelot)
Subject: Re: vanilla Scheme code now or in future?
Message-Id: <5721@mit-vax.LCS.MIT.EDU>
In article <7336@polya.Stanford.EDU> wilson@carcoar.Stanford.EDU (Paul
Wilson) writes:
>Does anybody have any serious programs written in something *close*
>to vanilla Scheme? I might write some compatibilty macros, etc.,
>and try to run some PC/Mac/Chez Scheme or T code, but I wouldn't
>want to work too hard at that. (If it's too hairy, I'll just use
>a different language/processor.)
You might want to have a look to the FX-87 Interpreter, which
implements the FX-87 programming language designed by the Programming
Systems Research Group at MIT. It is mostly written in Scheme (> 95%)
with some additional support written in CommonLISP (mainly for
packages and hashtables); it runs on top of Jonathan Rees's
Pseudoscheme that macroexpands/compiles R3RS Scheme to CommonLISP.
We made prototype portings to T and C-Scheme without major problems
but we don't make them publicly available (too tentative).
The FX-87 Interpreter is available by anonymous ftp (pub/fx/impl) on
brokaw.lcs.mit.edu.
Hope this helps,
Pierre
--
Pierre Jouvelot
. CAI, Ecole des Mines de Paris, France (JOUVELOT@FREMP11.bitnet)
. PSRG, LCS, MIT, Cambridge (JOUVELOT@BROKAW.LCS.MIT.EDU)
------------------------------
Date: 3 Mar 89 05:54:53 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!oz@ohio-state.arpa (Ozan Yigit)
Subject: Re: vanilla Scheme code now or in future?
Message-Id: <1170@yunexus.UUCP>
In article <7336@polya.Stanford.EDU> wilson@carcoar.Stanford.EDU writes:
>... Other than the Gabriel benchmarks (translated by Will
>Clinger) and the examples from Abelson and Sussman (with Sussman),
>I only got one other program.
>
Would "scoops" fit your bill ?? It looks fairly clean (R3RS) and
would probably give your gc a good run. Would be ftp-available from
various places I am sure, or somebody can mail it to you.
happy scheming.. oz
--
... and I say to them, Usenet: oz@nexus.yorku.ca
`Where the hell were you ......!uunet!utai!yunexus!oz
when the page was blank?' Bitnet: oz@[yulibra|yuyetti]
Harlan Ellison Phonet: +1 416 736-5257x3976
------------------------------
From: chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Subject: Re: Unknown book reference
Date: 9 Mar 89 22:06:10 GMT
In article <6640@saturn.ucsc.edu> kjell@saturn.ucsc.edu (Kjell Post) writes:
In the bibliography in TI-Scheme Language Reference Manual they mention
[6] Friedman, Haynes, Kohlbecker, and Wand. "Fundamental Abstractions
of Programming Languages and Their Implementation."
Programming Language: Abstractions and Their Implementations.
To appear.
Is this a book? When is it available?
The new title is "Programming Languages: Abstraction, Representation,
and Implementation." It will be published by MIT Press/McGraw Hill
and should appear before the end of this year.
------------------------------
End of Scheme Digest
********************
∂10-Mar-89 1559 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Wired numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 15:59:28 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 10 Mar 89 18:25:02 EST
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 10 Mar 89 12:50-EST
Message-Id: <2814544175-9975825@RTS-8>
Sender: ziggy@RTS-8
Date: Fri, 10 Mar 89 12:49:35 EST
From: "Michael R. Blair" <ziggy@VX.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: Re: Wired numeric predicates?
I tried replying directly to Will Clinger but I cannot seem to successfully
route replies to him, so I forwarded this to the list. Perhaps it is of
general interest anyway. Thanks for your reply, Will.
----------------------------
Yes. I know the R↑3 Manual is not ambiguous on the point that < et al. are
procedures and not special forms. I'm sorry if I sounded alarmist about this.
I just wondered if the non-ambiguity was intentional or desireable.
I understand your rationale for not wanting numeric predicates to be special
forms. The reason I brought it up was that I am a Teaching Assistant in an
undergrad course this term that uses Scheme. A student raised the issue since
it seems natural to think of (< x1 x2 x3...) as being the AND of each of the
individual two-step comparisons. The resemblence between this and the AND
form were sufficiently strong that the student conveniently ignored the fact
that we explicitly describe < as being a *procedure* and not as a *special
form*... I guess people naturally don't look carefully at things that they
consider ``intuitively obvious''. (Actually, MIT Scheme also defines AND to be
a procedure, but we had blown this at the time... the student wanted to know
about MACScheme).
I suspect this is a very common misconception among naive users, which
suggests to me that the language would have a more uniform interface to
the user if the numeric predicates were in fact special forms.
Again, I see the language designers view that we want as little special
syntax as necessary to reinforce that we use it only where it is REALLY
needed. However, this viewing angle produces a uniformity in the language
_design_ which does not result in as uniform a _language interface_.
I guess this is just a matter of emphasis/taste. I really have not strong
opinions on this... was just curious.
~Ziggy
∂10-Mar-89 2147 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #82
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 21:47:24 PST
Date: 11 MAR 89 00:05:51 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #82
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #82 11 MAR 89 00:05:51 EST
Today's Topics:
Windows Coming Unstuck in TI's PC-Scheme
----------------------------------------------------------------------
Date: 8 Mar 89 16:09:24 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: Windows Coming Unstuck in TI's PC-Scheme
Message-Id: <1899@randvax.UUCP>
I'm running TI's PC-Scheme on a 12 mHz AT clone, and when I write "too
fast" to the 'console window the pcs-status-window comes unstuck and
scrolls through the 'console window (and other fascinating things appear
on the screen). All this seems to have no impact on the operation of the
underlying Scheme program.
Must be some interesting hardware/software interaction, since the problem
doesn't show up when I run the same software on Compaq 12 mHz ATs and
PC-Scheme is the only package that scrambles my rice rocket's display.
Does anyone else have this problem? More importantly, does anyone know of
a cure? -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
End of Scheme Digest
********************
∂12-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #83
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 89 21:37:57 PST
Date: 13 MAR 89 00:12:22 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #83
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #83 13 MAR 89 00:12:22 EST
Today's Topics:
HOW DO YOU FREEZE A TI PC-SCHEME SESSION?
----------------------------------------------------------------------
Date: 11 Mar 89 16:53:36 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: HOW DO YOU FREEZE A TI PC-SCHEME SESSION?
Message-Id: <1907@randvax.UUCP>
Does anyone know a way to freeze a PC-Scheme session?
I know dos-call can be used to return to dos briefly. Since the session
is lost if the machine is rebooted (because part of the session stays
memory resident), though, this isn't satisfactory for doing a long-term
freeze.
Suggestions? Tnx! -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
End of Scheme Digest
********************
∂13-Mar-89 2138 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #84
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 21:38:05 PST
Date: 14 MAR 89 00:12:35 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #84
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #84 14 MAR 89 00:12:35 EST
Today's Topics:
HOW DO YOU FREEZE A TI PC-SCHEME SESSION?
Lisp compilation
Uniformity
----------------------------------------------------------------------
Date: 13 Mar 89 16:44:28 GMT
From: chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Subject: Re: HOW DO YOU FREEZE A TI PC-SCHEME SESSION?
Message-Id: <CHAYNES.89Mar13114428@iuvax.cs.indiana.edu>
Does anyone know a way to freeze a PC-Scheme session?
I've found SoftwareCarousel by SoftLogic Solutions to be very useful
with PCS. It allows you to switch, with a hot key, between PCS and
other applications, such as an editor. (Epsilon is my favorite editor,
since it can be customized to bounce parens and do nice Scheme
indentation.) When PCS is swapped out, I it is saved in a file. It
should be possible to kept this file somewhere permanent with a DOS
copy, thus saving the frozen the session. Doubtless similar things
can be done with other DOS swapping utilities. DoubleDos is another
candidate, since like SoftwareCarousel, and unlike some others, it's
resident memory requirments are modest enough to allow PCS to run
moderate sized Scheme programs.
------------------------------
Date: Mon, 13 Mar 89 12:53:26 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903132053.AA03884@sesame.Stanford.EDU>
Subject: Lisp compilation
I seem to remember reading or hearing about a Lisp system which did
"on-the-fly" compilation. In particular, I believe that it compiled
specialized versions of polymorphic functions at runtime. It would then cache
the specialized version of the code in such a way that repeated uses of the
function with the same type arguments would run more efficiently than
performing a truly polymorphic dispatch each time. Anybody out there remember
anything of this sort? Can you give me a reference to a paper on it?
I need this information for a paper which goes to press in 1 week, so please
send any replies to me via email ASAP. Thanks in advance,
Morry Katz
katz@polya.stanford.edu
------------------------------
Date: 13 Mar 89 14:22:13 GMT
From: mcvax!inria!geocub!casteran@uunet.uu.net (Pierre Casteran)
Subject: Uniformity
Message-Id: <1068@geocub.greco-prog.fr>
In Scheme, there are two basic reifying forms: (the-environment)
------------------------------
End of Scheme Digest
********************
∂19-Mar-89 1256 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #86
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 12:56:22 PST
Date: 18 MAR 89 00:13:52 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #86
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #86 18 MAR 89 00:13:52 EST
Today's Topics:
Gabriel Benchmarks
----------------------------------------------------------------------
Date: 17 Mar 89 21:24:30 GMT
From: srivas@louie.udel.edu (Mandayam Srivas)
Subject: Gabriel Benchmarks
Message-Id: <11096@louie.udel.EDU>
I am looking for the Gabriel benchmarks that often used in testing different
lisps. What I need really are the tests themselves, along with notes on what
aspect of lisp each test is supposed to examine.
Does anyone in networld know where I could obtain them, or if they happen to
have them, could they mail them to me? Thanks in advance.
Srivas.
------------------------------
End of Scheme Digest
********************
∂19-Mar-89 1433 @MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Weird numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 14:33:26 PST
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 19 Mar 89 17:23:56 EST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182942; Sun 19-Mar-89 17:22:09 EST
Date: Sun, 19 Mar 89 17:22 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Weird numeric predicates?
To: jinx@ZURICH.AI.MIT.EDU, ziggy@VX.LCS.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8903171626.AA05893@chamartin.AI.MIT.EDU>
Message-ID: <19890319222206.1.ALAN@PIGPEN.AI.MIT.EDU>
Date: Fri, 17 Mar 89 11:26:05 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
I haven't thought about it carefully, but it may not be reasonable
(unless it is defined that way) to implement n-ary < and friends as
the "AND accumulation" of binary <. Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact, and this
value may have to be used consistently afterwards.
If <= is to behave transitively, even on inexact arguments, then you have
to coerce inexact number to exact numbers in order to perform comparisons.
(Or you must behave as if you did.) To see why, consider the following
three numbers:
(DEFINE A (- (EXPT 10 38) 1))
(DEFINE B 1E38)
(DEFINE C (+ (EXPT 10 38) 1))
Assuming your implementation has an exact representation for A and C
(probably as a BIGNUM) and the inexact B is represented in a floating point
format with less (probably far less!) that 38 digits of precision, then
coercing either A or C to inexact will most likely return B. If comparison
predicates coerce EXACT->INEXACT, then the following will be true:
(<= C B) ==> #T
(<= B A) ==> #T
(<= C A) ==> #F
Perhaps worse:
(= C B) ==> #T
(= B A) ==> #T
(= C A) ==> #F
If instead comparison predicates coerce INEXACT->EXACT then consistently
transitive answers will be obtained.
∂19-Mar-89 1822 @MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU Exactness contagion and wired numeric predicates
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 18:22:47 PST
Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Mar 89 13:56:46 EST
Received: from RTS-8.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Mar 89 13:57-EST
Message-Id: <2815153014-7973682@RTS-8>
Sender: ziggy@RTS-8
Date: Fri, 17 Mar 89 13:56:54 EST
From: "Michael R. Blair" <ziggy@vx.lcs.mit.edu>
To: jinx@chamartin.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Exactness contagion and wired numeric predicates
Not to belabor a belabored point, but this exactness issue you raised seems
interesting in its own right...
I haven't thought about it carefully, but it may not be reasonable
(unless it is defined that way) to implement n-ary < and friends as
the "AND accumulation" of binary <. Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact, and this
value may have to be used consistently afterwards.
Yow! I guess if we don't coerce all of them to inexact if even one of them is
inexact then we could reveal the evaluation order of the sequence. To point:
verifying monotonic increasing can be done by verifying monotonic decreasing
in the other direction. If you go left to right where the left is inexact and
the right is exact [Fig.0] then you coerce the exact to an inexact for the
comparison.
Fig.0: (< inexact exact exact)
The question is, do you use this inexact coerced value for the comparison with
the number to the right or not? If so, then you will not be consistent with
the right to left comparison (assuming this right to left likewise uses the
coerced value for the continued ``AND accumulation'').
However, in the re-write rule that I sketched in the original message, I
(unwittingly) arranged to NOT use the coerced value for the subsequent
comparison. The re-write rule looked like...
(let iter (lambda (current-expr rest-exprs)
...
(let ((next-expr (car rest-exprs)))
(and (< current-expr next-expr) ; Maybe Coerce next-expr here
(iter next-expr (cdr rest-exprs)))) ; But that does not mutate it!
...))
In fact, I don't see a reasonable way to ``get a handle on'' the coerced
value (used internally for the <) so that you could propagate this
`inexactness contagion'. If we were to define the < et al. by the above
re-writing then the issue is mute. (Granted, the above rule specifies
left-to-right but we could remedy this by writing:
(let ((list-of-comparees (reverse-or-not comparees)))
...<rule>...)
...where reverse-or-not non-deterministicall reverses a list or doesn't. This
is no more (or less) offesive than using PERMUTE in the semantics to
intentionally ambiguate the evaluation order of argument lists.
Anyway, I thought this amusing. Cheers,
~Ziggy
∂19-Mar-89 1823 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 18:22:58 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 17 Mar 89 23:54:36 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag05233; 17 Mar 89 23:36 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa04229; 17 Mar 89 23:28 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA26208; Fri, 17 Mar 89 17:07:12 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA20108; Fri, 17 Mar 89 17:05:52 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA03798; Fri, 17 Mar 89 17:07:22 pst
Message-Id: <8903180107.AA03798@mrloog.LA.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Date: 17 Mar 89 17:07:16 PST (Fri)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
; FILE: Portability-Proposal
; IMPLEMENTS: Proposal for suggested library function interface
; AUTHOR: Ken Dickey
; DATE: 1989 February 19
; LAST UPDATED: 1989 March 17
; HISTORY:
; STATUS: DRAFT (#1)
PREFACE:
The number of Scheme implementations is rapidly growing. This
document is an attempt to deal with portability issues so that
applications can be made source-portable with a single compatability
file across differing Scheme implementations. A recommended standard
library interface is included, with the recognition that not all
functions make sense for all implementations (e.g. the THE-CURRENT-TIME
function for embedded applications lacking real-time clock support).
The main portability issues addressed here deal with the ability to
programatically query an implementation and fill in the gaps between
the implementation supplied library and an application. Specifically,
to provide baseline functionality, specialize machine independent to
implementation specific functions, and allow implementation-dependent
optimizations.
Baseline functionality consists of augmenting an implementation's
library to include all functions required by an application. For
example, if hash-tables are not provided by the implementation, they
may be provided by the application. However, hash-tables provided by
an implementation may be significantly more efficient than those an
application might provide and are to be preferred if offered.
Specializing machine independent to implementation specific functions
requires mapping an application defined interface to idiosyncratic
implementation, operating system, or hardware features. For example,
an application may typically map conventionalized to idiosyncratic
line drawing functions.
Implementation dependent optimizations can have a major impact on
application performance. Writing portable applications of significant
size requires allowing the use of some optimizations where they are
available. A typical example is allowing a compiled implementation to
consider certain definitions as constant so that folding or code
inlining optimizations may be performed.
===========================================================================
=======================
IMPLEMENTATION QUERIES:
=======================
========
FUNCTION: (IMPLEMENTATION-INFORMATION)
========
RETURNS: A proper list of the form:
(<name> <version> <MACHINE> <CPU> <OS> <FS> . <supports>)
Each object returned is a symbol or #f. It is recommended that
symbols be in mixed case (as if created with STRING->SYMBOL).
EXAMPLE: (implementation-information) -->
(BogusScheme 1.0 Valhalla-9000 68080 GNUnix GNUfs Complex Reals X21)
NOTES: Case is used for readability and uniqueness. <Supports>
options can be checked with memq. <Version> can be parsed after
SYMBOL->STRING conversion (see string ports).
========
FUNCTION: (SCHEME-IMPLEMENTATION)
========
RETURNS: a proper list of the form (<name> <version>), where <name> and
<version> are symbols.
===========================================================================
================
FORMATTED OUTPUT
================
========
FUNCTION: (FORMAT <port> <format-string> . <args>)
========
RESULT: returns unconsumed <args> or a string; has side effect of
printing according to <format-string>. If <port> is #t the output is
to the current input port. If <port> is #f, a formatted string is
returned as the result of the call. Otherwise <port> must be an
output port. <format-string> must be a string. Characters are output
as if the string were output by the DISPLAY function with the
exception of those prefixed by a tilde (~) as follows:
~a any: display the object (as for humans).
~s slashified: write the object (as for parsers).
~d decimal: the integer argument is output in decimal format.
~x hexadecimal: the integer argument is output in hexadecimal format.
~o octal: the integer argument is output in octal format.
~b binary: the integer argument is output in binary format.
~p plural: if the argument is greater than 1, a lower case 's' is printed.
~c character: the next argument is displayed as a character.
~_ space: output a space character.
~% newline: output a newline character.
~& freshline: unless at the beginning of a line, same as ~%, else ignored.
~| page seperator: output a page seperator.
~~ tilde: output a tilde.
~t tab: output a tab charcter.
~g glorify: pretty print the argument (typically an s-expression).
~? indirection: take the next argument as a format string and consume
further arguments as appropriate, then continue to process the current
format string.
========
FUNCTION: (PRETTY-PRINT <sexp> . <port>)
(PRETTY-PRINT <sexp> <port> . <width>)
========
RETURNS: Unspecified. Side effect it to output the <sexp> in an
implementation dependent manner.
===========================================================================
==============
ERROR HANDLING
==============
========
FUNCTION: (RESET)
========
RETURNS: No, it never returns. In implementations which interact with
the user via a top-level repl (read eval print loop), this function
has the effect of returning to the top-level repl. Other actions are
implementation dependent.
========
FUNCTION: (FATAL-ERROR <message> . <irritants>)
========
RETURNS: No, it never returns. This function typically has the side
effect of FORMATting the <message>--which should be a format string
to the current output port. Any <irritants> unconsumed by format are
DISPLAYed to current output port. This is a fatal error. In
implementations which interact with the user via a top-level repl, a
RESET is performed. Other actions are implementation dependent, but
may include process termination.
EXAMPLE:
> (+ 2 (fatal-error "this is an ~a with extra arguments" 'error 1 2 3))
= this is an ERROR with extra arguments 1 2 3
>
========
FUNCTION: (ERROR <message> . <irritants>)
========
RETURNS: Implementation dependent. This behaves as FATAL-ERROR as far as
output of the <message> and <irritants>, but is possably continuable in
implementations providing an interactive inspector or other error
handling.
========
FUNCTION: (INSPECT . <obj>)
========
RETURNS: It depends. If <obj> is specified, it is the default return
value, else #f is the default. What is actually returned is usually
up to user discretion. This command invokes an interactive inspector
in the invoking enviromnent. If an <obj> argument is present, it is
the initial object of the inspection.
========
FUNCTION: (TRACE . <identifiers>)
========
RETURNS: Unspecified. Identifiers must have values. If an identifier
designates a function, that function is traced on entry and exit.
========
FUNCTION: (UNTRACE . <identifiers>)
========
RETURNS: Unspecified. Removes the trace side effect on traced
identifiers. With no arguments, untraces all traced identifiers.
===========================================================================
======
SYNTAX
======
============
SPECIAL FORM: (ALIAS <alias> <original>)
============
RETURNS: Unspecified. Has the side effect of creating an alias for
the original when it occurs in the call position. Both arguments must
be identifiers. <Original> must exist at time of call.
EXAMPLEs: (alias herald comment) (alias debug inspect)
============
SPECIAL FORM: (COMMENT . <any>)
============
RESULT: The comment syntax is read as if by READ and discarded. The
effect is interpreted or compiled as whitespace.
============
SPECIAL FORM: (UNLESS <test> <expressions>...)
============
RESULT: If <test> is #f, acts as (BEGIN <expressions>...), else
returns #t.
============
SPECIAL FORM: (WHEN <test> <expressions>...)
============
RESULT: If <test> is #t, acts as (BEGIN <expressions>...), else
returns #f.
============
SPECIAL FORM: (COMMENT-WHEN <test> <exp> . <exps>)
============
RESULT: If <test> is #f, then acts as COMMENT else acts as BEGIN (which
is flattened into the current contour).
===========================================================================
====
TIME
====
========
FUNCTION: (THE-CURRENT-DATE)
========
RETURNS: A list of 3 fixnums: (<year> <month> <day>) where <year> is
based on the Julian calendar and <month> <day> are based on 1.
EXAMPLE: (the-current-date) --> (2001 1 23)
========
FUNCTION: (THE-CURRENT-TIME)
========
RETURNS: A list of 3 fixnums: (<hour> <minute> <second>) in 24-hour format.
EXAMPLE: (the-current-time) --> (13 23 30)
========
FUNCTION: (RUNTIME)
========
RETURNS: An approximation to the number of microseconds the current
process has been running.
========
FUNCTION: (UPTIME)
========
RETURNS: An approximation to the number of seconds the since the
system was booted.
===========================================================================
============
STRING PORTS
============
========
FUNCTION: (OPEN-INPUT-STRING <string>)
========
RETURNS: An input port.
NOTES: Useful to READ.
========
FUNCTION: (GET-OUTPUT-STRING <string-port>)
========
RETURNS: A string. <String-port> must have been created by
OPEN-OUTPUT-STRING. Has the logical side effect of reseting the
string-port to the empty string.
========
FUNCTION: (OPEN-OUTPUT-STRING)
========
RETURNS: An output port.
NOTES: Useful to WRITE and PORT->STRING.
========
FUNCTION: (STRING-PORT? <port>)
========
RETURNS: #t if <port> is a string port, else #f.
===========================================================================
==========
BINARY I/O
==========
========
FUNCTION: (WRITE-BYTE <value> . <port>)
========
RETURNS: Unspecified. Side effect is to output <value>, which must be
a number in the range 0..255, in machine (binary) format.
========
FUNCTION: (READ-BYTE <value> . <port>)
========
RETURNS: The EOF-object or a fixnum in the range 0..255.
===========================================================================
============
BYTE VECTORS
============
========
FUNCTION: (BYTE-VECTOR <value>...)
========
RETURNS: A byte-vector of the same length as the number of values
supplied. Each value must be a number in the range 0..255.
========
FUNCTION: (BYTE-VECTOR-REF <bv> <index>)
========
========
FUNCTION: (BYTE-VECTOR-SET! <bv> <index> <new-value>)
========
========
FUNCTION: (BYTE-VECTOR->STRING <bv>)
========
========
FUNCTION: (STRING->BYTE-VECTOR <string>)
========
========
FUNCTION: (BYTE-VECTOR->LIST <bv>)
========
========
FUNCTION: (LIST->BYTE-VECTOR <string>)
========
========
FUNCTION: (BYTE-VECTOR? <obj>)
========
RETURNS: #t if <obj> is a byte-vector, else #f.
===========================================================================
===========
DEFINITIONS
===========
========
FUNCTION: (BOUND? <identifier>)
========
RETURNS: #t if <identifier> is bound in the environment of the call,
else #f.
========
FUNCTION: (DEFINE-IF-UNBOUND <name> <exp>)
(DEFINE-IF-UNBOUND (<name> <args>) <exp>)
========
NOTES: If <name> is unbound, the definition is as per DEFINE, else as
per COMMENT.
========
FUNCTION: (DEFINE-IF-IMPLEMENTATION <implementation> <name> <exp>)
(DEFINE-IF-IMPLEMENTATION <implementation> (<name> <args>) <exp>)
========
NOTES: If <implementation> is eq? to (CAR (IMPLEMENTATION-INFORMATION))
then definition is as per DEFINE, else as per COMMENT.
===========================================================================
==========
STRUCTURES
==========
============
SPECIAL-FORM: (DEFINE-STRUCTURE <structure-name> <field> ...)
============
RESULT: Defines a disjoint record type with a named set of fields.
The following are defined:
predicate <structure-name>?
constructor MAKE-<structure-name>
a setter for each field SET-<structure-name>-<field>!
and an accessor for each field <structure-name>-<field>
,
Fields may be initialized if of the form: (<field-name> <exp>), where
<exp> is evaluated once in the environment of the define-structure
form. Uninitialized fields default value is #f.
EXAMPLE: (define-structure quux bar (baz 20)) has the effect of
defining MAKE-QUUX, QUUX?, QUUX-BAR, SET-QUUX-BAR!, QUUX-BAZ,
and SET-QUUX-BAZ!.
(quux-bar (make-quux)) --> #f
(quux-baz (make-quux)) --> 20
===========================================================================
====
MISC:
====
========
FUNCTION: (RANDOM <limit> . <seed>)
========
RETURNS: A number between zero (inclusive) and <limit> (exclusive).
The argument(s) must be numbers. An approximation to a uniform
distribution is used. The <seed> argument is used to be able to
repeat the same pseudo-random sequence.
========
FUNCTION: (SORT <obj>)
========
RETURNS: A newly allocated object of the same type as <obj> with
<obj>'s elements sorted. <Obj> must be a list, vector, string, or
byte-vector.
========
FUNCTION: (SORT! <obj>)
========
RETURNS: Original <obj> with elements sorted. <Obj> must be a list,
vector, string, or byte-vector.
========
FUNCTION: (SUSPEND <filespec>)
========
RETURNS: Error if suspension was unsuccessful, else implementation
dependent (typically returns to native operating system). Saves an
approximation to the current state of computation in an implementation
dependent manner to a file denoted by <filespec> which can later be
invoked in an implementation dependent manner. Note that some system
state (such as the state of open files) may not be restorable.
========
FUNCTION: (AUTOLOAD <name-or-namelist> <filespec>)
========
RETURNS: Unspecified. Side effect is delayed definition in current
scope. When a function is initially referenced, it is automagically
loaded before being invoked. <name-or-namelist> must be an identifier
or a list of identifiers which are presumed to denote functions defined
in file referenced by <filespec>.
===========================================================================
###########################################################################
===========================================================================
End Of Interface
===========================================================================
###########################################################################
===========================================================================
===========================================================================
=====
NOTES:
=====
IMPLEMENTATION-INFORMATION returns mixed case symbols--I thought this
would get your attention!
FORMAT returns unused arguments: this makes format somewhat easier to
write and allows FATAL-ERROR to be defined without a second format
function:
(define (FATAL-ERROR <format-string> . <args>)
(let ( (unused-args
(apply format `(#t "~&~?" ,<format-string> ,@<args>))
)
)
(unless (null? unused-args)
(for-each (lambda (arg) (display #\space) (display arg))
unused-args)
)
(display #\newline)
(reset)
) )
COMMENT-WHEN: does the job of eval-when, compile-when, etc. I would
like to avoid the eval-time vs compile-time question for now. I
definately feel the need for conditional compilation. What do you
think?
WHEN, UNLESS: I see these in a lot of code. I use them. How about
other very common patterns?
BOUND?: I know, I know. But how are we to write DEFINE-IF-UNBOUND
unless we can test somewhere? Do we keep this as magic?
DEFINE-IF-<condition>: If we accept COMMENT-WHEN and BOUND?, are these
needed?
SORT: Assumed to do a typed dispatch to LIST-SORT, VECTOR-SORT, etc. (at
least until we have an object system interface such as Amos provides).
Raw and Cooked I/O {QUUX-NO-HANG}: I have not proposed anything here
because this is a tasking issue. Either you use READ-CHAR and
CHAR-READY? as specified by R3RS {cooked} or you are dealing with
buffers and interrupts and you have to deal with {raw} rubout
characters yourself. Binary i/o allows us to implement buffers if we
face the tasking questions {see Interrupts/Handlers, below}. Once we
have portable, buffered i/o we can write portable editors--just like
real languages.
===========================================================================
===========
UNADDRESSED: Here are some further topics that should be addressed.
=========== You can add more. Since I did such a bad job above,
you should be able to come up with a better proposal on one or more of
these.
Interrupts/Handlers {We need these as abstract services.
I would be real pleased if Will Clinger and Kent
Dybvig to got together to propose something (hint)}
Storage Recycling (GC), pre- and post-gc hooks.
Tables, Hashing, [Populations]
File Seeking {The Pascal Standard has a reasonable file specification}
Foreign Function Interface -- {Some say not a real language without it!}
Errorset, Programatic error handling.
File-System Objects and Structured File-Names (as in T or CL)
Numeric Precision & Numerics in general
Syntactic Extensions
===========================================================================
================
GENERAL COMMENTS
================
R3RS is a good job of language specification. But a language without
a reasonably large library of standard functions will not be taken
seriously. I consider the above to be just short of barely adequate.
My hope is to come to a concensus in time to get a reasonable library
appendix in the IEEE Scheme Standard. I could use some help.
Thanks in advance,
-Ken kend@mrloog.LA.TEK.COM
==================================E=O=F====================================
∂19-Mar-89 1823 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Wired numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 18:23:32 PST
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Mar 89 04:06:36 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA05893@chamartin.AI.MIT.EDU>; Fri, 17 Mar 89 11:26:05 -0500
Date: Fri, 17 Mar 89 11:26:05 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903171626.AA05893@chamartin.AI.MIT.EDU>
To: ziggy@VX.LCS.MIT.EDU
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Fri, 10 Mar 89 12:49:35 EST <2814544175-9975825@RTS-8>
Subject: Wired numeric predicates?
Reply-To: jinx@zurich.ai.mit.edu
I understand your rationale for not wanting numeric predicates to be special
forms. The reason I brought it up was that I am a Teaching Assistant in an
undergrad course this term that uses Scheme. A student raised the issue since
it seems natural to think of (< x1 x2 x3...) as being the AND of each of the
individual two-step comparisons. The resemblence between this and the AND
form were sufficiently strong that the student conveniently ignored the fact
that we explicitly describe < as being a *procedure* and not as a *special
form*... I guess people naturally don't look carefully at things that they
consider ``intuitively obvious''. (Actually, MIT Scheme also defines AND to be
a procedure, but we had blown this at the time... the student wanted to know
about MACScheme).
Minor comments:
6.001 Scheme has AND as a procedure because SICP used it that way.
AND is a special form in MIT Scheme, of which 6.001 is not a subset.
I haven't thought about it carefully, but it may not be reasonable
(unless it is defined that way) to implement n-ary < and friends as
the "AND accumulation" of binary <. Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact, and this
value may have to be used consistently afterwards.
∂19-Mar-89 1824 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 18:24:16 PST
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Mar 89 07:54:13 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA06322@chamartin.AI.MIT.EDU>; Sat, 18 Mar 89 07:55:29 -0500
Date: Sat, 18 Mar 89 07:55:29 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903181255.AA06322@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 17 Mar 89 17:07:16 PST (Fri) <8903180107.AA03798@mrloog.LA.TEK.COM>
Subject: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Reply-To: jinx@zurich.ai.mit.edu
Some general comments on your proposal:
1) We certainly need most of the functionality you have suggested.
2) I think it's premature to standardize on something like this for
IEEE. Proposals along these lines should certainly be considered for
R5RS.
Comments on individual issues:
1) IMPLEMENTATION-INFORMATION: I'd much rather see strings returned.
They are unlikely to be used often, so the extra time spent in the
comparison should not be important. The analogous MIT Scheme
procedure returns a vector of strings and numbers.
Why is SCHEME-IMPLEMENTATION needed, given IMPLEMENTATION-INFORMATION?
2) FORMAT: I assume you mean the current OUTPUT port when <port> is #t,
rather than the current INPUT port. I don't mind FORMAT, but I think
that Chris Hanson has some objections to it, which is why MIT Scheme
has flip-flopped between having it and not.
3) PRETTY-PRINT: I would like to extend it in the following way: If
<sexp> is a procedure object rather than a Sexp, it's source code (or
suitable substitute if compiled and source is not available) is
printed instead.
4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.
(ABORT-TO-NEAREST-REPL <thunk>)
fetches a continuation created by the nearest repl (nearest in systems where
there is more than one, like MIT Scheme, the top level one if there is
only one) and executes <thunk> with this continuation.
Thus
(define (reset)
(abort-to-nearest-repl (lambda () unspecific)))
(define (fatal-error message . irritants)
(abort-to-nearest-repl
(lambda ()
(for-each (lambda (unused-arg)
(display #\space)
(display obj))
(apply format #t message irritants))
(newline))))
I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.
I'm not too attached to the name ABORT-TO-NEAREST-REPL. The similar
MIT Scheme procedure is called ABORT->NEAREST.
5) ERROR must be a special form in order to get the environment of
the "call". In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)
6) TRACE and UNTRACE: Do you want identifiers or procedure objects?
If you want procedure objects you are forcing implementations to make
them modifiable.
If you want identifiers you must make TRACE and UNTRACE special forms
so they can get the environment of the "call" and therefore alter the
correct bindings.
7) ALIAS: Why can't you just use (define <alias> <original>) ?
A different question is making your compiler generate reasonable code,
but this should not be difficult.
If you want to use it for special forms instead (like comment), I'd
rather wait until we have some way of creating syntactic extensions.
8) COMMENT: I think you want to divorce the issues of reading and
ignoring a form. Maybe it's just a bug in your specification, but I'm
not sure why you involve the reader at all.
9) UNLESS and WHEN: I would wait for syntactic extensions. I
generally object to adding spurious special forms.
10) COMMENT-WHEN: Does this imply read time or syntax time evaluation?
Again, I'd wait for macros.
11) THE-CURRENT-DATE and THE-CURRENT-TIME: I assume you mean exact
integers for fixnums.
12) string ports: I like them (and use them frequently), but I think
we should bite the bullet and have constructors and selectors for ports:
(MAKE-INPUT-PORT <char-peeker> <char-reader> <char-ready-predicate> <close>)
(WITH-INPUT-PORT-COMPONENTS <input-port>
(lambda (peek read ready? close)
<actions>))
(MAKE-OUTPUT-PORT <char-writer> <string-writer> <close>)
(WITH-OUTPUT-PORT-COMPONENTS <output-port>
(lambda (char-write string-write close)
<actions>))
String ports can easily be built on top of this, but other ports (to
editor buffers, transcripting and tee'd ports, etc) can be built as well.
13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
14) BOUND?: must be a special form, since it has no way of obtaining
the environment of the "call".
15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
but not in internal definition position, and that makes them appear
strange. I don't think that special forms like DEFINE-IF-<mumble> is
the way to conditionalize code, but this is a matter of taste.
I would also change the EQ? test to STRING=? given my comments about
IMPLEMENTATION-INFORMATION.
16) SORT and SORT!: You probably want (SORT <obj> <binary-predicate>).
I don't know what predicate to use by default.
17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.
∂19-Mar-89 2143 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #87
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 21:43:33 PST
Date: 20 MAR 89 00:14:31 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #87
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #87 20 MAR 89 00:14:31 EST
Today's Topics:
extend-syntax
----------------------------------------------------------------------
Date: 19 Mar 89 22:18:17 GMT
From: bobg+@andrew.cmu.edu (Robert Steven Glickstein)
Subject: extend-syntax
Message-Id: <IY92Qdy00Vsn829Ftw@andrew.cmu.edu>
I'm just getting started with Scheme and I have MIT's CScheme, release 6.1.2
(microcode 10.2, runtime 13.91, sf 3.13). I've been reading Dybvig's "The
Scheme Programming Language", and I'd like to try out some of the examples in
Dybvig's book. Dybvig's Scheme ("Chez Scheme") differs from CScheme in that
CScheme does not have the "extend-syntax" function. Does anyone have a R3RS
definition of extend-syntax?
Thanks in advance,
-Bob Glickstein
-Information Technology Center, Carnegie Mellon University, Pittsburgh, PA
------------------------------
End of Scheme Digest
********************
∂20-Mar-89 2135 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #88
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 89 21:35:22 PST
Date: 21 MAR 89 00:14:36 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #88
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #88 21 MAR 89 00:14:36 EST
Today's Topics:
Scheme Digest #86
----------------------------------------------------------------------
From: Ashok Gupta <gupta@prl.philips.co.uk>
Date: Mon, 20 Mar 89 08:51:28 bst
Message-Id: <375.8903200851@apollo12.prl.philips.co.uk>
Subject: Re: Scheme Digest #86
The tests are in the book "Performance & Evaluation of Lisp Systems"
by Richard Gabriel.
------------------------------
End of Scheme Digest
********************
∂21-Mar-89 0325 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Weird numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 03:25:17 PST
Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 21 Mar 89 06:18:59 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA28863; Tue, 21 Mar 89 03:20:09 PDT
Date: Tue, 21 Mar 89 03:20:09 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903211120.AA28863@kestrel.arpa>
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Sun, 19 Mar 89 17:22 EST <19890319222206.1.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Weird numeric predicates?
Date: Sun, 19 Mar 89 17:22 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Date: Fri, 17 Mar 89 11:26:05 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
I haven't thought about it carefully, but it may not be reasonable
(unless it is defined that way) to implement n-ary < and friends as
the "AND accumulation" of binary <. Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact, and this
value may have to be used consistently afterwards.
If <= is to behave transitively, even on inexact arguments, then you have
to coerce inexact number to exact numbers in order to perform comparisons.
(Or you must behave as if you did.) To see why, consider the following
three numbers:
(DEFINE A (- (EXPT 10 38) 1))
(DEFINE B 1E38)
(DEFINE C (+ (EXPT 10 38) 1))
Assuming your implementation has an exact representation for A and C
(probably as a BIGNUM) and the inexact B is represented in a floating point
format with less (probably far less!) that 38 digits of precision, then
coercing either A or C to inexact will most likely return B. If comparison
predicates coerce EXACT->INEXACT, then the following will be true:
(<= C B) ==> #T
(<= B A) ==> #T
(<= C A) ==> #F
Perhaps worse:
(= C B) ==> #T
(= B A) ==> #T
(= C A) ==> #F
If instead comparison predicates coerce INEXACT->EXACT then consistently
transitive answers will be obtained.
I think that what this example really speaks to is the limitations of
implicit arithmetic coercion. It is really a form of DWIM. (I am
opposed to DWIM in any form -- some forms more than others.)
To clarify what I am talking about, let me sketch an alternative set
of arithmetic primitives for a hypothetical version of Scheme. (This
is not yet intended to be a formal proposal.) Suppose there were two
sets of primitives, one for exact arithmetic, one for inexact; for
instance, exact equality might be EX= and inexact equality INEX=.
Both these primitives are required to accept both kinds of numbers as
arguments (this is *not* an efficiency hack to allow them to make
assumptions about the argument types); they then coerce both arguments
to exact or inexact, respectively, before making the comparison.
My claim is that distinguishing the two primitives makes sense because
they are really two different operations; INEX= really asks if the
arguments are equal within the floating-point precision of the
implementation. Similar arguments hold for the other arithmetic
operations.
Implicit coercion is DWIMmy because it asks the system to choose one
of these two arguably different operations based on what the user
probably meant. Especially in an untyped language where the
discrimination is made at runtime, this is an excellent way to produce
unmaintainable code. (Suppose you have a program that does a lot of
arithmetic and, in debugging it, you find an inexact value where you
expected an exact one. How are you going to find out where the
inexact operand was introduced?)
Notice that, given Alan's example values, both EX= and INEX= are
transitive:
(EX= C B) ==> #F
(EX= B A) ==> #F
(EX= C A) ==> #F
(INEX= C B) ==> #T
(INEX= B A) ==> #T
(INEX= C A) ==> #T
Same for EX<= and INEX<=.
I am well aware that I am bucking Lisp tradition in making this
proposal. However, there have been times when I was trying to do
numerics in Lisp when I wished I had a strongly-typed language, for
just this kind of reason -- a float would creep in somewhere and I
would have trouble finding where. In (most?) strongly-typed languages
one still doesn't explicitly specify the mode in which the operation
is done separately from the types of the operands, but at least the
coercion rules apply at compile time.
(If you really want to make floating-point programs portable, how
'bout an optional third argument to *every* INEXop which is the number
of bits of precision (mantissa)? (And even a fourth, which is the
number of bits of exponent? (And then there's rounding...)))
To restate: I am basically proposing that the mode of each arithmetic
operation (exact or inexact; should there also be integer mode?) be
specified independently of the types of the operands.
-- Scott
∂21-Mar-89 1840 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 18:33:41 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 21 Mar 89 21:24:34 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa13380; 21 Mar 89 21:19 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa28590; 21 Mar 89 21:12 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA10384; Tue, 21 Mar 89 18:05:27 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA03847; Tue, 21 Mar 89 18:04:16 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA22716; Tue, 21 Mar 89 18:05:51 pst
Message-Id: <8903220205.AA22716@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU,
scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
In-Reply-To: Your message of Sat, 18 Mar 89 07:55:29 -0500.
<8903181255.AA06322@chamartin.AI.MIT.EDU>
Date: 21 Mar 89 18:05:49 PST (Tue)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
JINX,
Some general comments on your general comments:
--------
Some general comments on your proposal:
1) We certainly need most of the functionality you have suggested.
I am happy that someone else thinks so.
2) I think it's premature to standardize on something like this for
IEEE. Proposals along these lines should certainly be considered for
R5RS.
On the contrary, we need to standardize library issues as soon as
possible to keep divergence from preventing portability. The IEEE
standard is a good place for this. I really would rather see only
*language* issues in RnRS. Most languages standardize too late--after
implementations have significantly diverged--and there is hell to pay as
each implementor tries to get *his* dialect as *the* standard (e.g.
ATLAS). Currently, we have a portable language, but not portable code.
I believe that there is sufficient practical experience to have a
standard interface to common functionality and that the IEEE standard
needs such an interface to be viable.
Comments on individual issues:
1) IMPLEMENTATION-INFORMATION: I'd much rather see strings returned.
They are unlikely to be used often, so the extra time spent in the
comparison should not be important. The analogous MIT Scheme
procedure returns a vector of strings and numbers.
A vector is fine by me. Strings and exact integers are fine by me. Anyone?
Why is SCHEME-IMPLEMENTATION needed, given IMPLEMENTATION-INFORMATION?
I am happy to flush this.
2) FORMAT: I assume you mean the current OUTPUT port when <port> is #t,
rather than the current INPUT port. I don't mind FORMAT, but I think
that Chris Hanson has some objections to it, which is why MIT Scheme
has flip-flopped between having it and not.
Yes, I do mean OUTPUT port (I am sure typo's abound). Given string
ports, FORMAT is easy to implement and very useful. Chris?
3) PRETTY-PRINT: I would like to extend it in the following way: If
<sexp> is a procedure object rather than a Sexp, it's source code (or
suitable substitute if compiled and source is not available) is
printed instead.
Fine.
4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.
(ABORT-TO-NEAREST-REPL <thunk>)
fetches a continuation created by the nearest repl (nearest in systems where
there is more than one, like MIT Scheme, the top level one if there is
only one) and executes <thunk> with this continuation.
Thus
(define (reset)
(abort-to-nearest-repl (lambda () unspecific)))
(define (fatal-error message . irritants)
(abort-to-nearest-repl
(lambda ()
(for-each (lambda (unused-arg)
(display #\space)
(display obj))
(apply format #t message irritants))
(newline))))
How is the "nearest repl" known to the runtime system? How does a
Scheme system recognize that a function is a (possibly user written)
repl? I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?
I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.
Perhaps I'm confused. You don't want a FATAL ERROR to abort a
computation? This might be a valuable behavior in a (possibly
parallel) multi-tasking search situation. What would be the
difference between FATAL-ERROR and ERROR ? The thing that I am trying
to clean up here is the confusion over CERROR vs ERROR as to when an
error is fatal and when recoverable. `ERROR' is pretty common and
typing RECOVERABLE-ERROR gets a bit tedious.
I'm not too attached to the name ABORT-TO-NEAREST-REPL. The similar
MIT Scheme procedure is called ABORT->NEAREST.
I don't see this as a common usage in other Scheme implementations.
Anyone?
5) ERROR must be a special form in order to get the environment of
the "call". In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)
ERROR works just fine as a procedure in many systems (Chez Scheme, T,
and MacScheme). The fact that MIT Scheme has a non-standard way to
access the environment makes it convenient for ERROR to be a special
form in MIT Scheme. I would really prefer that you propose an
standard environment mechanism if you want to insist that ERROR must
be a special form (or better yet, a standard error handling
mechanism). I really prefer procedures to special forms.
How much code would break if I change the wording to allow ERROR to be a
procedure *or* a special form?
6) TRACE and UNTRACE: Do you want identifiers or procedure objects?
If you want procedure objects you are forcing implementations to make
them modifiable.
If you want identifiers you must make TRACE and UNTRACE special forms
so they can get the environment of the "call" and therefore alter the
correct bindings.
These are procedures in MacScheme and PCScheme and special forms in
Chez Scheme and T. PCScheme, T, and MacScheme all require procedure
objects rather than procedure names. I will change the wording to
indicate this and allow TRACE and UNTRACE to be either procedures or
special forms.
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
A different question is making your compiler generate reasonable code,
but this should not be difficult.
If you want to use it for special forms instead (like comment), I'd
rather wait until we have some way of creating syntactic extensions.
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
Unless someone in Indiana moves fast, we will not have syntactic
extensions in R4RS. When we get syntactic extensions, these are easy
to `define'. I strongly suspect that the number of Scheme
implementations is going to double every year or two for a while. We
need to be heading off the problems that will exist in 5 years unless
fixed now.
8) COMMENT: I think you want to divorce the issues of reading and
ignoring a form. Maybe it's just a bug in your specification, but I'm
not sure why you involve the reader at all.
I will elide the reference to READ.
9) UNLESS and WHEN: I would wait for syntactic extensions. I
generally object to adding spurious special forms.
We don't have syntactic extensions. I see these in a lot of code. I
believe they are common usage. Who else out there objects to these?
Who else uses them?
10) COMMENT-WHEN: Does this imply read time or syntax time evaluation?
Again, I'd wait for macros.
I was thinking of Chez Scheme's EVAL-WHEN when I wrote this (but we
don't have EVAL!). Perhaps I should withdraw it and use Kent's
definition instead. Kent?
11) THE-CURRENT-DATE and THE-CURRENT-TIME: I assume you mean exact
integers for fixnums.
Yes.
12) string ports: I like them (and use them frequently), but I think
we should bite the bullet and have constructors and selectors for ports:
(MAKE-INPUT-PORT <char-peeker> <char-reader> <char-ready-predicate> <close>)
(WITH-INPUT-PORT-COMPONENTS <input-port>
(lambda (peek read ready? close)
<actions>))
(MAKE-OUTPUT-PORT <char-writer> <string-writer> <close>)
(WITH-OUTPUT-PORT-COMPONENTS <output-port>
(lambda (char-write string-write close)
<actions>))
String ports can easily be built on top of this, but other ports (to
editor buffers, transcripting and tee'd ports, etc) can be built as well.
I will add this, but keep string ports as a common usage.
13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
So you want 3..258? I think that silent masking of overflow would be
pretty random.
14) BOUND?: must be a special form, since it has no way of obtaining
the environment of the "call".
I will update to be either procedure or special form.
15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
but not in internal definition position, and that makes them appear
strange. I don't think that special forms like DEFINE-IF-<mumble> is
the way to conditionalize code, but this is a matter of taste.
I don't see how these differ from non-conditional defines, which also
appear strange. I would be very happy to see a better proposal on
conditional compilation.
I would also change the EQ? test to STRING=? given my comments about
IMPLEMENTATION-INFORMATION.
Yes, if this is the concensus.
16) SORT and SORT!: You probably want (SORT <obj> <binary-predicate>).
I don't know what predicate to use by default.
Yes, a <binary-predicate> is required. There is no default. Mea typola.
17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.
PCScheme has an AUTOLOAD-FROM-FILE procedure. I will have the definition
allow either a procedure or a special form.
----------
Thank you very much for your input.
-The Reader
∂21-Mar-89 1956 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 19:56:35 PST
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 21 Mar 89 22:47:14 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA09548@chamartin.AI.MIT.EDU>; Tue, 21 Mar 89 22:47:37 -0500
Date: Tue, 21 Mar 89 22:47:37 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903220347.AA09548@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 21 Mar 89 18:05:49 PST (Tue) <8903220205.AA22716@mrloog.LA.TEK.COM>
Subject: Portability (long)
Reply-To: jinx@zurich.ai.mit.edu
4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.
(ABORT-TO-NEAREST-REPL <thunk>)
...
How is the "nearest repl" known to the runtime system? How does a
Scheme system recognize that a function is a (possibly user written)
repl? I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?
The idea is that the runtime system provides facilities for building
repls which interact with these abort procedures (there are many in
MIT Scheme), and can provide additional functionality. While this
procedure is useful for writing things like RESET, it is useful in its
own right: interrupt characters cause invocations of such procedures
in MIT Scheme. Dan Friedman needs something like
ABORT-TO-NEAREST-REPL for some of the stuff he does as well.
I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.
Perhaps I'm confused. You don't want a FATAL ERROR to abort a
computation? This might be a valuable behavior in a (possibly
parallel) multi-tasking search situation. What would be the
difference between FATAL-ERROR and ERROR ? The thing that I am trying
to clean up here is the confusion over CERROR vs ERROR as to when an
error is fatal and when recoverable. `ERROR' is pretty common and
typing RECOVERABLE-ERROR gets a bit tedious.
I don't think such things as non-recoverable errors exist, thus I
would not like to have anything like FATAL-ERROR which by definition
implies non-recovery.
I'm not too attached to the name ABORT-TO-NEAREST-REPL. The similar
MIT Scheme procedure is called ABORT->NEAREST.
I don't see this as a common usage in other Scheme implementations.
Anyone?
I don't know what Dan Friedman is using, but, again, he's told me that
he would like to see it in some standard.
**********
5) ERROR must be a special form in order to get the environment of
the "call". In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)
ERROR works just fine as a procedure in many systems (Chez Scheme, T,
and MacScheme). The fact that MIT Scheme has a non-standard way to
access the environment makes it convenient for ERROR to be a special
form in MIT Scheme. I would really prefer that you propose an
standard environment mechanism if you want to insist that ERROR must
be a special form (or better yet, a standard error handling
mechanism). I really prefer procedures to special forms.
I'm very confused. As far as I know, all correct scheme
implementations must be properly tail recursive, and this is what forces
error to be a special form. For example, in
(define (foo x y)
(if (valid? x)
(error "foo: Invalid x" x)
(operate-on x y)))
if ERROR is an ordinary procedure, FOO tail recurses into it, which
means taht a debugger has no way of finding out what Y was.
Furthermore, a debugger can't even find out that error was called from FOO!
Either ERROR is mostly useless, or calls to ERROR must be treated
specially by the compiler, making these calls special forms by definition.
I only wrote what MIT Scheme does as an example of a possible
expansion for error. Another possibility is to have
(error . args)
expand into
((error-procedure . args))
which guarantees that ERROR-PROCEDURE is not invoked in tail recursive
position.
The problem is not first class environments, but tail recursion!
How much code would break if I change the wording to allow ERROR to be a
procedure *or* a special form?
Yuck!
**********
6) TRACE and UNTRACE: Do you want identifiers or procedure objects?
If you want procedure objects you are forcing implementations to make
them modifiable.
If you want identifiers you must make TRACE and UNTRACE special forms
so they can get the environment of the "call" and therefore alter the
correct bindings.
These are procedures in MacScheme and PCScheme and special forms in
Chez Scheme and T. PCScheme, T, and MacScheme all require procedure
objects rather than procedure names. I will change the wording to
indicate this and allow TRACE and UNTRACE to be either procedures or
special forms.
As an aside, they are procedures in MIT Scheme, requiring procedures
as arguments.
The reason why TRACE and UNTRACE must be special forms if they require
identifiers has nothing to do with first class environments but
with tail recursion. It is similar to the case of ERROR:
(let ((foo (lambda () <some code>)))
(trace 'foo))
if TRACE is an ordinary procedure, it cannot see the binding of foo
because of lexical scoping, and cannot parse the stack to find it due
to tail recursion, which has forced the LET frame to be reclaimed.
You may reply that TRACE applies only to "top level bindings", but
such beasts do not exist in MIT Scheme or in T.
**********
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
...
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
Unless someone in Indiana moves fast, we will not have syntactic
extensions in R4RS. When we get syntactic extensions, these are easy
to `define'. I strongly suspect that the number of Scheme
implementations is going to double every year or two for a while. We
need to be heading off the problems that will exist in 5 years unless
fixed now.
Although I agree with the gist of your argument, I don't see how this
applies to ALIAS. Either you have a special form in the first place
which you are providing an alias for, or you do not. If you have it,
you can use the original. If you don't, ALIAS won't solve your
problem: In order for ALIAS to be of any help in portability, you need
conditional compilation or conditional loading according to
implementation. Whatever you use to discriminate according to
implementation, you can use to provide definitions of the "missing"
special forms using each implementation's syntactic extension
facilities. As far as I know, all implementations have ways of
providing syntactic extensions.
**********
13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
So you want 3..258? I think that silent masking of overflow would be
pretty random.
I meant that 8 bit bytes are pretty arbitrary. It would be nice to be
able to read in (for example) 16 bit quantities, 32 bit quantities,
etc. Furthermore, although rare, there are still machines around that
are not based on 8 bit bytes, and they may become popular again in the
future. I would hate to see current hardware praxis getting into
the language.
**********
14) BOUND?: must be a special form, since it has no way of obtaining
the environment of the "call".
I will update to be either procedure or special form.
The problem is similar to that of ERROR and TRACE. Consider, for example
(let ((x 3))
(if (bound? 'X)
#t
#f))
If BOUND? is an ordinary procedure, it has no access to the
environment of the call, which may not even exist by the time BOUND?
is entered.
Declaring that BOUND? acts only on "top level" identifiers does not
solve the problem either.
**********
15) DEFINE-IF-<mumble>: These make sense only at top level of a file,
but not in internal definition position, and that makes them appear
strange. I don't think that special forms like DEFINE-IF-<mumble> is
the way to conditionalize code, but this is a matter of taste.
I don't see how these differ from non-conditional defines, which also
appear strange. I would be very happy to see a better proposal on
conditional compilation.
The problem is clearest with DEFINE-IF-UNBOUND
(define (foo x)
(define-if-unbound bar (+ x 3))
(list x bar))
The contour where BAR is to be found depends on whether BAR is
available in the load-time environment, which is not visible at
compile time. The code that the compiler must issue is not always
obvious, and it is always complicated. Ordinary internal definitions
do not have such problems. Would you consider LETREC-IF-UNBOUND?
Top level definitions do not present this problem if the compiler
treats references to such variables the same way that it treats
references to "globally" free variables, and are therefore handled by
the linker.
DEFINE-IF-IMPLEMENTATION has a similar problem in the presence of
separate compilation.
In general, as appealing as DEFINE-IF-<mumble> appears, I don't think
it is the way to achieve portability.
The way we tend to do that sort of thing around here is as follows:
Each program has two additional files, a compilation file, and a
loading file (they are often merged into one, but conceptually there
are two). These files contain ordinary code which test the
implementation, query the user, etc, and then conditionally compile or
load the appropriate files.
For example, consider a hypothetical system consisting of three common
files (file1, file2, and file3), and for each implementation there is
an additional file with the implementation dependencies (including
syntactic extensions). The compilation file would contain something like
(case (car (implementation-information))
(("Implementation1")
(compile-file "implementation1")
(load-file "implementation1")) ; To provide syntactic extensions
(("Implementation2")
(compile-file "implementation2")
(load-file "implementation2"))
...
(else
(error "Unknown implementation -- please port")))
(compile-file "file1")
(compile-file "file2")
(compile-file "file3")
The loading file would have similar code which would load the
appropriate parts of the system.
Although this mechanism is cumbersome for small programs, it works
very well for relatively large systems, and avoids rats' nests of
unreadable conditionally compiled code.
**********
17) AUTOLOAD: Must be a special form like DEFINE and DEFINE-IF-<mumble>.
PCScheme has an AUTOLOAD-FROM-FILE procedure. I will have the definition
allow either a procedure or a special form.
Same problem as TRACE, BOUND?, etc. I assume that in PCScheme it
always loads into the "global" environment.
∂21-Mar-89 2143 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Weird numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 21:43:38 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Mar 89 23:34:10 EST
Received: from PIGPEN.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 21 MAR 89 23:38:28 EST
Date: Tue, 21 Mar 89 23:31 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Weird numeric predicates?
To: gyro@kestrel.arpa
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8903211120.AA28863@kestrel.arpa>
Message-ID: <19890322043132.5.ALAN@PIGPEN.AI.MIT.EDU>
Date: Tue, 21 Mar 89 03:20:09 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Date: Sun, 19 Mar 89 17:22 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
....
If instead comparison predicates coerce INEXACT->EXACT then consistently
transitive answers will be obtained.
I think that what this example really speaks to is the limitations of
implicit arithmetic coercion. It is really a form of DWIM. (I am
opposed to DWIM in any form -- some forms more than others.)
The first few times I read this paragraph I read it as accusing me of
advocating some form of DWIM. I think I have now convinced myself that the
"it" in "It is really a form of DWIM" refers to the notion of coercing
between exact and inexact numbers in certain circumstances, and is not
directed at anything that I said. Nevertheless, since the inflammatory
word "DWIM" has been used in close proximity to my message, I feel
compelled to restate the rather simple point that I was trying to make.
My entire point was that:
Given that the current design for Scheme calls for the arithmetic
primitives to accept exact or inexact arguments in any combination, then:
1. If the comparison predicates compare exact numbers to inexact numbers
by first coercing the exacts to inexacts, then the comparison
predicates will not necessarily be transitive. (Because
EXACT->INEXACT is not an injection in the usual floating point
implementation of inexact numbers.)
2. If the comparison predicates compare exact numbers to inexact numbers
by first coercing the inexacts to exacts, then the comparison
predicates probably will be transitive. (Because INEXACT->EXACT is an
order preserving injection in the usual floating point implementation
of inexact numbers.)
Now, if you would like to argue with the given that the arithmetic
primitives accept mixed exact and inexact arguments, we can do that. You
might even find that you can convince me. But I don't want anyone to lose
track of what I originally said because someone stigmatized it by using the
word "DWIM" in its presence. I was not proposing anything that could be
described as DWIM, and in fact I was not proposing anything at all. I was
pointing out the consequences of two different implementations of the
arithmetic comparison predicates. Consequences, I might add, that most
implementors seem to be unaware of.
∂21-Mar-89 2255 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #89
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 22:54:07 PST
Date: 22 MAR 89 00:14:49 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #89
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #89 22 MAR 89 00:14:49 EST
Today's Topics:
Scheme/ Lisp Differentiation
Billiard Ball Simulator
Wanted: Comparison of OakLisp and CLOS object systems
----------------------------------------------------------------------
Date: 18 Mar 89 21:01:04 GMT
From: tboutell@vax1.acs.udel.edu (Thomas B Boutell)
Subject: Scheme/ Lisp Differentiation
Message-Id: <3130@udccvax1.acs.udel.EDU>
I realize I'm not the first to post this question, but I've seen other
postings of it and no replies, curiously enough. What are the differences
between Scheme and Lisp, essentially?
--
*ping!* KIDS, DON'T TRY THIS AT HOME! "in bed. EVERYTHING ends with 'in bed.'"
"Look, it's Scooby Doo in bondage!" DISCLAIMER: Datclaimer. Da wun ova there.
"Maybe we all is spiderman. Maybe dat's your pwoblem too." "Want a cookie?"
What happens if I decrement the user count? (scream in the distance.) *ping!*
------------------------------
Date: Tue, 21 Mar 89 09:07:17 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903211707.AA12277@sesame.Stanford.EDU>
Subject: Billiard Ball Simulator
I have been innundated with request for my Billiard Ball Simulator so despite
its long length I have decided to post the code. Please note its limitations.
This program is NOT a usefull simulator for Billiards, but only a medium sized
test program.
Morry Katz
katz@polya.stanford.edu
The following code is a quick hack I wrote for testing my parallelization
system on a medium sized program (larger than a toy). It is sort of a billiard
ball simulator (see comments at header of program).
CAVEAT EMPTOR:
1) I make no promises that this code is bug free. It seems to work on simple
test cases, but I have not tested it exhaustively.
2) It uses the MIT Cscheme macro package. A conversion to extend-syntax
should be simple. Also, the code could probably be converted to just use
functions, with some performance loss. (If you do either of the above,
please let me know since it seems silly for multiple people to do the same
work.
;;;
;;; BILLIARD.SCM: This file contains code for a very simple billiard ball
;;; simulator. The simulation takes place in two dimensions.
;;; The balls are really disks in that their height is not taken
;;; into account. All interactions are assumed to be
;;; frictionless so spin in irrelevant and not accounted for.
;;; (See section on limitations.)
;;;
;;; NOTES: A simulation is initiated by creating a number of balls and bumpers
;;; and and specifying a duration for the simulation. For each ball,
;;; its mass, radius, initial position, and initial velocity must be
;;; specified. For each bumper, the location of its two ends must be
;;; specified. (Bumpers are assumed to have zero width.)
;;;
;;; A sample run might be started as follows:
;;; (simulate
;;; (list (make-ball 2 1 9 5 -1 -1)
;;; (make-ball 4 2 2 5 1 -1))
;;; (list (make-bumper 0 0 0 10)
;;; (make-bumper 0 0 10 0)
;;; (make-bumper 0 10 10 10)
;;; (make-bumper 10 0 10 10))
;;; 30)
;;;
;;; It would create one billiard ball of mass 2 and radius 1 at position
;;; (9, 5) with initial velocity (-1, -1) and a second ball of mass 4
;;; and radius 2 at position (2, 5) with initial velocity (1, -1). The
;;; table would be a 10X10 square. (See diagram below)
;;;
;;; +---------------------------+
;;; | |
;;; | |
;;; | XXXX |
;;; | XXXXXXXX XX |
;;; |XXXXXX4XXXXX XXX2XX|
;;; | XXXXXXXX /XX |
;;; | XXXX \ |
;;; | |
;;; | |
;;; +---------------------------+
;;;
;;; LIMITATIONS: This simulator does not handle 3 body problems correctly. If
;;; 3 objects interact at one time, only the interactions of 2 of
;;; the bodies will be accounted for. This can lead to strange
;;; effects like balls tunneling through walls and other balls.
;;; It is also possible to get balls bouncing inside of each
;;; other in this way.
;;;
!
;;MAKE-QUEUE-RECORD returns a queue record with the given next, previous, and
;;value values
;;NEXT = The next record pointer
;;PREV = The previous record pointer
;;REST = A list of values for any optional fields (this can be used for
;; creating structure inheritance)
(define-macro (make-queue-record next prev . rest)
`(vector ,next ,prev ,@rest))
;;QUEUE-RECORD-NEXT returns the next field of the given queue record
;;QUEUE-RECORD = The queue record whose next field is to be returned
(define-macro (queue-record-next queue-record)
`(vector-ref ,queue-record 0))
;;SET-QUEUE-RECORD-NEXT! sets the next field of the given queue record
;;QUEUE-RECORD = The queue record whose next field is to be set
;;VALUE = The value to which the next field is to be set
(define-macro (set-queue-record-next! queue-record value)
`(vector-set! ,queue-record 0 ,value))
;;QUEUE-RECORD-PREV returns the prev field of the given queue record
;;QUEUE-RECORD = The queue record whose prev field is to be returned
(define-macro (queue-record-prev queue-record)
`(vector-ref ,queue-record 1))
;;SET-QUEUE-RECORD-PREV! sets the prev field of the given queue record
;;QUEUE-RECORD = The queue record whose prev field is to be set
;;VALUE = The value to which the prev field is to be set
(define-macro (set-queue-record-prev! queue-record value)
`(vector-set! ,queue-record 1 ,value))
;;QUEUE-RECORD-LEN returns the length of a queue record which has no optional
;;fields
(define-macro (queue-record-len) 2)
;;QUEUE-HEAD returns a dummy record at the end of the queue with the record
;;with the smallest key.
;;QUEUE = the queue whose head record is to be returned
(define-macro (queue-head queue)
`(vector-ref ,queue 0))
;;QUEUE-TAIL returns a dummy record at the end of the queue with the record
;;with the largest key.
;;QUEUE = the queue whose tail record is to be returned
(define-macro (queue-tail queue)
`(vector-ref ,queue 1))
;;QUEUE-<? returns the less-than comparitor to be used in sorting
;;records into the queue
;;QUEUE = The queue whose comparitor is to be returned
(define-macro (queue-<? queue)
`(vector-ref ,queue 2))
!
;;MAKE-SORTED-QUEUE returns a queue object. A queue header is a vector which
;;contains a head pointer, a tail pointer, and a less-than comparitor.
;;QUEUE-<? = A predicate for sorting queue items
(define (make-sorted-queue queue-<?)
(let ((queue
(vector
(make-queue-record ;The queue head record has no initial
'() ;next, previous, or value values
'())
(make-queue-record ;The queue tail record has no intial
'() ;next, previous, or value values
'())
queue-<?)))
(set-queue-record-next!
(queue-head queue)
(queue-tail queue))
(set-queue-record-prev!
(queue-tail queue)
(queue-head queue))
queue))
;;MAKE-EVENT-QUEUE-RECORD returns an event queue record with the given next,
;;previous, object, and collision-time values
;;NEXT = The next record pointer
;;PREV = The previous record pointer
;;OBJECT = The simulation object associated with this record
;;COLLISION-TIME = The collision time for this object
(define-macro (make-event-queue-record next prev object collision-time)
`(make-queue-record ,next ,prev ,object ,collision-time))
;;EVENT-QUEUE-RECORD-OBJECT returns the object associated with the given record
;;QUEUE-RECORD = The queue record whose object field is to be returned
(define-macro (event-queue-record-object queue-record)
`(vector-ref ,queue-record ,(queue-record-len)))
;;EVENT-QUEUE-COLLISION-TIME returns the collision time associated with the
;;given queue record
;;QUEUE-RECORD = The queue record whose collision time field is to be returned
(define-macro (event-queue-record-collision-time queue-record)
`(vector-ref ,queue-record ,(1+ (queue-record-len))))
;;SET-EVENT-QUEUE-COLLISION-TIME! sets the collision time associated with the
;;given queue record
;;QUEUE-RECORD = The queue record whose collision time field is to be returned
;;VALUE = The value to which it is to be set
(define-macro (set-event-queue-record-collision-time! queue-record value)
`(vector-set! ,queue-record ,(1+ (queue-record-len)) ,value))
!
;;QUEUE-INSERT inserts the given record in the given queue based on its value
;;QUEUE = The queue into which the record is to be inserted
;;QUEUE-RECORD = The record to be inserted in the queue
(define (queue-insert queue queue-record)
(define (actual-insert insert-record next-record)
(if (or ;If the insert position has been found
(eq? next-record ;or the end on the queue has been
(queue-tail queue)) ;reached
((queue-<? queue)
insert-record
next-record))
(sequence ;Link the insert record into the queue
(set-queue-record-next! ;just prior to next-record
(queue-record-prev
next-record)
insert-record)
(set-queue-record-prev!
insert-record
(queue-record-prev
next-record))
(set-queue-record-next!
insert-record
next-record)
(set-queue-record-prev!
next-record
insert-record))
(actual-insert ;Else, continue searching for the
insert-record ;insert position
(queue-record-next
next-record))))
(actual-insert ;Search for the correct position to
queue-record ;perform the insert starting at the
(queue-record-next ;queue head and perform the insert
(queue-head queue)))) ;once this position has been found
;;QUEUE-REMOVE removes the given queue record from its queue
;;QUEUE-RECORD = The record to be removed from the queue
(define (queue-remove queue-record)
(set-queue-record-next!
(queue-record-prev
queue-record)
(queue-record-next
queue-record))
(set-queue-record-prev!
(queue-record-next
queue-record)
(queue-record-prev
queue-record)))
;;QUEUE-SMALLEST returns the queue record with the smallest key on the given
;;queue
;;QUEUE = The queue from which the smallest record is to be extracted
(define (queue-smallest queue)
(queue-record-next
(queue-head queue)))
!
;;CLEAR-QUEUE! clears the given queue by destructively removing all the records
;;QUEUE = The queue to be cleared
(define (clear-queue queue)
(set-queue-record-next!
(queue-head queue)
(queue-tail queue))
(set-queue-record-prev!
(queue-tail queue)
(queue-head queue)))
;;EMPTY-QUEUE? returns true if the given queue is empty
;;QUEUE = The queue to be tested for emptiness
(define (empty-queue? queue)
(eq? (queue-record-next
(queue-head queue))
(queue-tail queue)))
!
;;MAKE-SIMULATION-OBJECT returns a simulation object containing the given
;;fields
;;COLLISION-PROCEDURE = A function for processing information about a potential
;; collision between this object and some ball
;;REST = A list of values for any optional fields (this can be used for
;; creating structure inheritance)
(define-macro (make-simulation-object collision-procedure . rest)
`(vector ,collision-procedure ,@rest))
;;SIMULATION-OBJECT-COLLLISION-PROCEDURE returns the collision procedure for
;;the given simulation object
;;OBJECT = The object whose collision procedure is to be returned
(define-macro (simulation-object-collision-procedure object)
`(vector-ref ,object 0))
;;SIMULATION-OBJECT-LEN returns the length of a simulation object which has no
;;optional fields
(define-macro (simulation-object-len) 1)
!
;;ACTUAL-MAKE-BALL returns a ball object
;;BALL-NUMBER = An index into the ball vector for this ball
;;MASS = The ball's mass
;;RADIUS = The ball's radius
;;PX = The x-coordinate of the ball's initial position
;;PY = The y-coordinate of the ball's initial position
;;VX = The x-coordinate of the ball's initial velocity
;;VY = The y-coordinate of the ball's initial velocity
(define-macro (actual-make-ball ball-number mass radius px py vx vy)
`(make-simulation-object
ball-collision-procedure ;The collision procedure for a ball
,ball-number
,mass
,radius
(make-sorted-queue ;The event queue
collision-time-<?)
0 ;Time of last collision
,px ;Position of last collision
,py ; "
,vx ;Velocity following last colliosion
,vy ; "
'() ;No vector of queue records for ball's
;with smaller numbers
'() ;No vector of queue records for bumpers
'() ;No list of balls with larger numbers
'())) ;No global event queue record, yet
(define (make-ball mass radius px py vx vy)
(actual-make-ball '() mass radius px py vx vy))
;;BALL-NUMBER returns the index of the given ball
;;BALL = The ball whose index is to be returned
(define-macro (ball-number ball)
`(vector-ref ,ball ,(simulation-object-len)))
;;SET-BALL-NUMBER! set the index of the given ball to the given value
;;BALL = The ball whose index is to be set
;;VALUE = The value to which it is to be set
(define-macro (set-ball-number! ball value)
`(vector-set! ,ball ,(simulation-object-len) ,value))
;;BALL-MASS returns the mass of the given ball
;;BALL = The ball whose mass is to be returned
(define-macro (ball-mass ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 1)))
;;BALL-RADIUS returns the radius of the given ball
;;BALL = The ball whose radius is to be returned
(define-macro (ball-radius ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 2)))
;;BALL-EVENT-QUEUE returns the sort queue of collision events for the given
;;ball
;;BALL = The ball whose event is to be returned
(define-macro (ball-event-queue ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 3)))
;;BALL-COLLISION-TIME returns the time of the last collision for the given ball
;;BALL = The ball whose collision time is to be returned
(define-macro (ball-collision-time ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 4)))
!
;;SET-BALL-COLLISION-TIME! sets the time of the last collision for the given
;;ball
;;BALL = The ball whose collision time is to be set
;;VALUE = The value to which the ball's collision time is to be set
(define-macro (set-ball-collision-time! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 4) ,value))
;;BALL-COLLISION-X-POSITION returns the x-coordinate of the position of the
;;last collision for the given ball
;;BALL = The ball whose collision position is to be returned
(define-macro (ball-collision-x-position ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 5)))
;;SET-BALL-COLLISION-X-POSITION! sets the x-coordinate of the position of the
;;last collision for the given ball
;;BALL = The ball whose collision position is to be set
;;VALUE = The value to which the ball's collision position is to be set
(define-macro (set-ball-collision-x-position! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 5) ,value))
;;BALL-COLLISION-Y-POSITION returns the y-coordinate of the position of the
;;last collision for the given ball
;;BALL = The ball whose collision position is to be returned
(define-macro (ball-collision-y-position ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 6)))
;;SET-BALL-COLLISION-Y-POSITION! sets the y-coordinate of the position of the
;;last collision for the given ball
;;BALL = The ball whose collision position is to be set
;;VALUE = The value to which the ball's collision position is to be set
(define-macro (set-ball-collision-y-position! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 6) ,value))
;;BALL-X-VELOCITY returns the x-coordinate of the velocity of the given ball
;;following its last collision
;;BALL = The ball whose velocity is to be returned
(define-macro (ball-x-velocity ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 7)))
;;SET-BALL-X-VELOCITY! sets the x-coordinate of the velocity of the given ball
;;BALL = The ball whose velocity is to be set
;;VALUE = The value to which the ball's velocity is to be set
(define-macro (set-ball-x-velocity! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 7) ,value))
;;BALL-Y-VELOCITY returns the y-coordinate of the velocity of the given ball
;;following its last collision
;;BALL = The ball whose velocity is to be returned
(define-macro (ball-y-velocity ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 8)))
;;SET-BALL-Y-VELOCITY! sets the y-coordinate of the velocity of the given ball
;;BALL = The ball whose velocity is to be set
;;VALUE = The value to which the ball's velocity is to be set
(define-macro (set-ball-y-velocity! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 8) ,value))
!
;;BALL-BALL-VECTOR returns the vector of queue records for balls with smaller
;;ball numbers
;;BALL = The ball whose ball vector is to be returned
(define-macro (ball-ball-vector ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 9)))
;;SET-BALL-BALL-VECTOR! sets the vector of queue records for balls with smaller
;;ball numbers
;;BALL = The ball whose ball vector is to be set
;;VALUE = The vector to which the field is to be set
(define-macro (set-ball-ball-vector! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 9) ,value))
;;BALL-BUMPER-VECTOR returns the vector of queue records for bumpers
;;BALL = The ball whose bumper vector is to be returned
(define-macro (ball-bumper-vector ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 10)))
;;SET-BALL-BUMPER-VECTOR! sets the vector of queue records for bumpers
;;BALL = The ball whose bumper vector is to be set
;;VALUE = The vector to which the field is to be set
(define-macro (set-ball-bumper-vector! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 10) ,value))
;;BALL-BALL-LIST returns a list of balls with larger ball numbers than the
;;given ball
;;BALL = The ball whose ball list is to be returned
(define-macro (ball-ball-list ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 11)))
;;SET-BALL-BALL-LIST! sets the list of balls with larger ball numbers than the
;;given ball
;;BALL = The ball whose ball list is to be set
;;VALUE = The value to which the ball list is to be set
(define-macro (set-ball-ball-list! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 11) ,value))
;;BALL-GLOBAL-EVENT-QUEUE-RECORD returns the global event queue record for the
;;given ball
;;BALL = The ball whose global event queue record is to be returned
(define-macro (ball-global-event-queue-record ball)
`(vector-ref ,ball ,(+ (simulation-object-len) 12)))
;;SET-BALL-GLOBAL-EVENT-QUEUE-RECORD! set the global event queue record for the
;;given ball to the given value
;;BALL = The ball whose global event queue record is to be set
;;VALUE = The value to which the global event queue record field is to be set
(define-macro (set-ball-global-event-queue-record! ball value)
`(vector-set! ,ball ,(+ (simulation-object-len) 12) ,value))
!
;;ACTUAL-MAKE-BUMPER returns a bumper object
;;BUMPER-NUMBER = An index into the bumper vector for this bumper
;;X1 = The x-coordiante of one end of the bumper
;;Y1 = The y-coordiante of one end of the bumper
;;X2 = The x-coordiante of the other end of the bumper
;;Y2 = The y-coordiante of the other end of the bumper
(define-macro (actual-make-bumper bumper-number x1 y1 x2 y2)
`(make-simulation-object
bumper-collision-procedure ;The collision procedure for a bumper
,bumper-number
,x1 ;The bumper endpoints
,y1
,x2
,y2))
(define (make-bumper x1 y1 x2 y2)
(actual-make-bumper '() x1 y1 x2 y2))
;;BUMPER-NUMBER returns the index of the given bumper
;;BUMPER = The bumper whose index is to be returned
(define-macro (bumper-number bumper)
`(vector-ref ,bumper ,(simulation-object-len)))
;;SET-BUMPER-NUMBER! set the index of the given bumper to the given value
;;BUMPER = The bumper whose index is to be set
;;VALUE = The value to which it is to be set
(define-macro (set-bumper-number! bumper value)
`(vector-set! ,bumper ,(simulation-object-len) ,value))
;;BUMPER-X1 returns the x-coordinate of one end of the given bumber
;;BUMPER = the bumper whose x-coordinate is to be returned
(define-macro (bumper-x1 bumper)
`(vector-ref ,bumper ,(1+ (simulation-object-len))))
;;SET-BUMPER-X1! sets the x-coordinate of one end of the given bumber
;;BUMPER = the bumper whose x-coordinate is to be set
;;VALUE = The value to which the bumpers x-coordinate is to be set
(define-macro (set-bumper-x1! bumper value)
`(vector-set! ,bumper ,(1+ (simulation-object-len)) ,value))
;;BUMPER-Y1 returns the y-coordinate of one end of the given bumber
;;BUMPER = the bumper whose y-coordinate is to be returned
(define-macro (bumper-y1 bumper)
`(vector-ref ,bumper ,(+ (simulation-object-len) 2)))
;;SET-BUMPER-Y1! sets the y-coordinate of one end of the given bumber
;;BUMPER = the bumper whose y-coordinate is to be set
;;VALUE = The value to which the bumpers y-coordinate is to be set
(define-macro (set-bumper-y1! bumper value)
`(vector-set! ,bumper ,(+ (simulation-object-len) 2) ,value))
;;BUMPER-X2 returns the x-coordinate of the other end of the given bumber
;;BUMPER = the bumper whose x-coordinate is to be returned
(define-macro (bumper-x2 bumper)
`(vector-ref ,bumper ,(+ (simulation-object-len) 3)))
;;SET-BUMPER-X2! sets the x-coordinate of the other end of the given bumber
;;BUMPER = the bumper whose x-coordinate is to be set
;;VALUE = The value to which the bumpers x-coordinate is to be set
(define-macro (set-bumper-x2! bumper value)
`(vector-set! ,bumper ,(+ (simulation-object-len) 3) ,value))
!
;;BUMPER-Y2 returns the y-coordinate of the other end of the given bumber
;;BUMPER = the bumper whose y-coordinate is to be returned
(define-macro (bumper-y2 bumper)
`(vector-ref ,bumper ,(+ (simulation-object-len) 4)))
;;SET-BUMPER-Y2! sets the y-coordinate of the other end of the given bumber
;;BUMPER = the bumper whose y-coordinate is to be set
;;VALUE = The value to which the bumpers y-coordinate is to be set
(define-macro (set-bumper-y2! bumper value)
`(vector-set! ,bumper ,(+ (simulation-object-len) 4) ,value))
;;COLLISION-TIME-<? is a predicate which returns true if the first event queueu
;;record represents a collision that will take place at an earlier time than
;;the one for the second event queue record
;;EVENT-QUEUE-RECORD1 = The first event queue record
;;EVENT-QUEUE-RECORD2 = The second event queue record
(define (collision-time-<? event-queue-record1 event-queue-record2)
(time-<?
(event-queue-record-collision-time
event-queue-record1)
(event-queue-record-collision-time
event-queue-record2)))
;;TIME-<? is a predicate which returns true if the first time is smaller than
;;the second. '() represents a time infinitly large.
(define (time-<? time1 time2)
(if (null? time1)
#f
(if (null? time2)
#t
(< time1 time2))))
;;SQUARE returns the square of its argument
(define-macro (square x)
`(expt ,x 2))
!
;;BALL-BALL-COLLISION-TIME returns the time at which the two given balls would
;;collide if neither interacted with any other objects, '() if never. This
;;calculation is performed by setting the distance between the balls to the sum
;;of their radi and solving for the contact time.
;;BALL1 = The first ball
;;BALL2 = The second ball
(define (ball-ball-collision-time ball1 ball2)
(let ((delta-x-velocity ;Cache the difference in the ball's
( - (ball-x-velocity ball2) ;velocities,
(ball-x-velocity ball1)))
(delta-y-velocity
( - (ball-y-velocity ball2)
(ball-y-velocity ball1)))
(radius-sum ;the sum of their radi,
(+ (ball-radius ball1)
(ball-radius ball2)))
(alpha-x ;and common subexpressions in the time
(- ;equation
(- (ball-collision-x-position
ball2)
(ball-collision-x-position
ball1))
(-
(* (ball-x-velocity ball2)
(ball-collision-time
ball2))
(* (ball-x-velocity ball1)
(ball-collision-time
ball1)))))
(alpha-y
(-
(- (ball-collision-y-position
ball2)
(ball-collision-y-position
ball1))
(-
(* (ball-y-velocity ball2)
(ball-collision-time
ball2))
(* (ball-y-velocity ball1)
(ball-collision-time
ball1))))))
(let* ((delta-velocity-magnitude-squared
(+ (square
delta-x-velocity)
(square
delta-y-velocity)))
(discriminant
(- (* (square radius-sum)
delta-velocity-magnitude-squared)
(square
(- (* delta-y-velocity
alpha-x)
(* delta-x-velocity
alpha-y))))))
!
(if (or (negative? discriminant) ;If the balls don't colloide:
(zero?
delta-velocity-magnitude-squared))
'() ;Return infinity
(let ((time ;Else, calculate the collision time
(/
(- 0
(+ (sqrt discriminant)
(+
(* delta-x-velocity
alpha-x)
(* delta-y-velocity
alpha-y))))
(+ (square
delta-x-velocity)
(square
delta-y-velocity)))))
(if (and ;If the balls collide in the future:
(time-<?
(ball-collision-time
ball1)
time)
(time-<?
(ball-collision-time
ball2)
time))
time ;Return the collision time
'())))))) ;Else, return that they never collide
!
;;BALL-BUMPER-COLLISION-TIME returns the time at which the given ball would
;;collide with the given bumper if the ball didn't interacted with any other
;;objects, '() if never. This is done by first calculating the time at which
;;the ball would collide with a bumper of infinite length and then checking if
;;the collision position represents a portion of the actual bumper.
;;BALL = The ball
;;BUMPER = The bumper
(define (ball-bumper-collision-time ball bumper)
(let ((delta-x-bumper ;Collision time with the bumper of
(- (bumper-x2 bumper) ;infinite extent is calculated by
(bumper-x1 bumper))) ;setting the distance between the ball
(delta-y-bumper ;and the bumper to be the radius of the
(- (bumper-y2 bumper) ;ball and solving for the time. The
(bumper-y1 bumper)))) ;distance is calculated by |aXb|/|a|,
(let ((bumper-length-squared ;where 'a' is the vector from one end
(+ (square delta-x-bumper) ;of the bumper to the other and 'b' is
(square delta-y-bumper))) ;the vector from the first end of the
(denominator ;bumper to the center of the ball
(- (* (ball-y-velocity ball)
delta-x-bumper)
(* (ball-x-velocity ball)
delta-y-bumper))))
(if (zero? denominator) ;If the ball's motion is parallel to
;the bumper:
'() ;Return infinity
(let ((delta-t ;Calculate the collision time
(-
(/
(+
(*
(- (ball-collision-x-position
ball)
(bumper-x1 bumper))
delta-y-bumper)
(*
(- (ball-collision-y-position
ball)
(bumper-y1 bumper))
delta-x-bumper))
denominator)
(/
(* (ball-radius
ball)
(sqrt
bumper-length-squared))
(abs denominator)))))
(if (not (positive? ;If the ball is moving away from the
delta-t)) ;bumper:
'() ;Return infinity
!
(let ((ball-x-contact ;Whether the ball contacts the actual
(+ (ball-collision-x-position ;bumper of limited extent
ball) ;will be determined by comparing |b.a|
(* (ball-x-velocity ;with |a|↑2
ball)
delta-t)))
(ball-y-contact
(+ (ball-collision-y-position
ball)
(* (ball-y-velocity
ball)
delta-t))))
(let ((delta-x-ball
(- ball-x-contact
(bumper-x1
bumper)))
(delta-y-ball
(- ball-y-contact
(bumper-y1
bumper))))
(let ((dot-product
(+
(* delta-x-ball
delta-x-bumper)
(* delta-y-ball
delta-y-bumper))))
(if (or ;If the ball misses the bumper on
(negative? ;either end:
dot-product)
(> dot-product
bumper-length-squared))
'() ;Return infinity
(+ delta-t ;Else, return the contact time
(ball-collision-time
ball))))))))))))
!
;;BALL-COLLISION-PROCEDURE calculates the new velocities of the given balls
;;based on their collision at the given time. Also, tells all other balls
;;about the new trajectories of these balls so they can update their event
;;queues
;;BALL1 = The first ball
;;BALL2 = The second ball
;;COLLISION-TIME = The collision time
;;GLOBAL-EVENT-QUEUE = The global queue of earliest events for each ball
(define (ball-collision-procedure ball1 ball2 collision-time
global-event-queue)
(queue-remove ;Remove the earliest event associated
(ball-global-event-queue-record ;with each ball from the global event
ball1)) ;queue
(queue-remove
(ball-global-event-queue-record
ball2))
(let ((ball1-collision-x-position ;Calculate the positions of both balls
(+ (ball-collision-x-position ;when they collide
ball1)
(* (ball-x-velocity
ball1)
(- collision-time
(ball-collision-time
ball1)))))
(ball1-collision-y-position
(+ (ball-collision-y-position
ball1)
(* (ball-y-velocity
ball1)
(- collision-time
(ball-collision-time
ball1)))))
(ball2-collision-x-position
(+ (ball-collision-x-position
ball2)
(* (ball-x-velocity
ball2)
(- collision-time
(ball-collision-time
ball2)))))
(ball2-collision-y-position
(+ (ball-collision-y-position
ball2)
(* (ball-y-velocity
ball2)
(- collision-time
(ball-collision-time
ball2))))))
(let ((delta-x ;Calculate the displacements of the
(- ball2-collision-x-position ;centers of the two balls
ball1-collision-x-position))
(delta-y
(- ball2-collision-y-position
ball1-collision-y-position)))
!
(let* ((denominator ;Calculate the angle of the line
(sqrt (+ (square ;joining the centers at the collision
delta-x) ;time with the x-axis (this line is
(square ;the normal to the balls at the
delta-y)))) ;collision point)
(cos-theta
(/ delta-x denominator))
(sin-theta
(/ delta-y denominator)))
(let ((ball1-old-normal-velocity ;Convert the velocities of the balls
(+ (* (ball-x-velocity ;into the coordinate system defined by
ball1) ;the normal and tangential lines at
cos-theta) ;the collision point
(* (ball-y-velocity
ball1)
sin-theta)))
(ball1-tang-velocity
(- (* (ball-y-velocity
ball1)
cos-theta)
(* (ball-x-velocity
ball1)
sin-theta)))
(ball2-old-normal-velocity
(+ (* (ball-x-velocity
ball2)
cos-theta)
(* (ball-y-velocity
ball2)
sin-theta)))
(ball2-tang-velocity
(- (* (ball-y-velocity
ball2)
cos-theta)
(* (ball-x-velocity
ball2)
sin-theta)))
(mass1 (ball-mass
ball1))
(mass2 (ball-mass
ball2)))
(let ((ball1-new-normal-velocity ;Calculate the new velocities
(/ ;following the collision (the
(+ ;tangential velocities are unchanged
(* ;because the balls are assumed to be
(* 2 ;frictionless)
mass2)
ball2-old-normal-velocity)
(*
(- mass1 mass2)
ball1-old-normal-velocity))
(+ mass1 mass2)))
!
(ball2-new-normal-velocity
(/
(+
(*
(* 2
mass1)
ball1-old-normal-velocity)
(*
(- mass2 mass1)
ball2-old-normal-velocity))
(+ mass1 mass2))))
(set-ball-x-velocity! ;Store data about the collision in the
ball1 ;structure for each ball after
(- (* ball1-new-normal-velocity ;converting the information back
cos-theta) ;to the x,y frame
(* ball1-tang-velocity
sin-theta)))
(set-ball-y-velocity!
ball1
(+ (* ball1-new-normal-velocity
sin-theta)
(* ball1-tang-velocity
cos-theta)))
(set-ball-x-velocity!
ball2
(- (* ball2-new-normal-velocity
cos-theta)
(* ball2-tang-velocity
sin-theta)))
(set-ball-y-velocity!
ball2
(+ (* ball2-new-normal-velocity
sin-theta)
(* ball2-tang-velocity
cos-theta)))
(set-ball-collision-time!
ball1
collision-time)
(set-ball-collision-time!
ball2
collision-time)
(set-ball-collision-x-position!
ball1
ball1-collision-x-position)
(set-ball-collision-y-position!
ball1
ball1-collision-y-position)
(set-ball-collision-x-position!
ball2
ball2-collision-x-position)
(set-ball-collision-y-position!
ball2
ball2-collision-y-position))))))
!
(newline)
(display "Ball ")
(display (ball-number ball1))
(display " collides with ball ")
(display (ball-number ball2))
(display " at time ")
(display (ball-collision-time ball1))
(newline)
(display " Ball ")
(display (ball-number ball1))
(display " has a new velocity of ")
(display (ball-x-velocity ball1))
(display ",")
(display (ball-y-velocity ball1))
(display " starting at ")
(display (ball-collision-x-position ball1))
(display ",")
(display (ball-collision-y-position ball1))
(newline)
(display " Ball ")
(display (ball-number ball2))
(display " has a new velocity of ")
(display (ball-x-velocity ball2))
(display ",")
(display (ball-y-velocity ball2))
(display " starting at ")
(display (ball-collision-x-position ball2))
(display ",")
(display (ball-collision-y-position ball2))
(recalculate-collisions ball1 global-event-queue)
(recalculate-collisions ball2 global-event-queue))
!
;;BUMPER-COLLISION-PROCEDURE calculates the new velocity of the given ball
;;following its collision with the given bumper at the given time. Also, tells
;;other balls about the new trajectory of the given ball so they can update
;;their event queues.
;;BALL = The ball
;;BUMPER = The bumper
;;COLLISION-TIME = The collision time
;;GLOBAL-EVENT-QUEUE = The global queue of earliest events for each ball
(define (bumper-collision-procedure ball bumper collision-time
global-event-queue)
(queue-remove ;Remove the earliest event associated
(ball-global-event-queue-record ;with the ball from the global event
ball)) ;queue
(let ((delta-x-bumper ;Compute the bumper's delta-x
(- (bumper-x2 bumper)
(bumper-x1 bumper)))
(delta-y-bumper ;delta-y
(- (bumper-y2 bumper)
(bumper-y1 bumper))))
(let ((bumper-length ;length
(sqrt
(+ (square
delta-x-bumper)
(square
delta-y-bumper)))))
(let ((cos-theta ;and cosine and sine of its angle with
(/ delta-x-bumper ;respect to the positive x-axis
bumper-length))
(sin-theta
(/ delta-y-bumper
bumper-length))
(x-velocity ;Cache the ball's velocity in the x,y
(ball-x-velocity ball)) ;frame
(y-velocity
(ball-y-velocity ball)))
(let ((tang-velocity ;Calculate the ball's velocity in the
(+ (* x-velocity ;bumper frame
cos-theta)
(* y-velocity
sin-theta)))
(normal-velocity
(- (* y-velocity
cos-theta)
(* x-velocity
sin-theta))))
!
(set-ball-collision-x-position! ;Store the collision position
ball
(+ (ball-collision-x-position
ball)
(* (- collision-time
(ball-collision-time
ball))
(ball-x-velocity
ball))))
(set-ball-collision-y-position!
ball
(+ (ball-collision-y-position
ball)
(* (- collision-time
(ball-collision-time
ball))
(ball-y-velocity
ball))))
(set-ball-x-velocity! ;Calculate the new velocity in the
ball ;x,y frame based on the fact that
(+ (* tang-velocity ;tangential velocity is unchanged and
cos-theta) ;the normal velocity is inverted when
(* normal-velocity ;the ball collides with the bumper
sin-theta)))
(set-ball-y-velocity!
ball
(- (* tang-velocity
sin-theta)
(* normal-velocity
cos-theta)))
(set-ball-collision-time!
ball
collision-time)))))
(newline)
(display "Ball ")
(display (ball-number ball))
(display " collides with bumper ")
(display (bumper-number bumper))
(display " at time ")
(display (ball-collision-time ball))
(newline)
(display " Ball ")
(display (ball-number ball))
(display " has a new velocity of ")
(display (ball-x-velocity ball))
(display ",")
(display (ball-y-velocity ball))
(display " starting at ")
(display (ball-collision-x-position ball))
(display ",")
(display (ball-collision-y-position ball))
(recalculate-collisions ball global-event-queue))
!
;;RECALCULATE-COLLISIONS removes all old collisions for the given ball from
;;all other balls' event queues and calcultes new collisions for these balls
;;and places them on the event queues. Also, updates the global event queue if
;;the recalculation of the collision effects the earliest collision for any
;;other balls.
;;BALL = The ball whose collisions are being recalculated
;;GLOBAL-EVENT-QUEUE = The global queue of earliest events for each ball
(define (recalculate-collisions ball global-event-queue)
(clear-queue (ball-event-queue ;Clear the queue of events for this
ball)) ;ball as they have all changed
(let ((event-queue ;Calculate all ball collision events
(ball-event-queue ball))) ;with balls of lower number
(let ((ball-vector
(ball-ball-vector ball)))
(do ((i (-1+ (ball-number ball))
(-1+ i)))
((negative? i))
(let ((ball2-queue-record
(vector-ref
ball-vector
i)))
(set-event-queue-record-collision-time!
ball2-queue-record
(ball-ball-collision-time
ball
(event-queue-record-object
ball2-queue-record)))
(queue-insert
event-queue
ball2-queue-record))))
(let ((bumper-vector ;Calculate all bumper collision events
(ball-bumper-vector ball)))
(do ((i (-1+ (vector-length
bumper-vector))
(-1+ i)))
((negative? i))
(let ((bumper-queue-record
(vector-ref
bumper-vector
i)))
(set-event-queue-record-collision-time!
bumper-queue-record
(ball-bumper-collision-time
ball
(event-queue-record-object
bumper-queue-record)))
(queue-insert
event-queue
bumper-queue-record))))
!
(let ((global-queue-record ;Get the global event queue record
(ball-global-event-queue-record ;for this ball
ball)))
(set-event-queue-record-collision-time! ;Set the new earliest event time
global-queue-record ;for this ball
(if (empty-queue? event-queue)
'()
(event-queue-record-collision-time
(queue-smallest event-queue))))
(queue-insert ;Enqueue on the global event queue
global-event-queue ;the earliest event between this ball
global-queue-record))) ;and any ball of lower number or any
;bumper
(for-each ;For each ball on the ball list:
(lambda (ball2)
(let ((ball2-event-queue
(ball-event-queue ball2)))
(let ((alter-global-event-queue? ;Set flag to update global event queue
(and ;if the earliest event for ball2 was
(not (empty-queue? ;with the deflected ball
ball2-event-queue))
(eq? ball
(event-queue-record-object
(queue-smallest
ball2-event-queue)))))
(ball-event-queue-record ;Get the queue record for the deflected
(vector-ref ;ball for this ball
(ball-ball-vector
ball2)
(ball-number ball))))
(queue-remove ;Remove the queue record for the
ball-event-queue-record) ;deflected ball
(set-event-queue-record-collision-time! ;Recalculate the collision
ball-event-queue-record ;time for this ball and the deflected
(ball-ball-collision-time ;ball
ball
ball2))
(queue-insert ;Enqueue the new collision event
ball2-event-queue
ball-event-queue-record)
(if (or alter-global-event-queue? ;If the earliest collision event for
(eq? ball ;this ball has changed:
(event-queue-record-object
(queue-smallest
ball2-event-queue))))
(let ((queue-record ;Remove the old event from the global
(ball-global-event-queue-record ;event queue and replace it
ball2))) ;with the new event
(set-event-queue-record-collision-time!
queue-record
(event-queue-record-collision-time
(queue-smallest
ball2-event-queue)))
(queue-remove
queue-record)
(queue-insert
global-event-queue
queue-record))))))
(ball-ball-list ball)))
!
;;SIMULATE performs the billiard ball simulation for the given ball list and
;;bumper list until the specified time.
;;BALL-LIST = A list of balls
;;BUMPER-LIST = A list of bumpers
;;END-TIME = The time at which the simulation is to terminate
(define (simulate ball-list bumper-list end-time)
(let ((num-of-balls ;Cache the number of balls and bumpers
(length ball-list))
(num-of-bumpers
(length bumper-list))
(global-event-queue ;Build the global event queue
(make-sorted-queue
collision-time-<?)))
(let ((complete-ball-vector ;Build a vector for the balls
(make-vector
num-of-balls)))
(let loop ((ball-num 0) ;For each ball:
(ball-list ball-list))
(if (not (null? ball-list))
(let ((ball (car ball-list)))
(set-ball-number! ;Store the ball's number
ball
ball-num)
(vector-set! ;Place it in the ball vector
complete-ball-vector
ball-num
ball)
(set-ball-ball-list! ;Save the list of balls with ball
ball ;numbers greater than the current ball
(cdr ball-list))
(display-ball-state
ball)
(loop
(1+ ball-num)
(cdr ball-list)))))
(let loop ((bumper-num 0) ;For each bumper:
(bumper-list
bumper-list))
(if (not (null? bumper-list))
(sequence
(set-bumper-number! ;Store the bumper's number
(car bumper-list)
bumper-num)
(display-bumper-state
(car bumper-list))
(loop
(1+ bumper-num)
(cdr bumper-list)))))
!
(do ((ball-num 0 (1+ ball-num))) ;For each ball:
((= ball-num num-of-balls))
(let* ((ball (vector-ref ;Cache a reference to the ball
complete-ball-vector
ball-num))
(ball-vector ;Build a vector for the queue records
(make-vector ;of balls with smaller numbers than
ball-num)) ;this ball
(bumper-vector ;Build a vector for the queue records
(make-vector ;of bumpers
num-of-bumpers))
(event-queue ;Build an event queue for this ball
(ball-event-queue
ball)))
(set-ball-ball-vector! ;Install the vector of ball queue
ball ;records
ball-vector)
(do ((i 0 (1+ i))) ;For each ball of smaller number than
((= i ball-num)) ;the current ball:
(let* ((ball2 ;Cache the ball
(vector-ref
complete-ball-vector
i))
(queue-record ;Create a queue record for this ball
(make-event-queue-record ;based on the collision time
'() ;of the two balls
'()
ball2
(ball-ball-collision-time
ball
ball2))))
(vector-set! ;Install the queue record in the ball
ball-vector ;vector for this ball
i
queue-record)
(queue-insert ;Insert the queue record into the event
event-queue ;queue for this ball
queue-record)))
!
(set-ball-bumper-vector! ;Install the vector of bumper queue
ball ;records
bumper-vector)
(let loop ((bumper-num 0)
(bumper-list
bumper-list))
(if (not (null? bumper-list))
(let* ((bumper ;Cache the bumper
(car
bumper-list))
(queue-record ;Create a queue record for this bumper
(make-event-queue-record ;based on the collision time
'() ;of the current ball and this bumper
'()
bumper
(ball-bumper-collision-time
ball
bumper))))
(vector-set! ;Install the queue record in the bumper
bumper-vector ;vector for this ball
bumper-num
queue-record)
(queue-insert ;Insert the queue record into the event
event-queue ;queue for this ball
queue-record)
(loop
(1+ bumper-num)
(cdr bumper-list)))))
(let ((queue-record ;Build a global event queue record for
(make-event-queue-record ;the earliest event on this ball's
'() ;event queue
'()
ball
(if (empty-queue?
event-queue)
'()
(event-queue-record-collision-time
(queue-smallest
event-queue))))))
(set-ball-global-event-queue-record! ;Store this queue record in
ball ;the frame for this ball
queue-record)
(queue-insert ;Insert this queue record in the global
global-event-queue ;event queue
queue-record)))))
(actually-simulate ;Now that all of the data structures
global-event-queue ;have been built, actually start the
end-time))) ;simulation
!
;;DISPLAY-BALL-STATE displays the ball number, mass, radius, position, and
;;velocity of the given ball
;;BALL = The ball whose state is to be displayed
(define (display-ball-state ball)
(newline)
(display "Ball ")
(display (ball-number ball))
(display " has mass ")
(display (ball-mass ball))
(display " and radius ")
(display (ball-radius ball))
(newline)
(display " Its position at time ")
(display (ball-collision-time ball))
(display " was ")
(display (ball-collision-x-position ball))
(display ",")
(display (ball-collision-y-position ball))
(display " and its velocity is ")
(display (ball-x-velocity ball))
(display ",")
(display (ball-y-velocity ball)))
;;DISPLAY-BUMPER-STATE displays the bumper number and position of the given
;;bumper
;;BUMPER = The bumper whose state is to be displayed
(define (display-bumper-state bumper)
(newline)
(display "Bumper ")
(display (bumper-number bumper))
(display " extends from ")
(display (bumper-x1 bumper))
(display ",")
(display (bumper-y1 bumper))
(display " to ")
(display (bumper-x2 bumper))
(display ",")
(display (bumper-y2 bumper)))
!
;;ACTUALLY-SIMULATE performs the actual billiard ball simulation
;;GLOBAL-EVENT-QUEUE = The global queue of earliest events for each ball.
;; Contains a single event for each ball which is the
;; earliest collision it would have with a ball of a
;; smaller number or a bumper, if no other collisions took
;; place first.
;;END-TIME = The time at which the simulation should be terminated
(define (actually-simulate global-event-queue end-time)
(letrec ((loop
(lambda ()
(let* ((record ;Get the globally earliest event and
(queue-smallest ;its time
global-event-queue))
(collision-time
(event-queue-record-collision-time
record)))
(if (not ;If this event happens before the
(time-<? ;simulation termination time:
end-time
collision-time))
(let* ((ball ;Get the ball involved in the event,
(event-queue-record-object
record))
(ball-queue ;the queue of events for that ball,
(ball-event-queue
ball))
(other-object ;and the first object with which the
(event-queue-record-object ;ball interacts
(queue-smallest
ball-queue))))
((simulation-object-collision-procedure ;Process this
other-object) ;globally earliest collision
ball
other-object
collision-time
global-event-queue)
(loop))))))) ;Process the next interaction
(loop)))
------------------------------
Date: 21 Mar 89 11:45:05 PST (Tuesday)
Subject: Wanted: Comparison of OakLisp and CLOS object systems
From: "Ron_Fischer.mvenvos"@Xerox.COM
Message-ID: <890321-114523-9186@Xerox>
Could some kind person who has seriously used OakLisp expound on its
similarities and differences to CLOS?
Secondary query: could the current implementation of OakLisp be run w/o
virtual memory?
(ron)
------------------------------
End of Scheme Digest
********************
∂22-Mar-89 0450 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Weird numeric predicates?
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 04:50:06 PST
Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 22 Mar 89 07:42:49 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA05578; Wed, 22 Mar 89 04:43:35 PDT
Date: Wed, 22 Mar 89 04:43:35 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903221243.AA05578@kestrel.arpa>
To: Alan@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Alan Bawden's message of Tue, 21 Mar 89 23:31 EST <19890322043132.5.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Weird numeric predicates?
Date: Tue, 21 Mar 89 23:31 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Now, if you would like to argue with the given that the arithmetic
primitives accept mixed exact and inexact arguments, we can do that. You
might even find that you can convince me. But I don't want anyone to lose
track of what I originally said because someone stigmatized it by using the
word "DWIM" in its presence. I was not proposing anything that could be
described as DWIM, and in fact I was not proposing anything at all. I was
pointing out the consequences of two different implementations of the
arithmetic comparison predicates. Consequences, I might add, that most
implementors seem to be unaware of.
My sincere apologies for the unclear prose. Indeed, I should have
said I wasn't responding to your point directly but, as you say,
arguing with a given, one which had simply been brought to my
attention by your comments. My only defense is that, while this idea
has been forming in my head for a while, this is the first time I've
attempted to express it.
However, the given I was arguing with is not exactly "that the
arithmetic primitives accept mixed exact and inexact arguments". It
is that the arithmetic primitives are mode-generic: the mode in which
the operation is performed (exact or inexact) is dependent on the
exactness or inexactness of the arguments. This is the characteristic
that I am attempting to stigmatize with the word "DWIM".
I am suggesting, as an alternative, that the primitives be bifurcated
into exact and inexact versions and that the mode in which the
operation is performed be dependent only on which primitive is
involved. I am *not* suggesting that the primitives not accept mixed
exact and inexact arguments.
Thus, an exact primitive would coerce all arguments to be exact before
performing the operation, even if *all* of said arguments were
supplied in inexact form; conversely for inexact primitives.
Apologies again. Is this making sense yet?
Scott
∂22-Mar-89 0946 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:46:25 PST
Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 22 Mar 89 12:35:59 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA13463; Wed, 22 Mar 89 09:33:57 PST
Date: Wed, 22 Mar 89 09:33:57 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903221733.AA13463@sesame.Stanford.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: jinx@zurich.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu,
scheme-standard%kleph.ai.mit.edu@relay.cs.net
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 21 Mar 89 18:05:49 PST (Tue) <8903220205.AA22716@mrloog.LA.TEK.COM>
Subject: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Date: 21 Mar 89 18:05:49 PST (Tue)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
JINX,
Some general comments on your general comments:
--------
Some general comments on your proposal:
2) I think it's premature to standardize on something like this for
IEEE. Proposals along these lines should certainly be considered for
R5RS.
On the contrary, we need to standardize library issues as soon as
possible to keep divergence from preventing portability. The IEEE
standard is a good place for this. I really would rather see only
*language* issues in RnRS. Most languages standardize too late--after
implementations have significantly diverged--and there is hell to pay as
each implementor tries to get *his* dialect as *the* standard (e.g.
ATLAS). Currently, we have a portable language, but not portable code.
I believe that there is sufficient practical experience to have a
standard interface to common functionality and that the IEEE standard
needs such an interface to be viable.
It seems that the situation that many of us feared is already coming to pass.
I see here a justification for why standardization should drive language design
rather than visa versa. Let us remember that as difficult as it is to
standardize after peoples paths have diverged, it is even more difficult to
unstandardize a mistake. I would oppose standardization of any feature that
has not been experimented with in its proposed form for standardization by the
Scheme community for at least 6 months. DON'T RISK STANDARDIZATION OF
POTENTIAL BUGS.
Comments on individual issues:
4) RESET and FATAL-ERROR: I would propose a different, more powerful,
procedure instead, on top of which both of these could easily be
built.
(ABORT-TO-NEAREST-REPL <thunk>)
fetches a continuation created by the nearest repl (nearest in systems where
there is more than one, like MIT Scheme, the top level one if there is
only one) and executes <thunk> with this continuation.
Thus
(define (reset)
(abort-to-nearest-repl (lambda () unspecific)))
(define (fatal-error message . irritants)
(abort-to-nearest-repl
(lambda ()
(for-each (lambda (unused-arg)
(display #\space)
(display obj))
(apply format #t message irritants))
(newline))))
How is the "nearest repl" known to the runtime system? How does a
Scheme system recognize that a function is a (possibly user written)
repl? I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?
I have strong objections against having a procedure named FATAL-ERROR
(or anything else with ERROR in it's name) which does not allow the
option of fixing the bug and proceeding.
Perhaps I'm confused. You don't want a FATAL ERROR to abort a
computation? This might be a valuable behavior in a (possibly
parallel) multi-tasking search situation. What would be the
difference between FATAL-ERROR and ERROR ? The thing that I am trying
to clean up here is the confusion over CERROR vs ERROR as to when an
error is fatal and when recoverable. `ERROR' is pretty common and
typing RECOVERABLE-ERROR gets a bit tedious.
I'm not too attached to the name ABORT-TO-NEAREST-REPL. The similar
MIT Scheme procedure is called ABORT->NEAREST.
I don't see this as a common usage in other Scheme implementations.
Anyone?
When someone is proposing new functionality, common usage should be irrelevant.
We should be trying to find the correct way of doing things, not the most
common way. Common usage is a good argument as to why it is premature to
standardize this feature, not as to why a given functionality is more or less
desirable than another. Lets here some substantive technical arguments for or
against different approaches.
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
A different question is making your compiler generate reasonable code,
but this should not be difficult.
If you want to use it for special forms instead (like comment), I'd
rather wait until we have some way of creating syntactic extensions.
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
Unless someone in Indiana moves fast, we will not have syntactic
extensions in R4RS. When we get syntactic extensions, these are easy
to `define'. I strongly suspect that the number of Scheme
implementations is going to double every year or two for a while. We
need to be heading off the problems that will exist in 5 years unless
fixed now.
I feel VERY strongly that new syntactic forms of this sort should not be added
to Scheme. Again, standardization seems to be driving language design, rather
than visa versa. Lets put our effort into standardizing syntactic extensions
rather than into kludging around them.
9) UNLESS and WHEN: I would wait for syntactic extensions. I
generally object to adding spurious special forms.
We don't have syntactic extensions. I see these in a lot of code. I
believe they are common usage. Who else out there objects to these?
Who else uses them?
I HATE the idea of adding unless and when to Scheme. We already have enough
cruft in the form of do. I use Scheme rather than CommonLisp because of its
elegance and simplicity. The way we are going, I fear that pretty soon the two
will be indistinguishable.
----------
Thank you very much for your input.
-The Reader
Morry Katz
katz@polya.stanford.edu
∂22-Mar-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #90
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 21:36:15 PST
Date: 23 MAR 89 00:00:15 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #90
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #90 23 MAR 89 00:00:15 EST
Today's Topics:
Common Requests
----------------------------------------------------------------------
Date: Wed, 22 Mar 89 23:57:34 EST
From: "Christopher M. Maeda" <MAEDA@AI.AI.MIT.EDU>
Subject: Common Requests
Message-ID: <561870.890322.MAEDA@AI.AI.MIT.EDU>
Perhaps we should write a mail demon that periodically
posts answers to the most commonly asked questions such as...
What are the differences between lisp and scheme?
Where can I find the Gabriel benchmarks?
Where do I find the xscheme sources?
Then no one will have to ask anymore.
------------------------------
End of Scheme Digest
********************
∂22-Mar-89 2245 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 22:45:08 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 23 Mar 89 01:26:39 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae14075; 23 Mar 89 1:14 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa16647; 23 Mar 89 1:10 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA15248; Wed, 22 Mar 89 21:51:00 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA23251; Wed, 22 Mar 89 21:53:26 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA01844; Wed, 22 Mar 89 21:50:23 pst
Message-Id: <8903230550.AA01844@mrloog.LA.TEK.COM>
To: Morris Katz <mkatz%sesame.stanford.edu@RELAY.CS.NET>
Cc: rrrs-authors@MC.LCS.MIT.EDU,
scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET, kend@mrloog.la
Subject: Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
In-Reply-To: Your message of Wed, 22 Mar 89 09:33:57 PST.
<8903221733.AA13463@sesame.Stanford.EDU>
Date: 22 Mar 89 21:50:21 PST (Wed)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
Rather than indent to the limit, I am breaking things up a bit...
JINX (Guillermo Rozas):---------------------------------------------V
2) I think it's premature to standardize on something like this for
IEEE. Proposals along these lines should certainly be considered for
R5RS.
Ken Dickey:---------------------------------------------------------V
On the contrary, we need to standardize library issues as soon as
possible to keep divergence from preventing portability. The IEEE
standard is a good place for this. I really would rather see only
*language* issues in RnRS. Most languages standardize too late--after
implementations have significantly diverged--and there is hell to pay as
each implementor tries to get *his* dialect as *the* standard (e.g.
ATLAS). Currently, we have a portable language, but not portable code.
I believe that there is sufficient practical experience to have a
standard interface to common functionality and that the IEEE standard
needs such an interface to be viable.
Morry Katz:---------------------------------------------------------V
It seems that the situation that many of us feared is already coming to pass.
I see here a justification for why standardization should drive language design
rather than visa versa. Let us remember that as difficult as it is to
standardize after peoples paths have diverged, it is even more difficult to
unstandardize a mistake. I would oppose standardization of any feature that
has not been experimented with in its proposed form for standardization by the
Scheme community for at least 6 months. DON'T RISK STANDARDIZATION OF
POTENTIAL BUGS.
Ken Dickey:---(New)--------------------------------------------------V
I guess I need to be more clear. I distinguish between a language and a
library. I am not proposing any changes to the Scheme language. I am
proposing *optional* library interfaces to either (1) enable code
portability between implementations or (2) codify common usages. In
class (1) I am interested in obtaining the functionality in the best
possible way. In class (2) I don't want any new features or
functionality, but I do want an interface--when implemented--to have the
same parameters and semantics. {*If* someone implements UNLESS, I want
(UNLESS <test> <exp>...), not some randomness. UNLESS has been used for
years--I didn't make it up}.
The interfaces (functions or special forms in this context) I consider
class (2) are:
pretty-print
reset
unless
when
random
sort
sort!
suspend
autoload
define-structure
I have rarely seen an implementation without them.
Other interfaces are included to cure specific problems: to obtain basic
implementation information, format output, do basic error handling,
tracing and environmental inspection, specialization (alias,
define-if-<mumble>, comment-when), benchmarking (date & time functions),
and binary-i/o (including buffers). With the exception of the
define-if-<mumble> and comment-when (and I would really like to see
alternate proposals for these), any differences in interface from what
most implementations have had for years is purely cosmetic--there is
nothing fundamentially new here.
There are many people like myself who are in a commercial environment and
wish to use Scheme. Unless Scheme can be shown to be a portable language
which tackles commercial problems we are condemned to use C++ or some
other abomination. It is my belief that if the above issues are not
addressed in the IEEE Scheme Standard, usage of the language will be
crippled. Standardizing interfaces to functionality which has existed
for some time in many implementations in a non-binding appendix seems to
me the most conservative way of doing so. Conditional compilation
/interpretation in some form seems to be the major piece of work, but I
see it as crucial to the success of the Scheme language (I am not giving
up my evenings doing this just to get flamed).
{I am sensitive to your concerns, but I don't think that for the readers
of this group conditional specialization is such a large problem that it
can't be addressed. Given the time frame of the standards process, we
may have 6 months of implementation experience by the time the standard
is published}.
****************************************
Morry Katz:----------------------------------------------------------
When someone is proposing new functionality ...
Ken Dickey:-(new)---------------------------------------------------
I recant. ABORT->NEAREST, MAKE-<direction>-PORT and friends belong as
proposals to RnRS.
***************************************
I suggest we seperate:
[A] Arguments to keep or scrap the library proposal as a whole.
and [B] Cleanup, clarifications, or alternate interface proposals for
specific functionality.
Thanks for the input,
-Ken kend@mrloog.LA.TEK.COM
∂23-Mar-89 0934 @MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:34:00 PST
Received: from sesame.Stanford.EDU (TCP 4405400251) by MC.LCS.MIT.EDU 23 Mar 89 12:23:14 EST
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA14594; Thu, 23 Mar 89 09:20:39 PST
Date: Thu, 23 Mar 89 09:20:39 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8903231720.AA14594@sesame.Stanford.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard%kleph.ai.mit.edu@relay.cs.net,
kend@mrloog.la
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 22 Mar 89 21:50:21 PST (Wed) <8903230550.AA01844@mrloog.LA.TEK.COM>
Subject: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Date: 22 Mar 89 21:50:21 PST (Wed)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
Ken Dickey:---(New)--------------------------------------------------V
(text ommitted)
There are many people like myself who are in a commercial environment and
wish to use Scheme. Unless Scheme can be shown to be a portable language
which tackles commercial problems we are condemned to use C++ or some
other abomination. It is my belief that if the above issues are not
addressed in the IEEE Scheme Standard, usage of the language will be
crippled. Standardizing interfaces to functionality which has existed
for some time in many implementations in a non-binding appendix seems to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
me the most conservative way of doing so. Conditional compilation
/interpretation in some form seems to be the major piece of work, but I
see it as crucial to the success of the Scheme language (I am not giving
up my evenings doing this just to get flamed).
-Ken kend@mrloog.LA.TEK.COM
There is no such thing as a non-binding appendix as far as I am concerned.
A non-binding appendix is a little like saying stdio isn't part of C.
Kernighan and Ritchie make this distinction in "The C Programming Language",
but from a practical standpoint it is moot. What are those in favor going to
say if in 6 months a group of us want to change the definitions in the
non-binding appendix in order to make what we believe are improvements? If you
can honestly say that I will not here any objections on the grounds that we
have already published a different version, then I guess the appendix really is
non-binding; however, I seriously doubt this. I suspect that it is time for
those of us who are interested in programming language development, as opposed
to product support, to go off and work on another language and let you codify
Scheme.
Morry Katz
katz@polya.stanford.edu
∂23-Mar-89 1709 @MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:ziggy@VX.LCS.MIT.EDU Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 16:06:04 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Mar 89 18:51:58 EST
Received: from VX.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 23 MAR 89 18:49:10 EST
Received: by VX.LCS.MIT.EDU with sendmail-4.12/4.8 id <AA01876@VX.LCS.MIT.EDU>; Thu, 23 Mar 89 18:50:31 est
Date: Thu, 23 Mar 89 18:50:31 est
From: Michael R. Blair <ziggy@VX.LCS.MIT.EDU>
To: kend%mrloog.la.tek.com@relay.cs.net, mkatz@sesame.stanford.edu
Subject: Re: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Cc: kend@mrloog.la, rrrs-authors@mc.lcs.mit.edu,
scheme-standard%kleph.ai.mit.edu@relay.cs.net
If you are worried about non-binding appendices being interpreted as binding, then
you could always prefix the non-binding forms with (say) NB-<mumble>. One could
also state (in small print) that some implementations may provide equivalent
forms that omit the NB prefix but this is NOT portable.
Future iterations could increment this prefix... say since the first standard is
tied to Revised↑4 Scheme, maybe use NB4-<mumble>.
If the appendix always says NB4-<mumble> and NEVER says just <mumble> anywhere
then nobody can grumble if you later redefine <mumble>.
That's my two cents. ~Ziggy
∂23-Mar-89 1715 @MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com Re: Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 16:53:21 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 23 Mar 89 19:47:30 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa27517; 23 Mar 89 19:14 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa28069; 23 Mar 89 19:04 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA08245; Thu, 23 Mar 89 15:47:01 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA12973; Thu, 23 Mar 89 15:49:24 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA09084; Thu, 23 Mar 89 15:47:23 pst
Message-Id: <8903232347.AA09084@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU,
scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET,
kend%mrloog.la.tek.com@RELAY.CS.NET
Subject: Re: Portability (long)
In-Reply-To: Your message of Tue, 21 Mar 89 22:47:37 -0500.
<8903220347.AA09548@chamartin.AI.MIT.EDU>
Date: 23 Mar 89 15:47:20 PST (Thu)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
(ABORT-TO-NEAREST-REPL <thunk>)
...
How is the "nearest repl" known to the runtime system? How does a
Scheme system recognize that a function is a (possibly user written)
repl? I don't have a problem with implementing RESET or FATAL-ERROR
this way, but why standardize this function as a library routine?
The idea is that the runtime system provides facilities for building
repls which interact with these abort procedures (there are many in
MIT Scheme), and can provide additional functionality. While this
procedure is useful for writing things like RESET, it is useful in its
own right: interrupt characters cause invocations of such procedures
in MIT Scheme. Dan Friedman needs something like
ABORT-TO-NEAREST-REPL for some of the stuff he does as well.
My recollection is that Dan wants a global variable bound to the
continuation caught at the top level. Most implementations have a RESET
function now. Describing RESET library interface describes what is
typically there now. Adding ABORT-TO-NEAREST-REPL to the library
interface (given the things that are missing) is, I feel, premature.
ABORT-TO-NEAREST-REPL is a proposal for RnRS.
**********************************************************
Currently there are error functions defined with 2 different behaviors.
One acts like
(define (ERROR msg . args) (format #t message args) (reset)).
The other acts like
(define (ERROR msg . args) (format #t message args) (debug)).
Different Scheme implementrations supply one form or both forms and both
forms are called ERROR by some implementations. I called the first one
FATAL-ERROR and the second one ERROR. Perhaps I should have just used
the MacScheme convention (ERROR and CERROR). I would like a consistent
naming convention across implementations which distinguishes behavior.
Please propose one (How about NOISY-RESET and ERROR?).
**************************************************************
5) ERROR must be a special form in order to get the environment of
the "call". In MIT Scheme, the ERROR special form expands into
something like
(ERROR-PROCEDURE (the-environment) <message> . <irritants>)
ERROR works just fine as a procedure in many systems (Chez Scheme, T,
and MacScheme). The fact that MIT Scheme has a non-standard way to
access the environment makes it convenient for ERROR to be a special
form in MIT Scheme. I would really prefer that you propose an
standard environment mechanism if you want to insist that ERROR must
be a special form (or better yet, a standard error handling
mechanism). I really prefer procedures to special forms.
I'm very confused. As far as I know, all correct scheme
implementations must be properly tail recursive, and this is what forces
error to be a special form. For example, in ...
ERROR *is* a procedure in Chez Scheme, T, and MacScheme. Yes, tail
recursion loses in the cases you mention. I understand the
implementation considerations. I will not propose that those who
implement ERROR as a function be forced to change that implementation to
be a special form. You are free to convince them.
************************************************************************
Yes, TRACE was underspecified. TRACE and UNTRACE should take values.
(I said that).
************************************************************************
7) ALIAS: Why can't you just use (define <alias> <original>) ?
This is hard to do with special forms.
...
The reason for these bits of syntax is that we need to solve the
portability problems now and we do not yet have syntactic extensions.
...
Although I agree with the gist of your argument, I don't see how this
applies to ALIAS. Either you have a special form in the first place
which you are providing an alias for, or you do not. If you have it,
you can use the original. If you don't, ALIAS won't solve your
problem: In order for ALIAS to be of any help in portability, you need
conditional compilation or conditional loading according to
implementation. Whatever you use to discriminate according to
implementation, you can use to provide definitions of the "missing"
special forms using each implementation's syntactic extension
facilities. As far as I know, all implementations have ways of
providing syntactic extensions.
ALIAS is useful in porting code and exists in current implementations
(PCScheme, Scheme-84). Yes, all implementation have ways of providing
syntactic extensions. The problem is that few of them are the same
(macro, define-macro, define-syntax, extend-syntax, ...). I can't write
ALIAS portably.
*************************************************************************
13) READ-BYTE and WRITE-BYTE: The 0..255 range seems random.
So you want 3..258? I think that silent masking of overflow would be
pretty random.
I meant that 8 bit bytes are pretty arbitrary. It would be nice to be
able to read in (for example) 16 bit quantities, 32 bit quantities,
etc. Furthermore, although rare, there are still machines around that
are not based on 8 bit bytes, and they may become popular again in the
future. I would hate to see current hardware praxis getting into
the language.
Yes, it would be nice to stay out of port and register sizes. It makes
writing system code somewhat difficult, however. Are you proposing a
parameterized routine? e.g. (WRITE-BINARY <exact-integer> . <num-bits>)?
I think that this special case of binary-i/o is helpful. The general
case is hard to specify well.
**********************************************************************
...
BOUND? may be a primitive procedure which accesses the environment of the
call via agreement between the compiler and runtime system. Isn't
requiring it to be a special form overspecification? I think that we
could really make do with BOUND-AT-TOP-LEVEL? or some such. I think
it best to flush DEFINE-IF-<mumble>, but testing for existance of a
definition without generating a runtime error is a necessity.
**********************************************************************
Unless there are strong objections I will flush DEFINE-IF-<mumble>.
************
I have only heard from 3 people and would appreciate more opinions and
comments.
Thanks,
-Ken kend@mrloog.LA.TEK.COM
∂23-Mar-89 1737 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 17:37:33 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 23 Mar 89 20:27:39 EST
Received: from Salvador.ms by ArpaGateway.ms ; 23 MAR 89 17:25:19 PST
Date: Thu, 23 Mar 89 17:25:09 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Portability (long)
In-reply-to: <8903232347.AA09084@mrloog.LA.TEK.COM>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard@kleph.ai.mit.edu
Message-ID: <890323-172519-6244@Xerox>
Ken says, ``I have only heard from 3 people and would appreciate more
opinions and comments.''
You asked for it.
This whole exercise seems entirely misguided to me. I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own. Ziggy's idea of putting a
prefix on each name seems beside the point; if I'm going to use these
``portable'' constructs, then I'm going to hardwire these names into my
code and resist changes to their semantics. I don't see what changing the
names will do, unless you intend that every implementation retain every
version of every facility, so that each implementation would have to carry
along NB4-UNLESS, NB5-UNLESS, etc. in perpetuity. That's clearly
unacceptable.
I have also not seen any response to, I think, Jinx's point about using
extra ``compile'' and ``load'' files that test which implementation is in
use and coordinate things appropriately. Of course, one need not actually
use files for such things; humans are reasonably good at picking out the
one ``system-dependent'' file of code for their implementation and using
that along with the bulk of the software system. If, indeed, as you state,
most implementations have facilities similar to what you've described (in
some cases, I doubt this very much), then such ``system-dependent'' files
will be terribly easy to write.
Any publication of a standard interface to certain facilities tends to
reduce experimentation among implementations. Such constraints should only
be imposed on facilities with which we collectively have significant
experience and on which we have reached consensus about what is The Right
Thing.
I think that detailed discussion of your many proposals is premature until
you or others have more adequately justified the point of the whole
endeavor.
Pavel
∂23-Mar-89 1841 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 18:41:43 PST
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Mar 89 21:17:31 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA13201@chamartin.AI.MIT.EDU>; Thu, 23 Mar 89 21:18:46 -0500
Date: Thu, 23 Mar 89 21:18:46 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903240218.AA13201@chamartin.AI.MIT.EDU>
To: kend%mrloog.la.tek.com@RELAY.CS.NET
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET,
kend%mrloog.la.tek.com@RELAY.CS.NET
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 23 Mar 89 15:47:20 PST (Thu) <8903232347.AA09084@mrloog.LA.TEK.COM>
Subject: Portability (long)
Reply-To: jinx@zurich.ai.mit.edu
My recollection is that Dan wants a global variable bound to the
continuation caught at the top level.
That is pretty much what ABORT-TO-NEAREST-REPL is, except that instead
of having the REPL do
(call-with-current-continuation
(lambda (here)
(fluid-let ((RESET here))
<code of repl>)))
it is done with (note extra parens)
((call-with-current-continuation
(lambda (here)
(fluid-let ((ABORT-TO-NEAREST-REPL here))
(let ((val <code of repl>))
(lambda () val))))))
so that the thunk will be executed when "fed" to ABORT-TO-NEAREST-REPL.
Maybe the name is confusing, so let's propose a compromise:
RESET is a procedure of 0 or 1 arguments. When invoked with no
arguments, it does what you want. When invoked with 1 argument, it
"resets" to the read eval print loop, and within this context, it
invokes its argument, which is what ABORT-TO-NEAREST-REPL does.
Most implementations have a RESET
function now. Describing RESET library interface describes what is
typically there now. Adding ABORT-TO-NEAREST-REPL to the library
interface (given the things that are missing) is, I feel, premature.
ABORT-TO-NEAREST-REPL is a proposal for RnRS.
Having ABORT-TO-NEAREST-REPL (under whatever name) makes zero-argument
RESET unnecessary, and I find zero-argument RESET distasteful.
****************************************
Currently there are error functions defined with 2 different behaviors.
One acts like
(define (ERROR msg . args) (format #t message args) (reset)).
The other acts like
(define (ERROR msg . args) (format #t message args) (debug)).
The ERROR special form in MIT Scheme does neither. In the absence of
any condition handlers, it opens up a NEW read eval print loop in the
environment of the error. The debugger can be invoked from there, or
a procedure can be invoked to abort to the previous read eval print
loop. In spirit it is more like the second, but does not really fit.
Different Scheme implementrations supply one form or both forms and both
forms are called ERROR by some implementations. I called the first one
FATAL-ERROR and the second one ERROR. Perhaps I should have just used
the MacScheme convention (ERROR and CERROR). I would like a consistent
naming convention across implementations which distinguishes behavior.
Please propose one (How about NOISY-RESET and ERROR?).
I understand this. I don't object to the name FATAL-ERROR only, I
object to the concept. I don't believe there are such beasts as
non-recoverable errors. I think ERROR should imply recovery, and I
will object to standardizing on anything else. Although the
"functionality" of your FATAL-ERROR can be built on top of RESET, or
ABORT-TO-NEAREST-REPL, I don't think that users should be encouraged
to write programs that randomly abort rather than let the user examine
their state and proceed the computation after fixing whatever is
wrong.
****************************************
ALIAS is useful in porting code and exists in current implementations
(PCScheme, Scheme-84). Yes, all implementation have ways of providing
syntactic extensions. The problem is that few of them are the same
(macro, define-macro, define-syntax, extend-syntax, ...). I can't write
ALIAS portably.
I still find your argument circular. Please give me an example where
ALIAS solves anything by itself, ie. without any conditionalization.
****************************************
Yes, it would be nice to stay out of port and register sizes. It makes
writing system code somewhat difficult, however. Are you proposing a
parameterized routine? e.g. (WRITE-BINARY <exact-integer> . <num-bits>)?
I think that this special case of binary-i/o is helpful. The general
case is hard to specify well.
I'd much rather go for WRITE-BINARY than for WRITE-BYTE.
****************************************
BOUND? may be a primitive procedure which accesses the environment of the
call via agreement between the compiler and runtime system. Isn't
requiring it to be a special form overspecification?
Therefore you would have
(let ((foo 3))
(bound? 'foo))
return #T
but
(define (check name)
(bound? name))
and separately compiled
(let ((foo 3))
(check? 'foo))
return #F? I don't believe you are really proposing this. This
violates all forms of referential transparency that I can think of.
I think that we
could really make do with BOUND-AT-TOP-LEVEL? or some such.
Assuming we can all get to agree on what "top-level" means.
I think
it best to flush DEFINE-IF-<mumble>, but testing for existance of a
definition without generating a runtime error is a necessity.
I don't disagree for the need for BOUND?. I just object to a
procedural definition which does not make sense.
∂23-Mar-89 2118 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #91
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 89 21:18:33 PST
Date: 24 MAR 89 00:00:40 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #91
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #91 24 MAR 89 00:00:40 EST
Today's Topics:
Scheme and C
please add me to this mailing list
----------------------------------------------------------------------
Date: 23 Mar 89 19:52:29 GMT
From: mailrus!uflorida!haven!uvaarpa!hudson!smf7s@ohio-state.arpa (friedman steven michael)
Subject: Scheme and C
Message-Id: <1267@hudson.acc.virginia.edu>
I am running PC-Scheme on an AT compatible. I am using it
to design an expert system, but I would like to write the user
interface in C, since it will be graphics intensive. Does anybody
have any experience with this? (BTW I have Microsoft C) Thanks
in advance for any help.
Steven M Friedman
Mail path: smf7s@virginia.BITNET
Voice path: (804) 295 0235 -- Home
(804) 924 7625 -- Office
------------------------------
Subject: please add me to this mailing list
Message-Id: <8903231147.AA14996@spt.entity.com>
Date: 23 Mar 89 11:47:45 EST (Thu)
From: alms@spt.entity.com (andrew lm shalit)
the subject says it all.
thanks.
-andrew
------------------------------
End of Scheme Digest
********************
∂24-Mar-89 0348 @MC.LCS.MIT.EDU:gyro@kestrel.arpa Standardization of libraries
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 89 03:47:57 PST
Received: from kestrel.arpa (TCP 1200600040) by MC.LCS.MIT.EDU 24 Mar 89 06:37:16 EST
Received: by kestrel.arpa (5.58/SMI-DDN)
id AA18718; Fri, 24 Mar 89 03:37:33 PDT
Date: Fri, 24 Mar 89 03:37:33 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Message-Id: <8903241137.AA18718@kestrel.arpa>
To: Pavel.pa@Xerox.COM
Cc: rrrs-authors@MC.LCS.MIT.EDU, scheme-standard@kleph.ai.mit.edu
In-Reply-To: Msg of Thu, 23 Mar 89 17:25:09 PST from Pavel.pa@Xerox.COM
Subject: Standardization of libraries
Date: Thu, 23 Mar 89 17:25:09 PST
From: Pavel.pa@Xerox.COM
This whole exercise seems entirely misguided to me. I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own.
I don't think the exercise is *entirely* misguided. Unless we take
the attitude that we literally don't care whether we have a user
community or not, we are going to have to pay some attention to the
needs of that community. The question is what kind, and how much, and
at what cost to our goal of facilitating exuberant experimentation
among implementors.
The problem, of course, is that there is a natural antagonism between
encouraging ferment and the needs of users for stability. I daresay
the general sentiment is that we consider ferment much more important
than do, say, the Common Lisp designers. (I don't think this goes
without saying -- I could make a case for the point of view that if we
want Scheme to be really widely used, we should go into "product
support" mode as quickly as possible -- but for the moment I will take
it as a given that our priority is ferment.)
So then the question becomes, is there any way we can have ferment and
still give our users what they need? I think there might be, though
it will take some effort to do, and that it will look roughly like
this:
-- In the Scheme standard (this applies equally to the RnRS
leading-edge standard and the IEEE "trickle-down" standard) we
make absolutely every attempt to specify the minimum language in
which all else can be written. In short, we want the standard to
specify a basis set of programming constructs, and nothing else.
-- This means that *anything* that can be written in terms of the
standard constructs must not be part of the standard. This
includes the kinds of things we have been discussing: top level
loops, error reporters, etc.
-- To make it possible to write portable programs that make use of
such facilities, we resort not to the static approach represented
by a document, but rather to a dynamic approach: an official
module registration facility.
The idea of the module registration facility is that anyone who thinks
they have a module (subsystem, collection of functions, whatever you
want to call it) that would be of general interest can register it,
that is, make it publicly available under a unique name. The module
could be something completely new, or it could be only a variation
(preferably not a totally trivial variation) on some other registered
module. Once a module is published, the only allowed changes to it
are bug fixes, compatible performance improvements, and upwardly
compatible extensions.
Users, then, need only list the modules to be used by any given
program. Once the program is written, the user never need update it
to use more recently released modules, although that is always an
option. Implementors need not concern themselves with modules at all,
except insofar as we may decide to add a construct or two to the core
language to support their use.
Note that when I say "a module registration facility" I don't mean a
facility in the linguistic sense, like Common Lisp's PROVIDE /
REQUIRE; I mean an office with a budget and a staff, you know, humans.
Well, with luck it would only take a fractional human. The tasks
would be 1) to assign the unique module names; 2) to maintain a
library containing the source code for each registered module; and 3)
to fill orders for copies of said source code.
It's an institutional rather than linguistic solution, but then I
think the problem is more a social one than a technical one to start
with.
Comments?
Scott
∂24-Mar-89 0721 @MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 89 07:21:05 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 24 Mar 89 10:04:19 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab07340; 24 Mar 89 9:46 EST
Received: from cs.brandeis.edu by RELAY.CS.NET id ad05919; 24 Mar 89 9:25 EST
Received: by cs.brandeis.edu (14.2/6.0.GT)
id AA11239; Fri, 24 Mar 89 08:29:35 est
Date: Fri, 24 Mar 89 08:29:35 est
From: Jim Miller <jmiller%cs.brandeis.edu@RELAY.CS.NET>
Posted-Date: Fri, 24 Mar 89 08:29:35 est
To: kend%mrloog.la.tek.com.2@cs.brandeis.edu
Cc: rrrs-authors%mc.lcs.mit.edu.2@cs.brandeis.edu,
scheme-standard%kleph.ai.mit.edu.2@cs.brandeis.edu
In-Reply-To: kend%mrloog.la.tek.com@RELAY.CS.NET's message of 17 Mar 89 17:07:16 PST (Fri) <8903180107.AA03798@mrloog.LA.TEK.COM>
Subject: "Its the little things that count. Hundreds of 'em." -- Cliff Shaw
Reply-To: JMiller%cs.Brandeis.edu@RELAY.CS.NET
Despite my vow never (well, hardly ever) to send mail these lists,
I'll take a whack at Ken's portability proposal. My concerns:
(a) The IEEE draft standard should NOT include things that belong in
the yellow pages. We need to get that set of public, portable programs
started. That's Ken's much-needed large library. Come on gang, it's
been over two years since Bill Rozas was appointed librarian, and I
haven't heard of a single contribution. GET WITH IT.
(b) Neither document should attempt to constrain or describe the
interactive environment. The standard should be for a programming
language, not its environment.
(c) The IEEE standard should not include special forms that are
trivially implemented on top of an extend-syntax type of macro
facility and the proposed standard language. Macros are within sight
now (they will be in R4RS or R4+epsilonRS) and can be adopted
wholesale into the IEEE standard after they have been implemented and
studied thoroughly.
So:
(1) I believe FORMAT, RANDOM, SORT, and SORT! can and should be
implemented as yellow pages procedures. Perhaps MIT will contribute
the latter three (I think their versions are portable).
(2) I endorse the proposal (Bill Rozas?) of standardizing port
constructors, but in R5RS, not IEEE. In the interim, let's have a YP
format for use in IEEE Scheme that generates strings.
(3) I agree with Bill that user's shouldn't be aided in using (RESET)
from within a program; it is part of the user interface for dealing
with the system.
(4) I also agree with Bill that errors should be able to be
intercepted at runtime. This is the whole area of exception handling,
and I don't believe that we're likely to get much agreement in this
area quickly. There are, however, cogent arguments that the
environment in which the error occurs must be available for error
handling, and this dictates special forms rather than procedures
(unless someone seriously proposes putting in first-class
environments). Thus, I believe that ERROR and FATAL-ERROR should be
reserved words, with the understanding that implementations will often
provide either a special form or a procedure of the "signature"
suggested by Ken. >> I SUGGEST THAT BOTH IEEE AND R5RS RESERVE THESE
NAMES. <<
(5) The following are all environment issues and shouldn't be
addressed in the standard: INSPECT, TRACE, UNTRACE, SUSPEND, AUTOLOAD.
(6) I don't like ALIAS, but I'll just claim that it ought to be a
macro built with the soon-to-be syntactic closure mechanism.
(7) COMMENT is a fine idea, but it's a trivial macro. So are UNLESS,
WHEN, and COMMENT-WHEN.
(8) I hate to say it, but don't forget about time zones and the
international date line. If you want to do date and times at all,
let's add the "right" primitive and have YP to do the rest.
(9) I don't even want to think about what I'd like RUNTIME to mean in
MultiScheme. If you propose a microsecond real clock for the base of
the date and time stuff, would that suffice?
(10) I'm not ready to byte off (sorry) your binary stuff. I don't see
any reason to recommend byte vectors to all implementations, and I
certainly don't believe in conversion between strings and byte
vectors.
(11) I think you've already seen arguments about BOUND? and the
DEFINE-IF- stuff that are powerful enough to suggest we aren't ready
for standards here.
(12) Structures are great. But (a) can we do them with macros, and
(b) can we come up with a more complete specification? I think the
R5RS should deal with this one.
--Jim Miller
∂24-Mar-89 1409 @MC.LCS.MIT.EDU,@polya.Stanford.EDU:mkatz@sesame Standardization of libraries
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 89 14:09:05 PST
Received: from polya.Stanford.EDU (TCP 4402000240) by MC.LCS.MIT.EDU 24 Mar 89 16:57:26 EST
Received: from Sesame.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA16188; Fri, 24 Mar 89 11:39:28 -0800
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
id AA16254; Fri, 24 Mar 89 11:39:36 PST
Date: Fri, 24 Mar 89 11:39:36 PST
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8903241939.AA16254@sesame.Stanford.EDU>
To: gyro@kestrel.arpa
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu,
scheme-standard@kleph.ai.mit.edu
In-Reply-To: Scott B. Layson's message of Fri, 24 Mar 89 03:37:33 PDT <8903241137.AA18718@kestrel.arpa>
Subject: Standardization of libraries
Date: Fri, 24 Mar 89 03:37:33 PDT
From: gyro@kestrel.arpa (Scott B. Layson)
Date: Thu, 23 Mar 89 17:25:09 PST
From: Pavel.pa@Xerox.COM
This whole exercise seems entirely misguided to me. I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own.
I don't think the exercise is *entirely* misguided. Unless we take
the attitude that we literally don't care whether we have a user
community or not, we are going to have to pay some attention to the
needs of that community. The question is what kind, and how much, and
at what cost to our goal of facilitating exuberant experimentation
among implementors.
The problem, of course, is that there is a natural antagonism between
encouraging ferment and the needs of users for stability. I daresay
the general sentiment is that we consider ferment much more important
than do, say, the Common Lisp designers. (I don't think this goes
without saying -- I could make a case for the point of view that if we
want Scheme to be really widely used, we should go into "product
support" mode as quickly as possible -- but for the moment I will take
it as a given that our priority is ferment.)
So then the question becomes, is there any way we can have ferment and
still give our users what they need? I think there might be, though
it will take some effort to do, and that it will look roughly like
this:
-- In the Scheme standard (this applies equally to the RnRS
leading-edge standard and the IEEE "trickle-down" standard) we
make absolutely every attempt to specify the minimum language in
which all else can be written. In short, we want the standard to
specify a basis set of programming constructs, and nothing else.
-- This means that *anything* that can be written in terms of the
standard constructs must not be part of the standard. This
includes the kinds of things we have been discussing: top level
loops, error reporters, etc.
-- To make it possible to write portable programs that make use of
such facilities, we resort not to the static approach represented
by a document, but rather to a dynamic approach: an official
module registration facility.
The idea of the module registration facility is that anyone who thinks
they have a module (subsystem, collection of functions, whatever you
want to call it) that would be of general interest can register it,
that is, make it publicly available under a unique name. The module
could be something completely new, or it could be only a variation
(preferably not a totally trivial variation) on some other registered
module. Once a module is published, the only allowed changes to it
are bug fixes, compatible performance improvements, and upwardly
compatible extensions.
Users, then, need only list the modules to be used by any given
program. Once the program is written, the user never need update it
to use more recently released modules, although that is always an
option. Implementors need not concern themselves with modules at all,
except insofar as we may decide to add a construct or two to the core
language to support their use.
Note that when I say "a module registration facility" I don't mean a
facility in the linguistic sense, like Common Lisp's PROVIDE /
REQUIRE; I mean an office with a budget and a staff, you know, humans.
Well, with luck it would only take a fractional human. The tasks
would be 1) to assign the unique module names; 2) to maintain a
library containing the source code for each registered module; and 3)
to fill orders for copies of said source code.
It's an institutional rather than linguistic solution, but then I
think the problem is more a social one than a technical one to start
with.
Comments?
Scott
At Snowbird we already essentially created such a facility. We called it a
library. Jinx agreed to be the librarian for the first 6 months (I believe).
Users were encouraged to contribute modules to the library (with a preference
for those which could be run under many different versions of Scheme). All
information in the library was to be available by anonymous ftp and possibly by
UUCP. It seems to me that the reason that the library has not taken off is
that we still lack a standard mechanism for creating syntactic extensions.
This makes creating code which is executable on many different implementations
of Scheme very difficult. It should be that any module should be able to be
composed of a series of segments (files) with only one of them being
implementation dependent. Lets get syntactic extensions standardized, and the
rest will come along naturally.
Morry Katz
katz@polya.stanford.edu
∂24-Mar-89 2123 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #92
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Mar 89 21:23:40 PST
Date: 25 MAR 89 00:03:43 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #92
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #92 25 MAR 89 00:03:43 EST
Today's Topics:
Scheme input buffer
Scheme implementation techniques?
----------------------------------------------------------------------
Date: 22 Mar 89 19:21:57 GMT
From: hefley@rand-unix.arpa (Charlene Hefley)
Subject: Scheme input buffer
Message-Id: <1915@randvax.UUCP>
I'm running TI Scheme on an IBM compatible (Compaq 286). Does
anyone know of a way to increase the input buffer size so that I
can type ahead more than 15 characters?
Thanks a bunch,
Charlene Hefley
inet: rand-unix.arpa
uucp: ...!randvax!hefley
------------------------------
Date: 23 Mar 89 23:58:26 GMT
From: mcvax!kth!draken!liuida!mikpe@uunet.uu.net (Mikael Pettersson)
Subject: Scheme implementation techniques?
Message-Id: <1229@mina.liu.se>
What are the approaches that have been used to implement interactive
Scheme systems? I am more-or-less familiar with the following ones:
1) interpreting unprocessed S-expressions (parse trees)
(using "meta-circular" or flat coded interpreters)
2) interpreting processed S-expressions (syntax trees)
(this is what my current interpreter does)
3) bytecode compilation and interpretation
4) compiling to native machine code
(is it worth while to always use compilation rather than
having an interpreter with a compile option?)
Are there any other approaches worth considering?
--
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ..!{mcvax,munnari,uunet}!enea!liuida!mpe
------------------------------
End of Scheme Digest
********************
∂25-Mar-89 0550 @MC.LCS.MIT.EDU:jh@tut.fi Standardization of libraries
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 89 05:50:51 PST
Received: from etana.funet.fi (TCP 20065400401) by MC.LCS.MIT.EDU 25 Mar 89 08:45:28 EST
Received: by etana.funet.fi; id AA27648; Wed, 25 Jan 89 15:36:40 +0200
Received: by korppi.tut.fi (4.0/10.6.master) id AA11003; Sat, 25 Mar 89 15:45:07 +0200
Message-Id: <8903251345.AA11003@korppi.tut.fi>
Date: Sat, 25 Mar 89 15:45:07 +0200
From: jh@tut.fi (Juha Hein{nen)
To: mkatz@sesame.stanford.edu
Cc: gyro@kestrel.ARPA, Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu,
scheme-standard@kleph.ai.mit.edu
In-Reply-To: Morris Katz's message of Fri, 24 Mar 89 11:39:36 PST <8903241939.AA16254@sesame.Stanford.EDU>
Subject: Standardization of libraries
dependent. Lets get syntactic extensions standardized, and the
rest will come along naturally.
I fully agree with this. Few interesting modules can be written
without a syntactic extension mechanism. Until Scheme has one, it
can't become a real programming language with good module library and
large commercial user community.
-- Juha Heinanen
∂25-Mar-89 2128 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #93
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 89 21:28:30 PST
Date: 26 MAR 89 00:04:13 EST
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #93
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #93 26 MAR 89 00:04:13 EST
Today's Topics:
SPEED OF TI's PC-SCHEME, EXPANDED AND EXTENDED MEMORY VERSIONS
Scheme implementation techniques?
----------------------------------------------------------------------
Date: 24 Mar 89 14:41:13 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: SPEED OF TI's PC-SCHEME, EXPANDED AND EXTENDED MEMORY VERSIONS
Message-Id: <1917@randvax.UUCP>
Has anyone done timing runs of both the expanded and extended memory
versions of TI's PC-Scheme? Is one version faster than the other?
Also, are there any programming tricks you can use to speed up the
large-memory versions? Using PC-Scheme 3.03, I'm suffering an almost
tripling of run times when I use the extended memory version...
(Sure is nice having the big heap space, though!)
Tnx in advance. -B
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Date: 25 Mar 89 22:16:59 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!oz@husc6.harvard.edu (Ozan Yigit)
Subject: Re: Scheme implementation techniques?
Message-Id: <1394@yunexus.UUCP>
In article <1229@mina.liu.se> mikpe@mina.liu.se (Mikael Pettersson) writes:
>
>What are the approaches that have been used to implement interactive
>Scheme systems? I am more-or-less familiar with the following ones:
... usual implementation techniques ...
>
>Are there any other approaches worth considering?
>
There is one other way I know of, having gone thru most of the
material included in my bibliography. This method may be called (in
a very loose way) the "threaded code" technique, or enclosing
everything into a lambda closure. The technique is discussed in
detail in the following paper:
%A Marc Feeley
%A Guy LaPalme
%T Using Cloures for Code Generation
%J Journal of Computer Languages
%V 12
%N 1
%P 47-66
%I Pergamon Press
%D 1987
Or, in a lot greater detail, including 68000 code generation, in the
following thesis:
%A Marc Feeley
%T Deux Approches a' L'implantation du Language Scheme
%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
Ope'rationelle, University of Montreal
%D May 1986
Here is the "optimizing compiler" from the first paper. It worked
for the example in the paper, so I think I typed it right.
;
; Optimizing scheme compiler
; supports quote, set!, if, lambda special forms,
; constant refs, variable refs and proc applications
;
; Using Clusures for Code Generation
; Marc Feeley and Guy LaPalme
; Computer Language, Vol. 12, No. 1, pp. 47-66
; 1987
;
(define (compile expr)
((gen expr nil #f)))
(define (gen expr env term)
(cond
((symbol? expr)
(ref (variable expr env) term))
((not (pair? expr))
(cst expr term))
((eq? (car expr) 'quote)
(cst (cadr expr) term))
((eq? (car expr) 'set!)
(set (variable (cadr expr) env) (gen (caddr expr) env #f) term))
((eq? (car expr) 'if)
(gen-tst (gen (cadr expr) env #f)
(gen (caddr expr) env term)
(gen (cadddr expr) env term)))
((eq? (car expr) 'lambda)
(let ((p (cadr expr)))
(prc p (gen (caddr expr) (allocate p env) #t) term)))
(else
(let ((args (map (lambda (x) (gen x env #f)) (cdr expr))))
(let ((var (and (symbol? (car expr)) (variable (car expr) env))))
(if (global? var)
(app (cons var args) #t term)
(app (cons (gen (car expr) env #f) args) #f term)))))))
(define (allocate parms env)
(cond ((null? parms) env)
((symbol? parms) (cons parms env))
(else
(cons (car parms) (allocate (cdr parms) env)))))
(define (variable symb env)
(let ((x (memq symb env)))
(if x
(- (length env) (length x))
(begin
(if (not (assq symb -glo-env-)) (define-global symb '-undefined-))
(assq symb -glo-env-)))))
(define (global? var)
(pair? var))
(define (cst val term)
(cond ((eqv? val 1)
((if term gen-1* gen-1)))
((eqv? val 2)
((if term gen-2* gen-2)))
((eqv? val nil)
((if term gen-null* gen-null)))
(else
((if term gen-cst* gen-cst) val))))
(define (ref var term)
(cond ((global? var)
((if term gen-ref-glo* gen-ref-glo) var))
((= var 0)
((if term gen-ref-loc-1* gen-ref-loc-1)))
((= var 1)
((if term gen-ref-loc-2* gen-ref-loc-2)))
((= var 2)
((if term gen-ref-loc-3* gen-ref-loc-3)))
(else
((if term gen-ref* gen-ref) var))))
(define (set var val term)
(cond ((global? var)
((if term gen-set-glo* gen-set-glo) var val))
((= var 0)
((if term gen-set-loc-1* gen-set-loc-1) val))
((= var 1)
((if term gen-set-loc-2* gen-set-loc-2) val))
((= var 2)
((if term gen-set-loc-3* gen-set-loc-3) val))
(else
((if term gen-set* gen-set) var val))))
(define (prc parms body term)
((cond ((null? parms)
(if term gen-pr0* gen-pr0))
((symbol? parms)
(if term gen-pr1/rest* gen-pr1/rest))
((null? (cdr parms))
(if term gen-pr1* gen-pr1))
((symbol? (cdr parms))
(if term gen-pr2/rest* gen-pr2/rest))
((null? (cddr parms))
(if term gen-pr2* gen-pr2))
((symbol? (cddr parms))
(if term gen-pr3/rest* gen-pr3/rest))
((null? (cdddr parms))
(if term gen-pr3 gen-pr3))
(else
(error "too many parameters in a lambda-expression")))
body))
(define (app vals glo term)
(apply (case (length vals)
((1) (if glo
(if term gen-ap0-glo* gen-ap0-glo)
(if term gen-ap0* gen-ap0)))
((2) (if glo
(if term gen-ap1-glo* gen-ap1-glo)
(if term gen-ap1* gen-ap1)))
((3) (if glo
(if term gen-ap2-glo* gen-ap2-glo)
(if term gen-ap2* gen-ap2)))
((4) (if glo
(if term gen-ap3-glo* gen-ap3-glo)
(if term gen-ap3* gen-ap3)))
(else (error "too many arguments in a proc application")))
vals))
;
; code generation for non-terminal evaluations
;
;
; constants
;
(define (gen-1) (lambda () 1))
(define (gen-2) (lambda () 2))
(define (gen-null) (lambda () #!null))
(define (gen-cst a) (lambda () a))
;
; variable reference
;
(define (gen-ref-glo a) (lambda () (cdr a))) ; global var
(define (gen-ref-loc-1) (lambda () (cadr *env*))) ; first local var
(define (gen-ref-loc-2) (lambda () (caddr *env*))) ; second local var
(define (gen-ref-loc-3) (lambda () (cadddr *env*))) ; third local var
(define (gen-ref a) (lambda () (do ((i 0 (1+ i)) ; any non-global
(env (cdr *env*) (cdr env)))
((= i a) (car env)))))
;
; assignment
;
(define (gen-set-glo a b) (lambda () (set-cdr! a (b))))
(define (gen-set-loc-1 a) (lambda () (set-car! (cdr *env*) (a))))
(define (gen-set-loc-2 a) (lambda () (set-car! (cddr *env*) (a))))
(define (gen-set-loc-3 a) (lambda () (set-car! (cdddr *env*) (a))))
(define (gen-set a b) (lambda () (do ((i 0 (1+ i))
(env (cdr *env*) (cdr env)))
((= i a) (set-car! env (b))))))
;
; conditional
;
(define (gen-tst a b c) (lambda () (if (a) (b) (c))))
;
; procedure application
;
(define (gen-ap0-glo a) (lambda () ((cdr a))))
(define (gen-ap1-glo a b) (lambda () ((cdr a) (b))))
(define (gen-ap2-glo a b c) (lambda () ((cdr a) (b) (c))))
(define (gen-ap3-glo a b c d) (lambda () ((cdr a) (b) (c) (d))))
(define (gen-ap0 a) (lambda () ((a))))
(define (gen-ap1 a b) (lambda () ((a) (b))))
(define (gen-ap2 a b c) (lambda () ((a) (b) (c))))
(define (gen-ap3 a b c d) (lambda () ((a) (b) (c) (d))))
;
; lambda expressions
;
(define (gen-pr0 a) ; without "rest" parameter
(lambda ()
(let ((def (cdr *env*)))
(lambda ()
(set! *env* (cons *env* def))
(a)))))
(define (gen-pr1 a)
(lambda ()
(let ((def (cdr *env*)))
(lambda (x)
(set! *env* (cons *env* (cons x def)))
(a)))))
(define (gen-pr2 a)
(lambda ()
(let ((def (cdr *env*)))
(lambda (x y)
(set! *env* (cons *env* (cons x (cons y def))))
(a)))))
(define (gen-pr3 a)
(lambda ()
(let ((def (cdr *env*)))
(lambda (x y z)
(set! *env* (cons *env* (cons x (cons y (cons z def)))))
(a)))))
(define (gen-pr1/rest a)
(lambda ()
(let ((def (cdr *env*)))
(lambda x
(set! *env* (cons *env* (cons x def)))
(a)))))
(define (gen-pr2/rest a)
(lambda ()
(let ((def (cdr *env*)))
(lambda (x . y)
(set! *env* (cons *env* (cons x (cons y def))))
(a)))))
(define (gen-pr3/rest a)
(lambda ()
(let ((def (cdr *env*)))
(lambda (x y . z)
(set! *env* (cons *env* (cons x (cons y (cons z def)))))
(a)))))
;
; code generation for terminal evaluations
;
;
; constants
;
(define (gen-1*)
(lambda ()
(set! *env* (car *env*))
1))
(define (gen-2*)
(lambda ()
(set! *env* (car *env*))
2))
(define (gen-null*)
(lambda ()
(set! *env* (car *env*))
#!null))
(define (gen-cst* a)
(lambda ()
(set! *env* (car *env*))
a))
;
; variable reference
;
(define (gen-ref-glo* a)
(lambda ()
(set! *env* (car *env*))
(cdr a)))
(define (gen-ref-loc-1*)
(lambda ()
(let ((val (cadr *env*)))
(set! *env* (car *env*))
val)))
(define (gen-ref-loc-2*)
(lambda ()
(let ((val (caddr *env*)))
(set! *env* (car *env*))
val)))
(define (gen-ref-loc-3*)
(lambda ()
(let ((val (cadddr *env*)))
(set! *env* (car *env*))
val)))
(define (gen-ref* a)
(lambda ()
(do ((i 0 (1+ i))
(env (cdr *env*) (cdr env)))
((= i a)
(set! *env* (car *env*))
(car env)))))
;
; assignment
;
(define (gen-set-glo* a b)
(lambda ()
(set! *env* (car *env*))
(set-cdr! a (b))))
(define (gen-set-loc-1* a)
(lambda ()
(set! *env* (car *env*))
(set-car! (cdr *env*) (a))))
(define (gen-set-loc-2* a)
(lambda ()
(set! *env* (car *env*))
(set-car! (cddr *env*) (a))))
(define (gen-set-loc-3* a)
(lambda ()
(set! *env* (car *env*))
(set-car! (cdddr *env*) (a))))
(define (gen-set* a b)
(lambda ()
(do ((i 0 (1+ i))
(env (cdr *env*) (cdr env)))
((= i 0)
(set! *env* (car *env*))
(set-car! env (b))))))
;
; procedure application
;
(define (gen-ap0-glo* a)
(lambda ()
(set! *env* (car *env*))
((cdr a))))
(define (gen-ap1-glo* a b)
(lambda ()
(let ((x (b)))
(set! *env* (car *env*))
((cdr a) x))))
(define (gen-ap2-glo* a b c)
(lambda ()
(let ((x (b)) (y (c)))
(set! *env* (car *env*))
((cdr a) x y))))
(define (gen-ap3-glo* a b c d)
(lambda ()
(let ((x (b)) (y (c)) (z (d)))
(set! *env* (car *env*))
((cdr a) x y z))))
(define (gen-ap0* a)
(lambda ()
(let ((w (a)))
(set! *env* (car *env*))
(w))))
(define (gen-ap1* a b)
(lambda ()
(let ((w (a)) (x (b)))
(set! *env* (car *env*))
(w x))))
(define (gen-ap2* a b c)
(lambda ()
(let ((w (a)) (x (b)) (y (c)))
(set! *env* (car *env*))
(w x y))))
(define (gen-ap3* a b c d)
(lambda ()
(let ((w (a)) (x (b)) (y (c)) (z (d)))
(set! *env* (car *env*))
(w x y z))))
;
; lambda
;
(define (gen-pr0* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda ()
(set! *env* (cons *env* def))
(a)))))
(define (gen-pr1* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda (x)
(set! *env* (cons *env* (cons x def)))
(a)))))
(define (gen-pr2* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda (x y)
(set! *env* (cons *env* (cons x (cons y def))))
(a)))))
(define (gen-pr3* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda (x y z)
(set! *env* (cons *env* (cons x (cons y (cons z def)))))
(a)))))
(define (gen-pr1/rest* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda x
(set! *env* (cons *env* (cons x def)))
(a)))))
(define (gen-pr2/rest* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda (x . y)
(set! *env* (cons *env* (cons x (cons y def))))
(a)))))
(define (gen-pr1/rest* a)
(lambda ()
(let ((def (cdr *env*)))
(set! *env* (car *env*))
(lambda (x y . z)
(set! *env* (cons *env* (cons x (cons y (cons z def)))))
(a)))))
;
; global defs
;
(define (define-global var val)
(if (assq var -glo-env-)
(set-cdr! (assq var -glo-env-) val)
(set! -glo-env- (cons (cons var val) -glo-env-))))
(define -glo-env- (list (cons 'define define-global)))
(define-global 'cons cons)
(define-global 'car car)
(define-global 'cdr cdr)
(define-global 'null? null?)
(define-global 'not not)
(define-global '< <)
(define-global '-1+ -1+)
(define-global '+ +)
(define-global '- -)
;
; current environment
;
(define *env* '(dummy)))
;
; environment manipulation
;
(define (restore-env)
(set! *env* (car *env*)))
;
; evaluator
;
(define (evaluate expr)
((compile (list 'lambda '() expr))))
;
; (evaluate '(define 'fib
; (lambda (x)
; (if (< x 2)
; x
; (+ (fib (- x 1))
; (fib (- x 2)))))))
;
;
--
... and I say to them, Usenet: oz@nexus.yorku.ca
`Where the hell were you ......!uunet!utai!yunexus!oz
when the page was blank?' Bitnet: oz@[yulibra|yuyetti]
Harlan Ellison Phonet: +1 416 736-5257x3976
------------------------------
End of Scheme Digest
********************
∂26-Mar-89 1910 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Mar 89 19:10:27 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 26 Mar 89 22:03:52 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab14534; 26 Mar 89 21:29 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa23966; 26 Mar 89 21:25 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA18502; Sun, 26 Mar 89 11:40:24 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA10648; Sun, 26 Mar 89 11:42:47 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA07435; Sun, 26 Mar 89 11:39:45 pst
Message-Id: <8903261939.AA07435@mrloog.LA.TEK.COM>
To: Pavel.pa@XEROX.COM
Cc: kend%mrloog.la.tek.com@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU,
scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET, kend@mrloog.la
Subject: Re: Portability (long)
In-Reply-To: Your message of Thu, 23 Mar 89 17:25:09 PST.
<890323-172519-6244@Xerox>
Date: 26 Mar 89 11:39:43 PST (Sun)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
This whole exercise seems entirely misguided to me. I have not seen you
(or anyone) respond well to Morry's objection that any ``appendix''
constitutes a standard with inertia of its own.
An appendix will have inertia just as any large body of code (of any
sort) has inertia. I don't believe that the inertia will be as great as
C's standard library because Scheme already has i/o and string=?, etc.
which C needed to be viable. Scheme is pretty viable on its own. In
addition, I expect things to change. R2RS->R3RS had some interesting
changes. Number syntax will change when (if) we can agree on ways to
deal with approximations to real numbers.
My proposal arises out of my perception that some names and functions are
widely used and are diverging. I think that defining a language without
some thought of its enviromnent is a bit like Algol without i/o. We
should not do much now, but there are some things that we do have
experience with. I have never seen a file system without the idea of a
file pointer designating a position within a file (Pascal got in trouble
with exactly this when they belatedly had to standardize). I have not
seen too many Lisps without a Read Eval Print Loop which has a way of
RESETing to the top level and EXITing to the host system. I don't need a
REPL to program my toaster-oven, but I do use them in many Schemes (T,
MacScheme. PCScheme, Skim, AmigaScheme and XScheme this last year) and
would like to be able to trust a few things not to change. I feel that
there is a need for discussion on the topics raised because the rate of
convergence for the Scheme community is very slow {e.g. numerics, macros}.
The Structure and Interpretation text is being used in over 125
universities last time I heard and I am concerned that issues be worked
on and solved before they become ISSUES.
I have also not seen any response to, I think, Jinx's point about using
extra ``compile'' and ``load'' files that test which implementation is in
use and coordinate things appropriately.
There is *no* standard way of finding out what implementation is running!
Any publication of a standard interface to certain facilities tends to
reduce experimentation among implementations. Such constraints should only
be imposed on facilities with which we collectively have significant
experience and on which we have reached consensus about what is The Right
Thing.
Agreed. The question is of balance and timing. I don't expect the
FORMAT function to have "~A" format string cause a program to abort. I
expect FORMAT (if it exists) to DISPLAY the next argument. I agree with
your statement. I think that in some areas we can reach a consensus.
I think that detailed discussion of your many proposals is premature until
you or others have more adequately justified the point of the whole
endeavor.
Well, there are some things it would be nice to do. Assuming that a
syntax system comes along soon, we can certainly do without ALIAS and
friends. To do a structure or object system a way of adding disjoint
types would be nice. I usually find some system code I can't recompile
with (e.g.) VECTOR? integrated, and I do get tired of rewriting a printer
to make sure something prints as #<structure foo> rather than a
strange-looking vector. I can't write a native or byte-code compiler
without the ability to do binary i/o. I can't do a portable interactive
text editor without the ability to set up software interrupt handlers.
Likewise, some sort of ERRORSET would be helpful in catching user runtime
errors in an editor rather than putting a user in some random debug REPL
in a raw mode tty. I have yet to see a runtime system library of any
size which did not supply a set of SORT functions or a RANDOM number
generator or some form of FORMATted output. Yes, I can do my own reader
for strings, but STRING-PORTs are much more convenient.
[OK, so I have a more-than-full-time job and outside interests. There is
a lot that I want. And I am impatient. I want great things. I want
discussions in certain areas so that we will have convergence.]
**"What, if any, of this is appropriate for the IEEE Scheme Standard at
this time?"**
Assuming a syntax system and a yellow pages (Real Soon Now...), the
minimum I see is the ability to query an implementation to find out its
name and version (Nice to get Operating and Filesystem likewise and what
numerics, etc. are supported).
I would very much like to see (and feel strongly about) having specific
problems addressed in a non-binding appendix (not part of the language
standard) and as interfaces only:
Binary i/o (including file positioning); <mumble>-ports
Formatted output (FORMAT)
Basic error handling, tracing
Compiler and Inspector invocation
Date and Time
I would be happy to see: (interfaces to)
Ability to add disjoint types (to support Structures, Objects)
Commonly used functionality.
-------------------------
Thank you for speaking up.
-Ken kend@mrloog.LA.TEK.COM
∂27-Mar-89 1400 @MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM Re: Portability (long)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Mar 89 14:00:18 PST
Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 27 Mar 89 16:52:58 EST
Received: from Salvador.ms by ArpaGateway.ms ; 27 MAR 89 13:32:49 PST
Date: Mon, 27 Mar 89 13:32:39 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Portability (long)
In-reply-to: <8903261939.AA07435@mrloog.LA.TEK.COM>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
Message-ID: <890327-133249-13090@Xerox>
I have no objection to attempting to gain concensus on language and library
issues that we believe are well understood. I believe, however, that many
of the issues you describe are not well understood or are not concerned
with the language or its libraries. In particular, many of your issues
concern facilities intended for use by a human programmer and not by
programs.
An example of an issue that clearly falls within the language or its
libraries is random access operations on ports for which they make sense,
such as a file input port.
An example of an issue outside of that domain is the notion of a
real-eval-print loop or a ``host system''. I strongly oppose
standardization of such notions because they are not universal in any
sense. You claim that you have ``not seen too many Lisps without a Read
Eval Print Loop which has a way of RESETing to the top level and EXITing to
the host system''. I have seen several, including Xerox Lisp and Symbolics
Genera; in these systems, there is no such thing as a ``host system'' and,
in Xerox Lisp at least, no institutionalized notion of a ``top level'' to
which one might return.
The Scheme language committees should not be concerned with a programmer's
ability maneuver in the user interface of an implementation. If, in a
particular implementation, the programmer cannot figure out, without
reading the documentation, how to manipulate a read-eval-print loop, it is
not an issue for the committees designing a language. We are not
attempting to design or standardize upon a user interface.
I have also not seen any response to, I think, Jinx's point about
using
extra ``compile'' and ``load'' files that test which implementation
is in
use and coordinate things appropriately.
There is *no* standard way of finding out what implementation is
running!
Of course there is: the human setting up the system can simply read the
name on the box containing the software. Come on, now; how hard can it be
for the human programmer to choose the appropriate system-dependent
compatibility file?
I usually find some system code I can't recompile
with (e.g.) VECTOR? integrated
Why is this an issue for standardization? If you're making changes to
``system code'', by which I assume you mean parts of some particular
implementation, then you're already completely non-portable. If that
implementation doesn't tell you all of the fancy hacks that they use in
preparing their system code, complain to them, not to the standardization
committee.
Assuming a syntax system and a yellow pages (Real Soon Now...), the
minimum I see is the ability to query an implementation to find out its
name and version (Nice to get Operating and Filesystem likewise and what
numerics, etc. are supported).
You don't need this in your program. Let the human do it.
Among your lists of desired interfaces, you include:
Basic error handling, tracing
Compiler and Inspector invocation
Error handling is a deep area in which I would be glad to see some
significant work done. I'm more than willing to consider seriously any
proposal that deals with the issues well. For example, I would love to see
someone work on discovering the clean kernel of ideas in the
useful-but-baroque Common Lisp condition system (sorry, Kent). I would, on
the other hand, object strongly to any patchwork solution unless we can get
concensus that it is a part of any ``real'' solution we might later adopt.
I don't want to standardize on short-term hacks.
Tracing and invocation of other implementation-dependent programming
environment facilities is not an appropriate area for standardization.
Programs don't type these commands, humans do; let those humans read that
particular system's documentation, if any.
In conclusion, I am not against the Scheme specification including the
interfaces to certain essentially universal libraries. I am, however,
opposed to any standardization of the user interface. In those cases where
standardization is appropriate, I would like to see very precise proposals
that clearly address the complete issue, rather than short-term patches.
Pavel
∂27-Mar-89 2021 @MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com Re: Portability (long) ...(now short)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 27 Mar 89 20:21:18 PST
Received: from RELAY.CS.NET (TCP 30007663404) by MC.LCS.MIT.EDU 27 Mar 89 23:15:56 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae05205; 27 Mar 89 19:30 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aa05834; 27 Mar 89 19:21 EST
Received: by tektronix.TEK.COM (5.51/7.0)
id AA17472; Mon, 27 Mar 89 15:33:04 PST
Received: by dadla.LA.TEK.COM (5.51/6.24)
id AA01309; Mon, 27 Mar 89 15:35:22 PST
Received: by mrloog.LA.TEK.COM (1.2/6.24)
id AA15848; Mon, 27 Mar 89 15:33:25 pst
Message-Id: <8903272333.AA15848@mrloog.LA.TEK.COM>
To: jinx@ZURICH.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU,
scheme-standard%kleph.ai.mit.edu@RELAY.CS.NET
Subject: Re: Portability (long) ...(now short)
In-Reply-To: Your message of Thu, 23 Mar 89 21:18:46 -0500.
<8903240218.AA13201@chamartin.AI.MIT.EDU>
Date: 27 Mar 89 15:33:23 PST (Mon)
From: kend%mrloog.la.tek.com@RELAY.CS.NET
****************************************
ALIAS is useful in porting code and exists in current implementations
(PCScheme, Scheme-84). Yes, all implementation have ways of providing
syntactic extensions. The problem is that few of them are the same
(macro, define-macro, define-syntax, extend-syntax, ...). I can't write
ALIAS portably.
I still find your argument circular. Please give me an example where
ALIAS solves anything by itself, ie. without any conditionalization.
ALIAS can be used to ease porting of code by obviating the need to go
through text files with an editor doing alpha-conversion `by hand'. I
guess that I am really impatient to get a uniform syntax system. If we
have to live with the current situation for another couple of years,
ALIAS and friends can be of some help. If we get syntax soon, we can
(and should) flush most syntax [although LET, LETREC, etc. would be nice
to keep, moving DO to the Yellow Pages would make quite a few people
happy].
****************************************
BOUND? may be a primitive procedure which accesses the environment of the
call via agreement between the compiler and runtime system. Isn't
requiring it to be a special form overspecification?
Therefore you would have
(let ((foo 3))
(bound? 'foo))
return #T
but
(define (check name)
(bound? name))
and separately compiled
(let ((foo 3))
(check? 'foo))
return #F? I don't believe you are really proposing this. This
violates all forms of referential transparency that I can think of.
NO!! The above should return #t! The agreement I was thinking of is use
of registers, shape of environment (ribcage, display, etc.) and so fourth.
If a compiler can recognize BOUND? as constant, it can do the elimination
of the test in the above case and just generate code to return #t.
Likewise for the CHECK case if you change the definition of CHECK to use
DEFINE-CONSTANT and the compiler has access to the seperately compiled
unit's binding information.
The more interesting question is when the BOUND? check can take place and
in what environment (read, compile, run). I would prefer to have this
resolved in the compile time environment so that no code is ever
generated to do the test. This is definately an environment problem
(unless we make such a function a part of the core language [to quote you:
"Yuck!"]). I guess the real question here is "Is the cure worse than the
disease?". What I want is a (cheap) way to test for desired
functionality, not just names. Perhaps we need to wait for a module
system and specification language.
Thanks,
-Ken
∂28-Mar-89 1308 @MC.LCS.MIT.EDU:ramsdell@huxley.MITRE.ORG copyrights
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 89 13:08:30 PST
Received: from mbunix.mitre.org (TCP 30003074001) by MC.LCS.MIT.EDU 28 Mar 89 15:52:30 EST
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@huxley.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
id AA09201; Tue, 28 Mar 89 15:51:27 EST
Posted-Date: Tue, 28 Mar 89 15:51:25 EST
Received: by huxley. (4.0/SMI-4.0)
id AA00405; Tue, 28 Mar 89 15:51:25 EST
Date: Tue, 28 Mar 89 15:51:25 EST
From: ramsdell@huxley.MITRE.ORG (John D. Ramsdell)
Message-Id: <8903282051.AA00405@huxley.>
To: rrrs-authors@mc.lcs.mit.edu
Subject: copyrights
Reply-To: ramsdell@MDF.mitre.org
The new copyright law effective March 1, 1989 states that some
documents have a copyright even if the document does not contain the
words "copyright 1989 by ..." or "Copr 1989 by ...". If we do not
intend to copyright R5RS, does anyone know what we must do to make it so?
John
∂28-Mar-89 1541 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu transitive arithmetic comparisons
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 89 15:41:29 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 28 Mar 89 18:33:01 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 28 Mar 89 15:32:58 PDT
Received: by fog.cs.uoregon.edu; Tue, 28 Mar 89 15:32:40 PDT
Date: Tue, 28 Mar 89 15:32:40 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8903282332.AA10517@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: transitive arithmetic comparisons
Jinx:
...Comparisons between exact and
inexact numbers should coerce the exact numbers to inexact...
Alan:
If <= is to behave transitively, even on inexact arguments, then you have
to coerce inexact number to exact numbers in order to perform comparisons.
It depends on the implementation. Fortunately this is of no concern to the
user, who can rest easy knowing that the arithmetic predicates are transitive
without having to know what the implementors had to go through to make them
so.
In an implementation that represents all exact reals as 32-bit fixnums, and
all inexact reals as 64-bit flonums, then it is correct to coerce exact to
inexact before comparing, as Jinx said.
In an implementation that represents all exact reals as fixnums, bignums, or
ratnums, and all inexact reals as flonums, then it is correct to coerce
inexact to exact before comparing, as Alan said.
In an implementation that represents all exact reals as 32-bit fixnums, and
all inexact reals as 32-bit flonums, then the correct behavior is much more
complicated because there exist fixnums that cannot be coerced to flonums
without loss of accuracy and vice versa. Likewise for implementations that
represent all exact reals as fixnums or bignums, and all inexact reals as
flonums. Although algorithms with the correct transitive behavior are a
bit too complicated for me to want to describe here, they exist.
The R4RS specifies only that the arithmetic predicates must be transitive.
It doesn't say how this is to be achieved, since that would require some
assumptions about the particular representations used for exact and inexact
numbers.
Peace, Will
∂28-Mar-89 1559 @MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu yellow pages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 89 15:59:03 PST
Received: from mist.math.uoregon.edu (TCP 20067602003) by MC.LCS.MIT.EDU 28 Mar 89 18:35:49 EST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 28 Mar 89 15:34:38 PDT
Received: by fog.cs.uoregon.edu; Tue, 28 Mar 89 15:34:13 PDT
Date: Tue, 28 Mar 89 15:34:13 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8903282334.AA10524@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
Subject: yellow pages
(a) The IEEE draft standard should NOT include things that belong in
the yellow pages. We need to get that set of public, portable programs
started. That's Ken's much-needed large library. Come on gang, it's
been over two years since Bill Rozas was appointed librarian, and I
haven't heard of a single contribution. GET WITH IT.
Hear, hear! Rather than give Ken a hard time, we should thank him
for getting us back to the reason for all this standardization:
so we can write and share portable code.
Rozas volunteered to be librarian for only six months, to get things
started. It's time for someone else to volunteer, and it's time for
that someone to make lists of what ought to go in the yellow pages
(as Ken has tried to do, but on a bigger scale) and enlist individuals
and companies to contribute those things. Chris Hanson, for example,
volunteered long ago to contribute a library of string-handling
procedures. I recently volunteered a portable string->number for the
R4RS syntax. The new librarian should nag us to do it, and publicize
their availability.
I agree with those who have said that this stuff shouldn't go into the
IEEE standard, at least not now. Get them into the yellow pages, use
them, and then standardize if appropriate.
I have a few specific comments on Ken's proposals and the discussion
they begat:
There is no such thing as a read/eval/print loop in applications
written using MacScheme+Toolsmith. The notion of such a thing may
seem natural to a Scheme programmer, but it generally makes no sense
to users of a system written in Scheme. This shows that the REPL
is part of the programming environment, which we have agreed not to
try to standardize. The same is true of RESET.
The reason that Ken's ERROR (which corresponds to CERROR in MacScheme)
can be a procedure rather than a special form is that programmers can
avoid calling it in a tail-recursive position if think they might want
to examine the environment of the procedure from which it is called.
That is, they can write (BEGIN (ERROR ...) #T) instead of (ERROR ...)
if they want. I suspect that anyone who prefers a special form to this
is probably going to be unhappy with Scheme anyway.
There are several semantically distinct notions of structures, each
with its own set of advantages. Compare, for example, the structures
used in PC Scheme with the system based on structural subtyping that
is distributed with MacScheme 2.0; compare both with the structures
used in the forthcoming book by Friedman, Haynes, Kohlbecker, and
Wand; compare all three with the records proposed last year by Rees.
I think we should first get half a dozen structure packages into the
yellow pages, wait a couple of years, and then see if people prefer
one to the others.
I don't see the need for a conditional compilation facility. Most
conditionalization can be handled in the load file, and the rest can
be handled with things like
(define make-bit-vector
(case **implementation**
((macscheme) make-bytevector)
(else (lambda (size) (make-string size #\0)))))
If the objection to this is the code size for the case expression,
the solution is to wait for the macro package and use a macro instead.
If the objection is that calls to make-bit-vector might not be as
efficient as calls to make-vector or make-bytevector, then I think
that's a different problem that doesn't have much to do with conditional
compilation.
Peace, Will
∂28-Mar-89 1624 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU yellow pages
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Mar 89 16:23:37 PST
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 28 Mar 89 19:17:39 EST
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA21021@chamartin.AI.MIT.EDU>; Tue, 28 Mar 89 19:17:19 -0500
Date: Tue, 28 Mar 89 19:17:19 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8903290017.AA21021@chamartin.AI.MIT.EDU>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@mc.lcs.mit.edu, scheme-standard@kleph.ai.mit.edu
In-Reply-To: William Clinger's message of Tue, 28 Mar 89 15:34:13 PDT <8903282334.AA10524@fog.cs.uoregon.edu>
Subject: yellow pages
Reply-To: jinx@zurich.ai.mit.edu
The reason that Ken's ERROR (which corresponds to CERROR in MacScheme)
can be a procedure rather than a special form is that programmers can
avoid calling it in a tail-recursive position if think they might want
to examine the environment of the procedure from which it is called.
That is, they can write (BEGIN (ERROR ...) #T) instead of (ERROR ...)
if they want. I suspect that anyone who prefers a special form to this
is probably going to be unhappy with Scheme anyway.
I understand that. That is why I suggested that the error special
form could expand into
((error-procedure <args>))
which again guarantees non tail-recursive position.
I disagree, however, with two of the points of the above paragraph:
I suspect that anyone who prefers a special form to this
is probably going to be unhappy with Scheme anyway.
I disagree with this sentence for obvious reasons.
programmers can
avoid calling it in a tail-recursive position if think they might want
to examine the environment of the procedure from which it is called.
The problem is that this choice by the programmer does not leave a
choice to the user of the program (who might be the same person at a
different point in time). I've often been upset at an earlier version
of myself for flushing state in a program when thinking that I
obviously would never need to examine it.
I think that having an ERROR procedure which makes it convenient to
flush the computation's state at a point when it should not be flushed
(as far as I'm concerned) is a really bad idea. I'd much rather have
programmers go out of the way to flush the state at an error than the
other way around, as you suggest.
∂04-Apr-89 2002 @MC.LCS.MIT.EDU:ziggy@hx.lcs.mit.edu Consistency
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 Apr 89 20:02:30 PDT
Received: from hx.LCS.MIT.EDU (TCP 2207400305) by MC.LCS.MIT.EDU 4 Apr 89 22:56:08 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 4 Apr 89 22:52:37 EDT
Message-Id: <2816736980-5305984@RTS-8>
Sender: ziggy@RTS-8.LCS.MIT.EDU
Date: Tue, 4 Apr 89 22:56:20 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@mc
Subject: Consistency
In the R↑3 Report, it is stated that some implementations allow
(= z1 z2...) which test if all its arguments are numerically
equal. [p.19]
I like this, but I wonder why we do not, for consistency, state
that some implementations will allow multiple argument:
EQ? EQUAL? EQV?
After all, they are comparison functions just like `='.
For that matter, what about: BOOLEAN? INTEGER? ...
Or even: CHAR-ALPHABETIC? ...
** Or anything else with a `?' in its name! **
Does this sound like ``Andy Rooney meets RRRS''?
~Ziggy
P.S. I'm not just trying to make trouble... I honestly
wanted to test (eq? x y z) today... really.
∂07-Apr-89 0749 @MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu ftp'able R3.95RS
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:49:41 PDT
Received: from kleph.ai.mit.edu (TCP 2212600254) by MC.LCS.MIT.EDU 5 Apr 89 11:42:55 EDT
Received: by kleph.ai.mit.edu (5.59/1.5)
id AA16637; Wed, 5 Apr 89 10:44:18 EST
Date: Wed, 5 Apr 89 10:44:18 EST
From: cph@kleph.ai.mit.edu (Chris Hanson)
Message-Id: <8904051544.AA16637@kleph.ai.mit.edu>
To: will@fog.cs.uoregon.edu
Cc: rrrs-authors@kleph.ai.mit.edu
In-Reply-To: William Clinger's message of Tue, 4 Apr 89 16:33:08 PDT <8904050033.AA06109@fog.cs.uoregon.edu>
Subject: ftp'able R3.95RS
Reply-To: cph@zurich.ai.mit.edu
Date: Tue, 4 Apr 89 16:33:08 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Did you receive my message saying that I had ftp'ed the R3.95RS to zurich/tmp?
I haven't seen any announcement of it. Are you in circulation? Please
acknowledge this message.
Peace, Will
The R3.95RS sources are available via anonymous ftp from
"zurich.ai.mit.edu", as one of the following files:
pub/scheme-reports/r3.95rs.tar
pub/scheme-reports/r3.95rs.tar.Z
Sorry for the delay -- I've been on vacation and just returned.
∂07-Apr-89 0750 @MC.LCS.MIT.EDU:ziggy@hx.LCS.MIT.EDU R↑3.95 non-idealities (anal)
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:49:58 PDT
Received: from hx.LCS.MIT.EDU (TCP 2207400305) by MC.LCS.MIT.EDU 5 Apr 89 15:19:27 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Wed, 5 Apr 89 15:15:53 EDT
Date: Wed, 5 Apr 89 15:15:53 EDT
From: ziggy@hx.LCS.MIT.EDU (Michael R. Blair)
Message-Id: <8904051915.AA26396@hx.LCS.MIT.EDU>
To: rrrs-authors@mc
Subject: R↑3.95 non-idealities (anal)
I noticed that, like the R↑3 Report, that
CATCH and RETURN are in the index. Is this
an oversight? If not, I don't understand why
EXIT and GOTO are not.
~Ziggy
Sorry to send this to the entire list, but
I just don't have any luck trying to send
directly to Will.
∂07-Apr-89 0754 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #95
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Apr 89 07:53:44 PDT
Date: 7 APR 89 00:04:07 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #95
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #95 7 APR 89 00:04:07 EDT
Today's Topics:
Please help me with Xscheme
TI Macros for MIT C-Scheme - Patch #1
----------------------------------------------------------------------
Date: 6 Apr 89 17:57:52 GMT
From: agate!web-3b.berkeley.edu!c60c-3ds@ucbvax.berkeley.edu
Subject: Please help me with Xscheme
Message-Id: <22714@agate.BERKELEY.EDU>
2 questions:
Where can I get documentation for Dave Betz's Xscheme?
I just tried to compile it on the ST with Sozobon C and encountered some
problems. First, some of the function names are >7 chars, and lose uniqueness.
I just put some defines in to take care of this. Second, the loader might
be broken, because I get errors like "Undefined: __sscanf from d(fscanf.o)"
My copy of Xscheme sources had no ststuff.c file, so I used the one from xlisp,
and added the missing file functions. I doubt if that is where the bug is.
( ( John Kawakami ) )
) ) c60c-3ds@web.berkeley.edu ( (
( ( ) )
------------------------------
Date: 6 Apr 89 07:50:29 GMT
From: jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!ists!mike@rutgers.edu (Mike Clarkson)
Subject: TI Macros for MIT C-Scheme - Patch #1
Message-Id: <375@ists.ists.ca>
I am embarrassed. The shar that I used to package the previous postings
of macros for TI functionality junked the last line if it didn't end with
a line-feed. So some of the files were truncated.
Enclosed are patches to fix the problem, plus a new feature (PP), and
some hooks for future development of the FLUIDS package.
My apologies to those who were frustrated by my error.
Snip here and feed to patch.
Mike.
-------------------------------------------------------------------------------
diff -c dist1.0/README dist1.1/README
*** dist1.0/README Thu Apr 6 03:03:42 1989
--- dist1.1/README Thu Apr 6 02:52:22 1989
***************
*** 2,9 ****
TI PC COMPATIBILITY PACKAGE
! Version 1.0
! March 1989
For MIT C-Scheme 6.2.2
--- 2,9 ----
TI PC COMPATIBILITY PACKAGE
! Version 1.1
! April 1989
For MIT C-Scheme 6.2.2
***************
*** 82,90 ****
ASSERT
GET-FILE-POSITION (Needs support in C for opening files with append)
(SET! (VECTOR-REF vector n) value) (not implemented yet)
- (SET! (FLUID var) value) (not implemented yet)
SYNTAX (Conflicts with the MIT syntax)
The windows code will have to wait until the next release of C-Scheme,
which should have some windowing code to support Edwin:
--- 82,98 ----
ASSERT
GET-FILE-POSITION (Needs support in C for opening files with append)
(SET! (VECTOR-REF vector n) value) (not implemented yet)
SYNTAX (Conflicts with the MIT syntax)
+ The fluids code is being worked on (with many thanks to jinx);
+ at the moment there are just "Not implemented yet" macros in place.
+
+ FLUID
+ FLUID-BOUND
+ FLUID-LAMBDA
+ TI-FLUID-LET
+ (SET! (FLUID var) value)
+
The windows code will have to wait until the next release of C-Scheme,
which should have some windowing code to support Edwin:
***************
*** 107,114 ****
WINDOW-SET-SIZE!
WINDOW?
! Engines have not been implemented, though I may look at making kwh's
! tasks act like engines:
MAKE-ENGINE
ENGINE-RETURN
--- 115,122 ----
WINDOW-SET-SIZE!
WINDOW?
! Engines have not been implemented. Jinx has supplied me with a set of
! engines that I am testing out, at least for Bsd systems.
MAKE-ENGINE
ENGINE-RETURN
***************
*** 130,136 ****
POSITION-PEN
The line editor hasn't been ported, but in these days od Gnu, does anyone
! reall care?
EDIT
--- 138,144 ----
POSITION-PEN
The line editor hasn't been ported, but in these days od Gnu, does anyone
! really care?
EDIT
diff -c dist1.0/compile-the-files.scm dist1.1/compile-the-files.scm
*** dist1.0/compile-the-files.scm Thu Apr 6 03:03:43 1989
--- dist1.1/compile-the-files.scm Wed Apr 5 10:12:49 1989
***************
*** 16,18 ****
--- 16,19 ----
(sf "window.scm")
;; The main file that loads or auto-loads the rest
+ (sf "ti.scm")
diff -c dist1.0/parser-escape.scm dist1.1/parser-escape.scm
*** dist1.0/parser-escape.scm Thu Apr 6 03:03:46 1989
--- dist1.1/parser-escape.scm Wed Apr 5 10:18:50 1989
***************
*** 24,26 ****
--- 24,27 ----
(intern-string-no-coerce! (loop (read-string delimiters))))))
;; end in-package parser-package
+ )
diff -c dist1.0/scoops.scm dist1.1/scoops.scm
*** dist1.0/scoops.scm Thu Apr 6 03:03:39 1989
--- dist1.1/scoops.scm Wed Apr 5 10:19:00 1989
***************
*** 1161,1163 ****
--- 1161,1165 ----
((access ,(%sc-concat "SET-" var) (%sc-method-env ,class)) ,val)))))
;; end scoops-package environment
+ ))
+
diff -c dist1.0/sort.scm dist1.1/sort.scm
*** dist1.0/sort.scm Thu Apr 6 03:03:32 1989
--- dist1.1/sort.scm Wed Apr 5 10:19:08 1989
***************
*** 107,109 ****
--- 107,111 ----
(vector-copy v)
0
(-1+ (vector-length v)))
+ v)
+
diff -c dist1.0/ti.scm dist1.1/ti.scm
*** dist1.0/ti.scm Thu Apr 6 03:03:34 1989
--- dist1.1/ti.scm Thu Apr 6 02:52:35 1989
***************
*** 165,174 ****
((string? pathname)
(string->pathname pathname))
(else (error "DOS-CHDIR: Not a pathname, symbol or string")))))
-
-
-
;;; DOS-COPY-FILE
(define dos-file-copy copy-file)
--- 165,171 ----
***************
*** 221,226 ****
--- 218,240 ----
;;; EXPLODE
(autoload-from-file "$SCHEME/xplode" '(explode))
+ ;;; FLUID
+ (add-syntax! 'fluid (macro (var)
+ `(writeln "Not implemented yet")))
+
+ ;;; FLUID-BOUND?
+ (add-syntax! 'fluid-bound? (macro (var)
+ `(writeln "Not implemented yet")))
+
+ ;;; FLUID-LAMBDA
+ (add-syntax! 'fluid-lambda (macro (bindings . code)
+ `(writeln "Not implemented yet")))
+
+ ;;; FLUID-LET
+ ;; Renamed to TI-FLUID-LET as it Conflicts with MIT's fluid-let
+ (add-syntax! 'ti-fluid-let (macro (bindings . code)
+ `(writeln "Not implemented yet")))
+
;;; FLUSH-INPUT
(define (flush-input #!optional port)
(let ((newline-delimiters (char-set #\Newline)))
***************
*** 370,378 ****
--- 384,435 ----
;; Not implemented yet - needs C support
(autoload-from-file "$TISCHEME/file-extend" '(open-extend-file))
+ ;;; PCS-DEBUG-MODE
+ ;; Just a stub - always true
+ (define pcs-debug-mode #T)
+
;;; PI
(define pi (* 4.0 (atan 1.0 1.0)))
+ ;;; PP
+ (define pp
+ (let ()
+ (define (prepare scode)
+ (let ((s-expression (unsyntax scode)))
+ (if (and (pair? s-expression)
+ (eq? (car s-expression) 'NAMED-LAMBDA))
+ `(DEFINE ,@(cdr s-expression))
+ s-expression)))
+
+ (lambda (scode #!optional port width)
+
+ (define (kernel as-code?)
+ (if (scode-constant? scode)
+ ((access ti-pp scheme-pretty-printer) scode as-code? width)
+ ((access ti-pp scheme-pretty-printer) (prepare scode) true width)))
+
+ (cond ((unassigned? port)
+ (set! port *current-output-port*))
+ ((not (port? port)) (error 'PP "Bad port" port)))
+ (cond ((unassigned? width)
+ (set! width
+ (let ((x-size ((access :x-size port))))
+ (if x-size (min 72 x-size) 72))))
+ ((not (integer? width)) (error 'PP "Bad width" width)))
+ (with-output-to-port port
+ (lambda () (kernel false)))
+ *the-non-printing-object*)))
+
+ (in-package scheme-pretty-printer
+ (define (ti-pp expression as-code? width)
+ (fluid-let ((x-size width))
+ (let ((node (numerical-walk expression)))
+ (*unparse-newline)
+ ((if as-code? print-node print-non-code-node) node 0 0)
+ ((access :write-char *current-output-port*) char:newline)
+ ((access :flush-output *current-output-port*)))))
+ )
+
;;; POINT-COLOR
(autoload-from-file "$TISCHEME/graphics" '(point-color))
***************
*** 434,440 ****
eof-object)))
;;; REC
! ;; You may want to change REC of lambdas to named lambdas
(syntax-table-define system-global-syntax-table 'REC
(macro (var exp)
`(letrec ((,var ,exp)) ,var)))
--- 491,497 ----
eof-object)))
;;; REC
! ;; You may want to change REC of lambdas to NAMED-LAMBDAs
(syntax-table-define system-global-syntax-table 'REC
(macro (var exp)
`(letrec ((,var ,exp)) ,var)))
***************
*** 527,532 ****
(newline)
(define (ti-compatibility-package-version)
! "1.0")
(writeln "TI Functions loaded.")
--- 584,590 ----
(newline)
(define (ti-compatibility-package-version)
! "1.1")
(writeln "TI Functions loaded.")
+
--
Mike Clarkson mike@ists.UUCP
Institute for Space and Terrestrial Science mike@ists.ists.ca
York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3 +1 (416) 736-5611
------------------------------
End of Scheme Digest
********************
∂07-Apr-89 2125 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #96
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Apr 89 21:25:15 PDT
Date: 8 APR 89 00:04:42 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #96
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #96 8 APR 89 00:04:42 EDT
Today's Topics:
Clarification to force needed
My force example
----------------------------------------------------------------------
Date: Fri, 7 Apr 89 13:36:56 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904072036.AA16743@polya.Stanford.EDU>
Subject: Clarification to force needed
I am sending this to both lists, though I don't know if this is a
problem in the ANSI spec.
I believe that the current definition of (force <promise>) could use
some rewording to make it clear that FORCE is only entitled to memoize
when the promise has returned. That is, the sequence:
(set! expr (delay (if get-out (escape↑ #f) #t)))
(call/cc (lambda (cont)
(set! escape! cont)
(set! escape #t)
(force expr)))
(set! escape #f)
(force expr)
A problem can arise if forces change their type codes too early. The
intent is that if executing a force succeeds everything is fine, but
that one is entitled to restart a force that has been thrown out of.
My intent is also that
(set! fred (delay (begin ... (force blah) (throw...))))
(force fred)
is entitled to memoize blah if it succeeds, even if the overall delay
FRED is thrown from.
I believe this was the original intent, but it would be useful to make
the behavior outlined above explicitly correct in the standard.
Jon Shapiro
Stanford University
------------------------------
Date: Fri, 7 Apr 89 15:11:41 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904072211.AA23851@polya.Stanford.EDU>
Subject: My force example
Should have read
(define escape↑ )
(set! expr (delay (if get-out (escape↑ #f) #t)))
(call/cc (lambda (cont)
(set! escape↑ cont)
(set! get-out #t)
(force expr)))
(set! get-out #f)
(force expr)
Apologies for the inconvenience of redistribution...
Jon
------------------------------
End of Scheme Digest
********************
∂12-Apr-89 2131 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #97
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Apr 89 21:31:06 PDT
Date: 13 APR 89 00:05:26 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #97
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #97 13 APR 89 00:05:26 EDT
Today's Topics:
Belaboring the subject
----------------------------------------------------------------------
Date: 13 Apr 89 00:08:22 GMT
From: Robert Steven Glickstein <bobg+@andrew.cmu.edu>
Subject: Belaboring the subject
Message-Id: <sYEyHqy00Vsn02KUVY@andrew.cmu.edu>
I am very eager to know the status of the R↑4 Report on Scheme. A recent post
mentioned the R↑3.95 Report, but I can't find it anywhere, and if a more recent
revision exists, I'd be more interested in that. Can anyone help me?
==============
Bob Glickstein
ITC Database Group
Information Technology Center
Carnegie Mellon University
Pittsburgh, PA
==============
------------------------------
End of Scheme Digest
********************
∂16-Apr-89 1329 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #98
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Apr 89 13:28:56 PDT
Date: 16 APR 89 00:05:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #98
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #98 16 APR 89 00:05:45 EDT
Today's Topics:
Scheme on Macintosh
Comments from ieee spec
----------------------------------------------------------------------
Date: 16 Apr 89 00:00:25 GMT
From: husc8!houpt@husc6.harvard.edu (Thomas Houpt)
Subject: Scheme on Macintosh
Message-Id: <1636@husc6.harvard.edu>
I am looking for a good implementation of Scheme or its dialects for
use on a Mac (specifically an SE-30). I would like it to support Abelson
and Sussman compatability, as well as compiling to stand-alone Mac
applications (with full Mac interface stuff) Is MacScheme+Toolsmith
the thing to get? Or do other people have things in the works that would
be better? Thanks in advance!
------------------------------
Date: Sat, 15 Apr 89 20:25:00 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904160325.AA17437@polya.Stanford.EDU>
Subject: Comments from ieee spec
I recently grabbed a copy of the standard dated April 15 from
zurich.ai.mit.edu. I am forwarding some comments that I think are
relevant for R4RS to this group too.
Since I am new to the scheme community, it would be presumptuous to
assume that I have understood the subtleties of all of the standard,
but there are some areas that were unclear to me or seemed to permit
contradictory interpretations, and I thought I would send out comments
on these areas.
I hope the scheme group will accept those comments that are helpful,
and I look forward to any feedback I may get on my misunderstandings.
DEFINE:
The semantics of DEFINE is historically problematic. The change in
R3RS that eliminated the implicit LETREC in defines forces me to
generate code that checks to see if the procedure's variable has been
side effected by someone I call before I do the tail-recursive call.
If there were no other way to achieve side-effectability I would be
content with this, but it seems to me that there is an alternative
that does not require the compiler to pessimize the most-common-case:
First, I suggest that including (define <variable>) in R4RS, and
specifying that <variable> gets bound to an unspecified value
addresses the needs of both compilers and users.
If this change is made (I am sending this proposal to the
scheme-standard group too on the grounds that usage has effectively
standardized it), then the common case can be rewritten as:
(define name => (begin (define name)
(lambda ...)) (set! name
(letrec ((name (lambda ...)))
name)))
and the less-common case is still handled when needed by explicitly
writing the sequence
(define name)
(set! name (lambda ...))
Whatever is done, the semantics of what scope the lambda appears in
should be specified.
The only real problem I see with this is that it may imply a need to
extend BEGIN to handle things like
(begin (define ...) (set! ...) (define ...))
WRITE:
Write should return #f on failure and #t on success, or it should be
an error to write a value to an external port that lacks an external
representation.
I advocate returning #t or #f, which would permit me to build a
wrapper function to deal with failure rationally, and avoids the need
to define external ports. Failing to distinguish external ports from
internal ports is a bad idea because it constrains an implementation
from defining something analogous to a pipe. Returning #t or #f lets
the program deal with write errors by attempting to tell someone.
This would also permit an implementation to extend write such that it
can write continuations, and thereby implement DUMP-HEAP. Programs
could assume this facility, try it, and issue an appropriate
diagnostic if it doesn't work.
The standard shouldn't include DUMP-HEAP, but it shouldn't constrain
WRITE in a way that prohibits it either.
GENERAL:
1) Implementations should be encouraged somewhere to implement (WRITE
<continuation>). A representation should be written that when read
with READ results in a thunk that is an equivalent function to the
written continuation. The representation of continuations should be
implementation-defined.
Rationale: We all acknowledge that this is pragmatically something
that we want, and there should be a standard interface. Having write
return a value lets me assume the capability without causing problems
for implementations that don't support it.
2) I believe that the user-interface section should specify a
procedure (DUMP-WORLD "filename" <continuation>) that writes a
representation that can be executed in an implementation-dependent way
to arrive at the specified continuation. The <continuation> argument
should be optional, and if left unspecified should default to the
continuation that DUMP-WORLD will return to. DUMP-WORLD should return
#t if it succeeds or #f if it fails or the implementation doesn't
supply the functionality.
Rationale: The whole community acknowledges that we want this, but
that it is implementation-dependent. This proposal permits us to
specify the interface to it and construct our programs in a way that
deals gracefully with failure and doesn't impose it on
implmementations that don't or can't do it.
Why DUMP-WORLD and not DUMP-HEAP? Unlike DUMP-HEAP, which is covered
by WRITE, DUMP-WORLD does something fundamentally
implementation-specific.
------------------------------
End of Scheme Digest
********************
∂17-Apr-89 1605 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 16:04:57 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 17 Apr 89 18:58:19 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA07765@chamartin.AI.MIT.EDU>; Mon, 17 Apr 89 17:58:25 -0500
Date: Mon, 17 Apr 89 17:58:25 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904172258.AA07765@chamartin.AI.MIT.EDU>
To: shap@polya.stanford.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Jonathan S. Shapiro's message of Sat, 15 Apr 89 20:24:25 -0700 <8904160324.AA17433@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu
I recently grabbed a copy of the standard dated April 15 from
zurich.ai.mit.edu. Since I am new to the scheme community, it would
be presumptuous to assume that I have understood the subtleties of all
of the standard, but there are some areas that were unclear to me or
seemed to permit contradictory interpretations, and I thought I would
send out comments on these areas.
Which standard? Do you mean the ieee standard or the informal r4rs
report? The scheme-standard mailing list deals with the ieee
standard, while rrrs-authors deals with the informal report. Many
issues are important to both mailing lists, so sending mail to both is
probably the right thing to do since there are some people on one but
not the other. I think that your comments apply to r4rs, not the ieee
standard, so the message should have been sent to rrrs-authors as well.
I commend to your consideration adding an implementation note pointing
out the advantage of introducing of a special value, #undefined, which
is "returned" when an evaluation results in an unspecified value.
Rationale: The presence of such a value substantially simplifies
debugging by permitting the environment to analyze precisely the
nature of an error (i.e. the implementation doesn't have to worry
about debugging random pointers).
In light of lack of experience and agreement about this construct, it
would be inappropriate to standardize it at this time, but it would be
appropriate to mention it in an implementation notes aside.
I mostly agree with your recommendation, but your rationale does not
quite hold. The "problem" with unspecified values is that they can
propagate for an unbounded amount of time before anyone actually tries
to do something with them that will fail. For example, they can be
stored in a data structure which will not be examined until much
later. At the point at which the unspecified object causes an error,
there is often no context from the process that created the
unspecified object, so debugging is not really enhanced.
The return values of certain expressions are left unspecified for a
variety of reasons:
- No agreement within the community on what the return value should
be. See below the case of SET!
- Agreement that no value is especially useful and/or meaningful. In
this case the implementation does not have to track down some other
value, and can return something more convenient.
Another possibility would be a class (type) of unspecified objects
which would capture some "essential" aspect of the situation in which
they were created/returned. This could be made much more useful for
debugging, but would probably incur some performance problems. I
won't suggest requiring/recommending this.
----------------------------------------------------------------------
I think there is a conflict implied between this paragraph and
paragraph 3 of this section. The conflict is exemplified by:
(define mystring "abc")
(string-set! mystring 0 #\f)
The third paragraph as written implies that "abc" can be allocated in
read-only memory, and since string-set! does not "create" a new
object, paragraph one implies that read-only memory can be
side-effected. See my proposed rewording to paragraph 3.
There is another interpretation, which is that the STRING-SET! is in
error for attempting to modify an immutable object. The last sentence
of the third paragraph of this section in r3.95rs says precisely this.
A correct analogous program would be
(define mystring (string-copy "abc"))
(string-set! mystring 0 #\f)
An altogether different problem is that of determining whether an
object is immutable. Maybe an IMMUTABLE? predicate should be added to
the language, so that user written procedures can detect this case and
give a meaningful error message rather than causing an error in the
middle of system code.
----------------------------------------------------------------------
This paragraph could be misread to imply that objects must be
implemented with "in-use" bits. While this is a common implementation
method, it should be thought of as a conceptual approach, not an
implementation constraint. The wording also implies that the in-use
bits must always be kept up-to-date, which clearly is undesirable.
Would you be happy if the word "conceptually" were inserted before
"marked" at the beginning of the paragraph?
Other:
It might be helpful to note here somehow that there is useful
constraint that is not as strong as "immutable". There is a class of
objects named by top-level symbols that may be mutated but not resized
or rendered out-of-use, and it might be worth adding a paragraph to
point out that these can always be considered to be allocated. [Point
being to partition them from the space considered for garbage
reclamation].
I don't think that is reasonable for the standard. Implementations
may support objects in static areas, but I don't think that the
language itself should concern itself with such issues.
----------------------------------------------------------------------
The result of SET! being unspecified is sufficiently unusual that I
would be curious as to the rationale. To my knowledge, no semantic
difficulties are introduced by having SET! return the value, and there
is enough code out there that makes this assumption that in the
absence of a compelling reason to remove it SET! should return the
value.
There is disagreement in the community about what the return value
should be. MIT Scheme follows the convention that assignment (ie. SET!)
and slot assignment procedures (ie. SET-CAR!, STRING-SET!, etc.)
return the OLD contents, not the new value. Other implementations
follow the more usual convention of returning the new value.
Code making the assumption that any particular convention holds is
not portable.
----------------------------------------------------------------------
The standard does not specify the meaning of
(define <variable>)
which is in sufficiently common usage that it should be included.
<variable> should be bound to an unspecified value.
I agree, but I think there was some discussion about this, and it was
dropped, but I don't remember the reason.
Also, the semantics of DEFINE is historically problematic. The
change in R3RS that eliminated the implicit LETREC in defines forces
me to generate code that checks to see if the procedure's variable has
been side effected by someone I call before I do the tail-recursive
call.
That's not quite true. This behavior can be achieved by the following
implementations:
- Fetch the operator of the call by indirecting through a cell.
Assignments modify this cell.
- Assignment becomes "smart" about modifying the operators of certain
calls, and "does the right thing".
Furthermore, a programmer who wants to preclude the possibility of
assignment to the variable can do so by using
(define foo
(letrec ((foo (lambda ...)))
foo))
or
(define (foo .args.)
(letrec ((foo (lambda ...)))
(foo .args.)))
If this change is made (I am sending this proposal to the scheme group
too), then the common case rewrite rule is:
(define name => (begin (define name)
(lambda ...)) (set! name
(letrec ((name (lambda ...)))
name)))
Note that here you are suggesting something even more drastic than
what r2rs had. In r2rs
(define foo (lambda (x) ...))
and
(define (foo x) ....)
were NOT equivalent, since the second form had in implicit LETREC in it.
I'm also not sure that I agree with you that the expansion with LETREC
is desirable as a default. The differences between the two cases
above in r2rs and this question about desirability are the reasons
that the semantics was changed for r3rs. Although your proposal would
make the meaning of both forms be the same, I suspect you will find a
fair amount of opposition (including myself) to having an implicit
LETREC in
(define foo (lambda (x) ....))
----------------------------------------------------------------------
It should be specified whether the standard-procedures are considered
immutable or not. I could make a good compiler argument for them
being immutable and a good user argument for them being mutable (can
add polymorphism through appropriate SET! and LET hacks). It is my
opinion that this decision should not be left to the implementation.
I don't know what you mean about procedures being immutable. Do you
mean mutating the procedure object or changing the value of the
variable which initially holds a standard procedure? The language as
it currently appears provides no means for destructuring and mutating
procedure objects. As far as assigning those variables, I think it is
allowed by the language. My understanding of the paragraph on
immutable data is that only literal constants can be made immutable,
but there are no literal bindings.
----------------------------------------------------------------------
Write should return #f on failure and #t on success, or it should be
an error to write a value to an external port that lacks an external
representation.
There are two different issues here:
- One is whether WRITE should do something useful with all objects.
- The other is WRITE/READ invertibility, that is whether the output of
WRITE should always be valid input to READ and should cause READ to
return/create an object similar (same?) as that given to WRITE
originally.
Although the report does not explicitely state it (maybe it should),
I think that the authors agree that WRITE should accept all objects as
arguments and "print" something descriptive.
I don't think there is agreement that WRITE should be able to "print"
a "complete" representation of a procedure or a continuation, or what
this would mean. At the core of the matter is the fact that although
the notion of procedural equivalence is mathematically well defined,
it is not decidable, so there would be no way to effectively test a
WRITE/READ pair and ultimately to "know" what to print. Any other
definition of similarity between procedures would be artificial and
likely to cause confusion and problems.
An altogether different issue is whether we should adopt the C
convention of returning an arbitrary value when an unhandled situation
occurs or whether we should signal an error. In general I don't
believe in returning arbitrary values as a substitute for errors,
although I think there are some cases (like STRING->NUMBER) were we
can make an exception because of common usage. I don't think that
WRITE falls in this category.
The standard shouldn't include DUMP-HEAP, but it shouldn't constrain
WRITE in a way that prohibits it either.
I think this is already true. Although I doubt that DUMP-HEAP would
be written in terms of WRITE.
----------------------------------------------------------------------
1) Implementations should be encouraged somewhere to implement (WRITE
<continuation>). A representation should be written that when read
with READ results in a thunk that is an equivalent function to the
written continuation. The representation of continuations should be
implementation-defined.
I don't know what that means. What do you mean by an equivalent
function? Should all environment information be "re-interned" on the
way in so that side effects by the original continuation are visible
by the "new" continuation and viceversa?
Rationale: We all acknowledge that this is pragmatically something
that we want, and there should be a standard interface. Having write
return a value lets me assume the capability without causing problems
for implementations that don't support it.
I'm not sure I want something that I don't understand. It would have
to be very well and clearly defined for me to accept it.
----------------------------------------------------------------------
2) I believe that the user-interface section should specify a
procedure (DUMP-WORLD "filename" <continuation>) that writes a
representation that can be executed in an implementation-dependent way
to arrive at the specified continuation. The <continuation> argument
should be optional, and if left unspecified should default to the
continuation that DUMP-WORLD will return to. DUMP-WORLD should return
#t if it succeeds or #f if it fails or the implementation doesn't
supply the functionality.
As I said above, I don't believe in procedures returning arbitrary values rather
than signalling errors.
Rationale: The whole community acknowledges that we want this, but
that it is implementation-dependent. This proposal permits us to
specify the interface to it and construct our programs in a way that
deals gracefully with failure and doesn't impose it on
implmementations that don't or can't do it.
Why DUMP-WORLD and not DUMP-HEAP? Unlike DUMP-HEAP, which is covered
by WRITE, DUMP-WORLD does something fundamentally
implementation-specific.
In general, we decided to drop most user interface and development
environment procedures because we could easily envision environments
where they did not make sense. The current consensus is that most of
those procedures should not be in the language. Programs that depend
on this kind of functionality can be structured so that the
dependencies are restricted to a few modules which can be easily
rewritten for similar environments.
I think that LOAD and the transcript procedures have been dropped from
the draft ieee document for this reason.
∂17-Apr-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #99
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 21:39:48 PDT
Date: 18 APR 89 00:06:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #99
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #99 18 APR 89 00:06:13 EDT
Today's Topics:
Question with binding
Question with binding
----------------------------------------------------------------------
Date: Mon, 17 Apr 89 12:10:33 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904171910.AA26688@polya.Stanford.EDU>
Subject: Question with binding
I have been thinking about compiling scheme, and am confused about the
following possibility:
(define foo (lambda (x) (+ x 2)))
(define + (lambda (x y) something))
(foo)
If this is legal, I don't understand how a compiler can validly inline
primitives. Is there some provision in R3RS or R4RS that resolves
this problem, or is it really a problem? If the latter, how do
compilers deal with it?
Jon
------------------------------
Date: 17 Apr 89 20:36:41 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3107@kalliope.rice.edu>
In article <8904171910.AA26688@polya.Stanford.EDU> shap@POLYA.STANFORD.EDU (Jonathan S. Shapiro) writes:
>I have been thinking about compiling scheme, and am confused about the
>following possibility:
>
> (define foo (lambda (x) (+ x 2)))
> (define + (lambda (x y) something))
> (foo)
>
>If this is legal, I don't understand how a compiler can validly inline
>primitives. Is there some provision in R3RS or R4RS that resolves
>this problem, or is it really a problem? If the latter, how do
>compilers deal with it?
>
>Jon
Indiana University's Schemefolk treated this problem as follows (it's
possible I err here, in which case I profusely apologize to those
concerned):
A bunch of primitive functions, e.g., +, cons, etc., were treated as
_constants_ in the sense that the names could not have other values
assigned to them. This is not weird, since it recalls the usual
treatment of certain other constant names, e.g., 1, nil (or rather
#f), "hello", etc. Thus your (define + ...) would bomb.
They went on to add the facility (declare-constant ...) to the
language (Scheme84) so that the user could define hir own set of
constants. This was merely for the user's convenience, _not_ a
directive to the compiler to inline.
Just to make things interesting, they also added the facility
(undeclare-constant ...). It works as expected for user-defined
constants, which aren't inlined anyway. But for the system-constants,
while previous inlining stays, any new uses of the constant name take
on the new definition if any. (Is that clear? >:-])
--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice. --Isaac Bashevis Singer
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂18-Apr-89 2134 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Apr 89 21:34:30 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:07:54 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA09084@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:08:18 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA19933; Tue, 18 Apr 89 16:58:34 -0700
Date: Tue, 18 Apr 89 16:58:34 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904182358.AA19933@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: rrrs-authors@chamartin.AI.MIT.EDU, scheme-standard@mc.lcs.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard
I was talking about the ieee standard in my comments.
In response to my strings-immutable coment, Jinx suggested:
A correct analogous program would be
(define mystring (string-copy "abc"))
(string-set! mystring 0 #\f)
I really don't care for this. It makes strings substantively
different from vectors, when conceptually they ought not be. Further,
why is it that strings are reasonable things to put into immutable
space and lists, lambdas, etc. are not?
No, if what you want is to be able to have things in constant space,
introduce a construct that says so. Don't perturb well understood and
correct behavior.
After seeing Jinx's response, [I still am not sure he was serious...]
it seems all the more important that section 3.5 make it explicitly
clear that an object is only a candidate for immutable storage if the
implementation can prove that it cannot be mutated by the program.
Jon
∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Apr 89 23:11:52 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:33:11 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA09106@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:33:33 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA22078; Tue, 18 Apr 89 17:32:17 -0700
Date: Tue, 18 Apr 89 17:32:17 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190032.AA22078@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard
Procedures/immutability
Jinx pointed out (as did Mike Shaff) that my posting is unclear.
After talking this one through with Mike Shaff, he and Ifeel that this
issue deserves some discussion, though the results may not be
applicable to the IEEE standard.
As we see it, there are two things we might want to be able to say
with respect to mutability:
(define-immutable fred value)
says that the binding of fred to value cannot be changed. The value
of the storage may change if there exists a mutator to alter it, thus:
(define-immutable mylist '(a b))
allows
(set-car! mylist 1)
but not
(set! mylist fred)
This construct is not theoretically necessary, but neither are a lot
of other things in scheme. What makes such a construct desirable is
that if I can show that there is no mutator that can act on the
relevant value, it frees me to do partial evaluation. If the value is
a lambda, this is enough to let me do procedure integration.
We could argue that this construct would be better expressed by
(declare immutable <name>) [syntax]
A DECLARE form would be permissable in any context that a define form
is permissable. Thinking about it, I prefer this syntax, as it works
for let-bindings as well as defines.
Note that a binding being immutable is not something that causes
contamination. It is okay to say
(let ((b mylist)) ..body..)
and do whatever I please to B.
The second thing that we want to say something about is immutability
of values. By this, we might use:
(define-immutable constant-fred (constant (list '(a b))))
The (constant X) item entitles to put the value in immutable storage,
and makes it an error to do an operation that side-effects the value.
This property is contaminating. Given,
(let ((b constant-fred)) ..body..)
B is a mutable binding to an immutable value.
Now, I am satisfied that I understand DEFINE-IMMUTABLE, though I
debate about DEFINE-IMMUTABLE vs DECLARE. It should either be
nonreversable (i.e. once a binding is made immutable I am stuck) or it
should have temporal scope lasting until the binding is made mutable
again using (DECLARE MUTABLE <name>). Evaluations in the interim are
entitled to have assumed integrability.
I don't like the CONSTANT construct. First, it really wants to be
syntax, because if it takes any value it can have really ugly
propagational effects. What you want, it seems to me, is to have
either a separate set of constructors for constant objects or a syntax
that can be wrapped around the constructors. I don't know which I
like better. In either case, a (CONSTANT?) would need to be added.
I would like to see some discussion of this on the scheme lists.
Finally, to the original question, which has since been answered. Are
the standard function bindings mutable. The answer is apparently
"yes", and thanks to those who answered.
∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Apr 89 23:12:18 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:43:06 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA09116@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:43:31 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA22474; Tue, 18 Apr 89 17:42:48 -0700
Date: Tue, 18 Apr 89 17:42:48 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190042.AA22474@polya.Stanford.EDU>
To: jinx@zurich.ai.mit.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Comments on the draft standard
Now that I have had a chance to think about jinx's response on
read/write, and talked this over with M. Shaff as well.
Regarding the problem of read/write invertability, peace. Hadn't
thought it through, though I still maintain that there is merit to
standardizing the interfaces to dumpheap and dumpworld.
On the other hand, I now agree that read/write shouldn't return #f or
#t. The problem is, I really don't want to have to be killed (an
error is signalled...) when a read/write fails. I believe that the
best solution would be to add a third optinal argument to everything
that takes a port, the argument being of the form
(lambda args ..body..)
Which is the continuation to be called with some
implementation-specific arguments. An error should be signalled only
in the absence of such a continuation.
Thus:
(write <value> [ <port> [ <error-continuation> ]])
Comments?
Jon
∂18-Apr-89 2312 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Conusion with peek-char and char-ready
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Apr 89 23:12:43 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 18 Apr 89 20:53:20 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA09126@chamartin.AI.MIT.EDU>; Tue, 18 Apr 89 19:53:44 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA22919; Tue, 18 Apr 89 17:53:13 -0700
Date: Tue, 18 Apr 89 17:53:13 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904190053.AA22919@polya.Stanford.EDU>
To: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Guillermo J. Rozas's message of Mon, 17 Apr 89 17:58:25 -0500 <8904172258.AA07765@chamartin.AI.MIT.EDU>
Subject: Conusion with peek-char and char-ready
The conflict with char-ready? vs rubout handlers arises with peek-char
also, and it is very bad that the current draft requires no guarantee
that what I get from PEEK-CHAR is what I will get from a subsequent
READ-CHAR [I suspect this is a temporary editing discontinuity
introduced by the removal of CHAR-READY?]. This is emphatically *not*
the right thing, as it leads to an ambiguity in usage: one usage is to
use PEEK-CHAR to watch the instantaneous input stream, the other is to
do lookahead. If the relationship between PEEK-CHAR and READ-CHAR is
not strengthened, this confusion will get embedded in programs in
subtle ways.
The problem arises out of a confusion between readahead and
rubout/kill processing. In the presence of rubout handling,
CHAR-READY? should only return #t if there is input that has been
committed (on a UNIX system, if return has been pressed for the input
line). In the absence of rubout handling, (i.e. raw mode I/O),
CHAR-READY should return #t if a character has been typed.
This is getting pretty deep into terminal I/O specific stuff, and it
isn't clear to me that we ought to do that.
The problem can be temporarily resolved by restoring CHAR-READY? with
the interpretation above and introducing something like
(I/O-MODE <port> 'BUFFERED)
(I/O-MODE <port> 'RAW)
I think it would be better to do this than standardize on an I/O
facility in which there is no way to guarantee non-blocking read.
I am in general greatly concerned that the IEEE standardization is
very premature, and will lead to diverging practices in commercial
implementations that will make the language nearly impossible to
converge later.
Jon
∂19-Apr-89 0145 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #100
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 01:45:02 PDT
Date: 19 APR 89 00:06:19 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #100
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #100 19 APR 89 00:06:19 EDT
Today's Topics:
Question with binding
Question with binding
Defsystem for Scheme ?
Help me get Oaklisp
Oaklisp bignum multiplication
----------------------------------------------------------------------
Date: Mon, 17 Apr 89 23:49:51 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904180449.AA07981@chamartin.AI.MIT.EDU>
Subject: Question with binding
Reply-To: jinx@zurich.ai.mit.edu
I have been thinking about compiling scheme, and am confused about the
following possibility:
(define foo (lambda (x) (+ x 2)))
(define + (lambda (x y) something))
(foo)
If this is legal, I don't understand how a compiler can validly inline
primitives. Is there some provision in R3RS or R4RS that resolves
this problem, or is it really a problem? If the latter, how do
compilers deal with it?
Hopefully calling foo with no arguments gives a "wrong number of
arguments error" irrelevant of whether + is open coded. :-)
Now seriously, according to (my interpretation of) r3rs/r4rs,
assigning a new value to the variables which hold the standard
procedures is legal, and should have the "expected" effect. Thus open
coding standard procedures is "strictly" illegal in a pure r3rs/r4rs
environment.
In MIT Scheme, no open coding happens by default, and there are no
constant bindings. There are, however, a variety of declarations, of
which the most frequently found is
(declare (usual-integrations))
which tell the compiler that some set of common variables will have
their standard values at run time and that the compiler can freely
integrate/open-code these values.
In the absence of this (or another relevant) declaration, the compiler
will issue code which will act as if it referenced the variable at
call time and then invoked the resulting value. Thus changing the
value of + at run time will change the behavior of compiled code that
references +.
------------------------------
Date: Tue, 18 Apr 89 01:07 EDT
From: Andre van Meulebrouck <vanMeule@ALLEGHENY.SCRC.Symbolics.COM>
Subject: Question with binding
Message-ID: <19890418050732.4.VANMEULE@PERTA.SCRC.Symbolics.COM>
Date: 17 Apr 89 20:36:41 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3107@kalliope.rice.edu>
In article <8904171910.AA26688@polya.Stanford.EDU> shap@POLYA.STANFORD.EDU (Jonathan S. Shapiro) writes:
>I have been thinking about compiling scheme, and am confused about the
>following possibility:
>
> (define foo (lambda (x) (+ x 2)))
> (define + (lambda (x y) something))
> (foo)
>
>If this is legal, I don't understand how a compiler can validly inline
>primitives. Is there some provision in R3RS or R4RS that resolves
>this problem, or is it really a problem? If the latter, how do
>compilers deal with it?
>
>Jon
[...]
A bunch of primitive functions, e.g., +, cons, etc., were treated as
_constants_ in the sense that the names could not have other values
assigned to them. [...]
↑↑That's my understanding too: the idea that certain procedures can't change
during the course of a compilation/computation, otherwise things couldn't be
guaranteed to make sense if they were meanwhile allowed to change underneath
your feet during the computation/compilation. As to user defined
functions--well if you want to do those sorts of things with your own functions,
okay, but the system won't let you do that with its functions (upon which it
might depend, or otherwise feels some responsibility to protect the integrity
of). Something like that...(and I too profusely apologize if I misstated or
oversimply stated...).
In MacScheme, if you try (define + ...) you get:
ERROR: Integrable procedures may not be redefined.
(set! + ...)
I like the idea of that a great deal...I don't think the convenience of being
able to redefine things (advertently or inadvertently--with or without warning)
is a wonderful feature. You can always write your own similar functions with
different names, and call out to those in preference if a system function isn't
quite what you wanted, right?
--dorai
------------------------------
Date: 18 Apr 89 03:30:35 GMT
From: mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!ists!mike@ohio-state.arpa (Mike Clarkson)
Subject: Defsystem for Scheme ?
Message-Id: <380@ists.ists.ca>
Does anyone have a defsystem for Scheme? Something along the lines
of the Symbolics 6.x type would be nice.
If not I'll hack one.
Mike.
--
Mike Clarkson mike@ists.ists.ca
Institute for Space and Terrestrial Science uunet!attcan!ists!mike
York University, North York, Ontario, FORTRAN - just say no.
CANADA M3J 1P3 +1 (416) 736-5611
------------------------------
Date: Tue, 18 Apr 89 19:57 N
From: <FM%DACTH51.BITNET@mitvma.mit.edu>
Subject: Help me get Oaklisp
This is a repost of an article I accidently posted to info-cscheme instead of
scheme@mc. I still don't know how to get Oaklisp over BITNET. Please don't
mail to martins@rwthinf.uucp, they make me pay for my mail.
A while ago somebody, I think one of the authors, K. Lang or B. Pearlmutter,
posted a arcticle saying that a new release of OakLisp is available. I don't
have this article anymore, but anyhow it would be pretty useless since I
can't ftp. Does somebody know a way I can get Oaklisp over BITNET ? I
really like the ideas in Oaklisp and I can't wait to play with it.
! Martin Schoenert, martins@rwthinf.uucp, fm@dacth51.bitnet, +49 241 804551 !
! Lehrstuhl D Mathematik, RWTH, Templergraben 64, D 51 Aachen, West Germany !
------------------------------
Date: Tue, 18 Apr 89 19:58 N
From: <FM%DACTH51.BITNET@mitvma.mit.edu>
Subject: Re: Oaklisp bignum multiplication
In my original posting I asked about Oaklisp's multiplication method. Barak
Pearlmutter answered:
"Actually, Sun3 benchmarks came out in favor of the elementary school
algorithm for numbers below a certain size, so the fancy algorithm
doesn't kick in unless both numbers are pretty big."
Just how big ? I evaluated various multiplication methods once, and found
that numbers have to be bigger than ~1000 decimal digits to gain from using
Karatsubas method. Such large numbers don't occur very often, even in a
computational algebra system.
"In any case, you're
correct that things are O( n↑.59 m ) where n<m, but by either writing a
balanced factorial function or making a special kind of factor-number
which delays computation until the result is needed and then does a
balanced multiplication tree, (FACT 1000) can be sped up considerably."
Sure, but computing factorials isn't terrible exiting. And my feeling is
that in applications like computational algebra systems it will happen quite
often that one of the operands will be rather small.
! Martin Schoenert, martins@rwthinf.uucp, fm@datch51.bitnet, +49 241 804551 !
! Lehrstuhl D Mathematik, RWTH, Templergraben 64, D 51 Aachen, West Germany !
------------------------------
End of Scheme Digest
********************
∂19-Apr-89 0711 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:10:55 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 19 Apr 89 09:55:44 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA09480@chamartin.AI.MIT.EDU>; Wed, 19 Apr 89 08:54:53 -0500
Date: Wed, 19 Apr 89 08:54:53 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904191354.AA09480@chamartin.AI.MIT.EDU>
To: shap@polya.Stanford.EDU
Cc: rrrs-authors@chamartin.AI.MIT.EDU, scheme-standard@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 16:58:34 -0700 <8904182358.AA19933@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu
A correct analogous program would be
(define mystring (string-copy "abc"))
(string-set! mystring 0 #\f)
I really don't care for this. It makes strings substantively
different from vectors, when conceptually they ought not be. Further,
why is it that strings are reasonable things to put into immutable
space and lists, lambdas, etc. are not?
There is no difference between strings, vectors, and lists at this
level. Your example used strings, so I just rewrote it to be correct.
Vector and list literals can be immutable as well and the same would
apply to them. As far as lambdas, they are not objects in the
language. Procedures are immutable in the standard since no
operations that destructure/mutate them are provided. Lists
representing lambda expressions and which evaluate to procedures are
just lists, so anything applying to lists applies to them as well.
I'm not defending immutable structures, I'm just interpreting the
report and the understanding of the authors at this point. Besides
the obvious implementation desire to put such literals in "immutable
space", there are other reasons, the main of which is that the static
meaning of programs becomes harder to determine if literals are
mutable.
After seeing Jinx's response, [I still am not sure he was serious...]
it seems all the more important that section 3.5 make it explicitly
clear that an object is only a candidate for immutable storage if the
implementation can prove that it cannot be mutated by the program.
I was dead serious.
What you suggest would prevent most literals from becoming immutable
since they are externally visible or returned to the "outside world"
inside of lists or other structures which can be destructured outside.
Note that personally I don't really care what the report says about
mutating literals. I consider doing it bad style, but I don't like to
legislate style. Maybe one of the proponents of immutable literals
can better answer your objections.
∂19-Apr-89 0723 @MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU Comments on the draft standard
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:23:10 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 19 Apr 89 09:58:52 EDT
Received: by chamartin.AI.MIT.EDU (5.61/1.2)
id <AA09483@chamartin.AI.MIT.EDU>; Wed, 19 Apr 89 08:58:27 -0500
Date: Wed, 19 Apr 89 08:58:27 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904191358.AA09483@chamartin.AI.MIT.EDU>
To: shap@polya.Stanford.EDU
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@chamartin.AI.MIT.EDU
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 17:42:48 -0700 <8904190042.AA22474@polya.Stanford.EDU>
Subject: Comments on the draft standard
Reply-To: jinx@zurich.ai.mit.edu
On the other hand, I now agree that read/write shouldn't return #f or
#t. The problem is, I really don't want to have to be killed (an
error is signalled...) when a read/write fails. I believe that the
best solution would be to add a third optinal argument to everything
that takes a port, the argument being of the form
Hopefully a condition/error handling subsystem will be added to a
future version of the standard. In the meantime condition handling is
implementation dependent.
As far as WRITE is concerned, I think it should handle all kinds of
objects, and signal no errors of this kind.
∂19-Apr-89 0814 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu Confusion with peek-char and char-ready
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 08:14:30 PDT
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 19 Apr 89 11:08:12 EDT
Received: by void.ai.mit.edu (5.59/1.5)
id AA29111; Wed, 19 Apr 89 10:12:58 EST
Date: Wed, 19 Apr 89 10:12:58 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8904191512.AA29111@void.ai.mit.edu>
To: shap@polya.stanford.edu
Cc: scheme-standard@mc.lcs.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro's message of Tue, 18 Apr 89 17:53:13 -0700 <8904190053.AA22919@polya.Stanford.EDU>
Subject: Confusion with peek-char and char-ready
Reply-To: jar@zurich.ai.mit.edu
Regarding the question of the interaction between PEEK-CHAR,
CHAR-READY?, and input editing, I think we should first check to see
what the Common Lisp cleanup committee has figured out; I know they
have considered this problem, and there's no sense in us reinventing
the wheel if they've figured out something reasonable. Could someone
out there who follows cl-cleanup stuff investigate for us?
The main reason I would like to see PEEK-CHAR in Scheme is so that it
becomes possible to write something like READ in a portable way. READ
has the property, not explicitly stated but I believe assumed, that if
the file contains "foo)" and you do READ followed by READ-CHAR, you
get the symbol FOO and the character #\). In order to write READ, you
have to have a way to determine whether you have arrived at the end of
a symbol, number, etc. either by hitting a delimiter or by hitting end
of file. The definition of PEEK-CHAR or any replacement for it should
be whatever it has to be to support this application.
Perhaps we don't need the full generality of PEEK-CHAR to get this
functionality, though. E.g. if the language had something like C
Scheme's character sets, we could have READ-CHAR-IF-IN-CSET, which
would read a character if it was among a given set and return #f
otherwise. I'm not proposing this, just mentioning it to point out
that there may be alternatives that don't get us into as much trouble.
∂19-Apr-89 1247 @MC.LCS.MIT.EDU:jar@void.ai.mit.edu test message
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 12:47:21 PDT
Received: from void.ai.mit.edu (TCP 2206400236) by MC.LCS.MIT.EDU 19 Apr 89 15:11:15 EDT
Received: by void.ai.mit.edu (5.59/1.5)
id AA29231; Wed, 19 Apr 89 14:16:55 EST
Date: Wed, 19 Apr 89 14:16:55 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8904191916.AA29231@void.ai.mit.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: test message
Reply-To: jar@zurich.ai.mit.edu
Testing the mailing list. Please ignore.
∂19-Apr-89 2152 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #101
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 19 Apr 89 21:52:41 PDT
Date: 20 APR 89 00:06:40 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #101
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #101 20 APR 89 00:06:40 EDT
Today's Topics:
Question with binding
Question with binding
Question with binding
Question with binding
----------------------------------------------------------------------
Date: 19 Apr 89 00:26:00 GMT
From: silver!mitchemt@iuvax.cs.indiana.edu
Subject: Re: Question with binding
Message-Id: <56700003@silver>
As far as I know, (define + (lambda (x y) (* x y))) will work just fine under
Chez Scheme. I agree that it would be hard to write a compiler for this type
of code. I don't think it will bomb but you might get some weird results. Hope
this is of some help.
Terrence Mitchem, Indiana University.
------------------------------
Date: 19 Apr 89 02:36:52 GMT
From: Brad Pierce <pierce@locus.ucla.edu>
Subject: Re: Question with binding
Message-Id: <23115@shemp.CS.UCLA.EDU>
In article <56700003@silver> mitchemt@silver.bacs.indiana.edu writes:
>
>As far as I know, (define + (lambda (x y) (* x y))) will work just fine under
>Chez Scheme. I agree that it would be hard to write a compiler for this type
>of code. I don't think it will bomb but you might get some weird results. Hope
>this is of some help.
> Terrence Mitchem, Indiana University.
The way Chez Scheme handles this problem is to have 4 different
optimization levels, numbered 0-3. At levels 0 and 1, the lower
levels, this definition will work just fine. At levels 2 and 3
redefining a primitive such as + will not be allowed. This has
worked well for me. Why force one approach or the other on a
user when both needs can be accomodated?
-- Brad Pierce, UCLA
------------------------------
Date: 19 Apr 89 07:38:36 GMT
From: agate!web-2d.berkeley.edu!laba-4he@ucbvax.berkeley.edu (The Cybermat Rider)
Subject: Re: Question with binding
Message-Id: <23293@agate.BERKELEY.EDU>
Here's my $0.02, from R(3.5)RS (apologies if it's already been posted by
someone else):
2.1 Identifiers
[.....]
Identifiers have several uses within Scheme programs:
+ Certain identifiers are reserved for use as syntactic keywords
(see below)
====> + Any identifier that is not a syntactic keyword may be used as a
====> variable
[.....]
The following identifiers are syntactic keywords, and should not be
used as variables:
=> do or
and else quasiquote
[.....]
+ is NOT defined as a syntactic keyword, and hence can (IMHO) be bound to
just about anything, even (gasp!) an integer. Whether a particular
implementation chooses to allow such a re-binding, though, is really the
decision of the implementor.
Btw, if any of you think this could cause major headaches, try reading
"Oaklisp: an Object-Oriented Scheme with First Class Types" [Lang &
Pearlmutter, OOPSLA '86 Proceedings]. As the title implies, even data types
can be re-defined!!
----------------------------------------------------------------------------
Adrian Ho a.k.a. The Cybermat Rider University of California, Berkeley
laba-4he@web.berkeley.edu (WEB Evans, Home of The CS Freakies)
Disclaimer: Nobody takes me seriously, so is it really necessary?
------------------------------
Date: Wed, 19 Apr 89 09:33:23 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904191433.AA09504@chamartin.AI.MIT.EDU>
Subject: Question with binding
Reply-To: jinx@zurich.ai.mit.edu
[...]
A bunch of primitive functions, e.g., +, cons, etc., were treated as
_constants_ in the sense that the names could not have other values
assigned to them. [...]
↑↑That's my understanding too: the idea that certain procedures
can't change during the course of a compilation/computation,
otherwise things couldn't be guaranteed to make sense if they were
meanwhile allowed to change underneath your feet during the
computation/compilation. As to user defined functions--well if
you want to do those sorts of things with your own functions,
okay, but the system won't let you do that with its functions
(upon which it might depend, or otherwise feels some
responsibility to protect the integrity of). Something like
that...(and I too profusely apologize if I misstated or oversimply
stated...).
What is the difference between variables holding standard procedures
and those holding user procedures or those holding other kinds of
values (ie. pi, true, etc)?
There are two different issues here:
- The first is whether "system/language definitions" should be more
binding than user definitions. I certainly think that they should
not. The system is just a set of tools/utilities for the user, who
should be free to ignore them/replace them or do anything s/he wants.
For example, I may not like a system's definition of LENGTH, because
it is not generic accross lists, vectors ans strings. I should be
able to go ahead and redefine it. Since my new definition works on
lists as well, no one should notice except myself, who will be
considerably happier.
- The second issue is whether there should be immutable bindings, and
again I don't believe in them either. Say that you have written a
program which creates and maintains a database and that 10 years down
the road (during which it has been running continuously) you find a
bug in some utility. It would be nice to be able to replace it by a
correct version and continue as if nothing had happened. Not being
able to redefine it might waste 10 years worth of computation.
Nobody but yourself will change things underneath your feet, and you
can certainly impose any convention that you want on your variables,
but please don't build it into the language since I may consider your
conventions unreasonable.
In MacScheme, if you try (define + ...) you get:
ERROR: Integrable procedures may not be redefined.
(set! + ...)
I like the idea of that a great deal...I don't think the
convenience of being able to redefine things (advertently or
inadvertently--with or without warning) is a wonderful feature.
You are viewing it as an idle feature, which it is not. Consider it a
way that the system provides for installing patches and improvements.
As far as MacScheme is concerned, I'm not sure whether Will Clinger
still agrees to this or not, but I think that the last time we talked
about it he agreed that all bindings should be mutable, although
implementations might default to a "benchmark mode" in which some
bindings would be considered constant.
You can always write your own similar functions with different
names, and call out to those in preference if a system function
isn't quite what you wanted, right?
Why should the system have precedence over me, the user? The system
should be just a library of utilities for me to use as I please.
More power to users, not to programs! :-)
------------------------------
End of Scheme Digest
********************
∂20-Apr-89 2205 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #102
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 Apr 89 22:04:56 PDT
Date: 21 APR 89 00:06:50 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #102
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #102 21 APR 89 00:06:50 EDT
Today's Topics:
Question with binding
package question
where define is legal
Question with binding
where define is legal
----------------------------------------------------------------------
Date: Wed, 19 Apr 89 09:33:13 PDT
From: mkatz@sesame (Morris Katz)
Message-Id: <8904191633.AA14869@sesame.Stanford.EDU>
Subject: Question with binding
Date: Tue, 18 Apr 89 01:07 EDT
From: Andre van Meulebrouck <vanMeule@ALLEGHENY.SCRC.Symbolics.COM>
Date: 17 Apr 89 20:36:41 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3107@kalliope.rice.edu>
In article <8904171910.AA26688@polya.Stanford.EDU> shap@POLYA.STANFORD.EDU (Jonathan S. Shapiro) writes:
>I have been thinking about compiling scheme, and am confused about the
>following possibility:
>
> (define foo (lambda (x) (+ x 2)))
> (define + (lambda (x y) something))
> (foo)
>
>If this is legal, I don't understand how a compiler can validly inline
>primitives. Is there some provision in R3RS or R4RS that resolves
>this problem, or is it really a problem? If the latter, how do
>compilers deal with it?
>
>Jon
[...]
A bunch of primitive functions, e.g., +, cons, etc., were treated as
_constants_ in the sense that the names could not have other values
assigned to them. [...]
↑↑That's my understanding too: the idea that certain procedures can't change
during the course of a compilation/computation, otherwise things couldn't be
guaranteed to make sense if they were meanwhile allowed to change underneath
your feet during the computation/compilation. As to user defined
functions--well if you want to do those sorts of things with your own functions,
okay, but the system won't let you do that with its functions (upon which it
might depend, or otherwise feels some responsibility to protect the integrity
of). Something like that...(and I too profusely apologize if I misstated or
oversimply stated...).
In MacScheme, if you try (define + ...) you get:
ERROR: Integrable procedures may not be redefined.
(set! + ...)
I like the idea of that a great deal...I don't think the convenience of being
able to redefine things (advertently or inadvertently--with or without warning)
is a wonderful feature. You can always write your own similar functions with
different names, and call out to those in preference if a system function isn't
quite what you wanted, right?
--dorai
Yes, but this may not be the correct way to think about things. Lets say that
I want to count the number of cons cells that are formed in a suite of
programs. A good way to do this might be to create an environment in which the
constructors like CONS and LIST were aliased to versions that counted the
number of cells they allocated. The program suite could then be run in this
new environment to gather the desired statistics. I would find the alternative
of modifying all of the programs in the test suite much less elegant and quite
inconvenient. In on approach the cost of implementation is constant and in the
other it is proportional to the size of the test suite.
Morry Katz
katz@polya.stanford.edu
------------------------------
Date: 20 Apr 89 12:36:06 GMT
From: mcvax!tuvie!brock@uunet.uu.net (Inst.f.Prakt.Info 1802)
Subject: package question
Message-Id: <683@tuvie>
Hi
I have a question or two to experienced Lisp/Scheme programmers about the
package mechanism.
1.) Are packages an acceptable equivalent to modules in conv. programming lang.?
2.) Do you use them for all of Your code?
3.) Are there any common problems programmers normally have when beginning
using packages?
(perhaps some of you holding courses may answer this)
4.) How do you handle I/O?
5.) Do there exist alternatives to packages. (Well OO-extensions, but are
there also simpler alternatives?)
Please answer directly to me, I'll post a summary to comp.lang.lisp.
Thanks in advance
Ulrich
Please answer to: (ulrich@vip.at UUCP: ...!mcvax!tuvie!vip!ulrich)
------------------------------
Subject: where define is legal
Message-Id: <8904201554.AA13117@spt.entity.com>
Date: 20 Apr 89 15:54:43 EDT (Thu)
From: alms@spt.entity.com (andrew lm shalit)
Offhand, the following definition seems bogus:
(define (foo bool)
(if bool
(define (result) #true)
(define (result) #false))
(result))
And indeed, when I try to run this in MacScheme, I get an error message.
I agree with the semantics, but I couldn't find anything in the R3
description of DEFINE which restricts where it may appear.
Some people from non-scheme backgrounds might think programmatic DEFINEs
perfectly reasonable, so it's probably worth mentioning the restriction
in the language description.
------------------------------
Date: 20 Apr 89 18:49:34 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3131@kalliope.rice.edu>
In article <8904191633.AA14869@sesame.Stanford.EDU> mkatz@sesame (Morris Katz) writes:
$ Date: Tue, 18 Apr 89 01:07 EDT
$ From: Andre van Meulebrouck <vanMeule@ALLEGHENY.SCRC.Symbolics.COM>
$ Date: 17 Apr 89 20:36:41 GMT
$ From: titan!dorai@rice.edu (Dorai Sitaram)
$ [...]
$ A bunch of primitive functions, e.g., +, cons, etc., were treated as
$ _constants_ in the sense that the names could not have other values
$ assigned to them. [...]
$
$ ↑↑That's my understanding too: the idea that certain procedures can't change
$ during the course of a compilation/computation, otherwise things couldn't be
$ guaranteed to make sense if they were meanwhile allowed to change underneath
$ your feet during the computation/compilation. As to user defined
$ functions--well if you want to do those sorts of things with your own functions,
$ okay, but the system won't let you do that with its functions (upon which it
$ might depend, or otherwise feels some responsibility to protect the integrity
$ of). [...]
$
$ In MacScheme, if you try (define + ...) you get:
$
$ ERROR: Integrable procedures may not be redefined.
$ (set! + ...)
$
$ I like the idea of that a great deal...I don't think the convenience of being
$ able to redefine things (advertently or inadvertently--with or without warning)
$ is a wonderful feature. You can always write your own similar functions with
$ different names, and call out to those in preference if a system function isn't
$ quite what you wanted, right?
$
$ --dorai
↑↑↑↑↑↑↑
Not right (for me). BTW, I did _not_ say the above. They are Andre's
words. I needed to say this, because I tend to the diametrically
opposite opinion >:-].
$Yes, but this may not be the correct way to think about things. Lets say that
$I want to count the number of cons cells that are formed in a suite of
$programs. A good way to do this might be to create an environment in which the
$constructors like CONS and LIST were aliased to versions that counted the
$number of cells they allocated. The program suite could then be run in this
$new environment to gather the desired statistics. I would find the alternative
$of modifying all of the programs in the test suite much less elegant and quite
$inconvenient. In on approach the cost of implementation is constant and in the
$other it is proportional to the size of the test suite.
$ Morry Katz
An earlier version of Chez did in fact allow redefinition of system
"constants" to be visible in existing system code, not just in
existing (and of course future) user code. One can use this to good
effect to define modified versions of the interpreter-eval, Morry's
cell-counting cons, etc. However, the current Chez has a most curious
stance on this matter. System "constants" can be redefined, but while
existing user code reflects these changes, system code is immune.
Obviously, there is no inlining going on. It's almost as if the
implementors took care to seal off system code with a huge "let",
i.e., (let ([cons cons] ... [<sys-const> <sys-const>] ...)
<sys-code>), so that any redefinition of the <sys-const>'s doesn't
affect <sys-code>.
I agree with Andre that redefinition of system-defined functions could
infringe upon the integrity of the system. In the old Chez, one needed
to just type (set! cons 0) to have the whole session come tumbling
down like a house of cards. But then, I don't think the guy who said
"Eternal vigilance is the price of liberty" meant it as an argument
_against_ liberty.
--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice. --Isaac Bashevis Singer
------------------------------------------------------------------------------
------------------------------
Date: 21 Apr 89 01:16:00 GMT
From: centauri!bohica@sun.com (Tom McReynolds)
Subject: Re: where define is legal
Message-Id: <100242@sun.Eng.Sun.COM>
I have a copy of Cscheme from prep.ai.mit.edu. I ran the example
described:
Scheme saved on Monday April 3, 1989 at 7:14:37 PM
Release 6.1.2
Microcode 10.2
Runtime 13.91
SF 3.13
Student 13.3
*** Note: no graphics available in this system. ***
1 ==> (define (foo bool)
(if bool
(define (result) 't)
(define (result) 'f))
(result))
FOO
1 ==> (foo nil)
F
1 ==> (foo 't)
T
Am I missing something?
-Tom
------------------------------
End of Scheme Digest
********************
∂22-Apr-89 1248 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #103
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Apr 89 12:47:42 PDT
Date: 22 APR 89 00:07:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #103
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #103 22 APR 89 00:07:06 EDT
Today's Topics:
where define is legal
Question with binding
where define is legal
Question with binding
where define is legal
where define is legal
Scheme for IBM PC compatible
----------------------------------------------------------------------
Date: 21 Apr 89 02:50:39 GMT
From: emo@iuvax.cs.indiana.edu (Eric Ost)
Subject: Re: where define is legal
Message-Id: <19891@iuvax.cs.indiana.edu>
>> Offhand, the following definition seems bogus:
>>>
>>> (define (foo bool)
>>> (if bool
>>> (define (result) #true)
>>> (define (result) #false))
>>> (result))
>>>
>>> And indeed, when I try to run this in MacScheme, I get an error message.
I suspect you get an unbound global variable error, correct?
What about the following, slightly different definition for "foo"?
(define (foo bool)
(define (result)
(if bool
#t
#f))
(result))
eric
------------------------------
Date: Fri, 21 Apr 89 02:11 EDT
From: Andre van Meulebrouck <vanMeule@ALLEGHENY.SCRC.Symbolics.COM>
Subject: Re: Question with binding
Message-ID: <19890421061138.6.VANMEULE@PERTA.SCRC.Symbolics.COM>
Date: 20 Apr 89 18:49:34 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3131@kalliope.rice.edu>
[. . .]
I agree with Andre that redefinition of system-defined functions could
infringe upon the integrity of the system. In the old Chez, one needed
to just type (set! cons 0) to have the whole session come tumbling
down like a house of cards. But then, I don't think the guy who said
"Eternal vigilance is the price of liberty" meant it as an argument
_against_ liberty.
Okay. All the zeal and arguments shown for allowing the redefinition of car to
garbage sound pretty good. And, I'm NOT religious or dogmatic about not
allowing redefinition. (In fact, I'm religious about NOT being religious.) I
just enjoyed the feature in MacScheme because of all those sleepless nights that
it saved me from lots of potential inadvertent mistakes that could have made
already sleepless nights more sleepless.
Recall also, that MacScheme is a "micro" computer implementation. Perhaps what
might be nice for "PC"s might not be universally acceptable for "large scale"
systems.
I just have one question for anyone that's in favor of redefinition.
Are you saying you want redefinition-with-wild-abandon? I.e. do you NOT want
the system to warn you and ask you: "Are you sure?"? (Admittedly there could be
a hackerish thrill in living dangerously....safety is wimps. :-)
Or, do you want the system to ask you? (Which could be annoying, especially for
loading files.)
Or, do you want the system to warn you by default, unless you set a
global-dont-warn-me-about-redefinitions flag appropriately? (And if the latter,
are you prepared to have zillions of such global variables for similar things in
a BIG MOBY system?)
Just curious (And by NO means intending raging controvery and/or heated
religious debates. If I'm espousing unpopular ideas, well, I derived them from
reading Salmon Rushdie--so he's to blame!)
<Happy trails> =:0)
--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice. --Isaac Bashevis Singer
------------------------------------------------------------------------------
[. . .]
------------------------------
Date: 21 Apr 89 08:22:28 GMT
From: mcvax!kth!draken!tut!pk@uunet.uu.net (Kellom{ki Pertti)
Subject: Re: where define is legal
Message-Id: <PK.89Apr21102228@korppi.tut.fi>
In article <8904201554.AA13117@spt.entity.com> alms@spt.entity.COM (andrew lm shalit) writes:
Offhand, the following definition seems bogus:
(define (foo bool)
(if bool
(define (result) #true)
(define (result) #false))
(result))
And indeed, when I try to run this in MacScheme, I get an error message.
I agree with the semantics, but I couldn't find anything in the R3
description of DEFINE which restricts where it may appear.
See section 5.2. Definitions:
"Definitions are valid in some, but not all, contexts where
expressions are. The are vlid only at the top level of a <program>
and, in some implementations, at the beginning of a <body>. [that is,
the body of a lambda, let, let*, letrec or define expression (from 5.2.2)]"
pertti
--
Pertti Kellom\"aki (TeX format) # pk@tut.fi # Wasting time is
Tampere Univ. of Technology # # an important part
Software Systems Lab # # of living
------------------------------
Date: Fri, 21 Apr 89 11:24 EDT
From: Nick Lewins <munnari!wacsvax.oz.au!nick@uunet.UU.NET>
Subject: Question with binding
Message-ID: <"19890421152425.8.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU>
Just to further the argument about redefining primative functions, TI's PC
Scheme behaves like this:
(define +
(lambda (x y n)
(modulo (+ x y) n)))
(+ 1 2 3) ==> 0
(define blah
(lambda ()
(+ 1 2 3)))
(blah) ==> 6
I realise that + is treated specially, but this seems to be an undesirable
(and inconsistant) way to handle primative function redefinition. What's
more, the values of pcs-integrate-integrables and pcs-integrate-primatives
don't seem to affect this behavior. Comments anyone?
Nick.
--
-------------------
nick@wacsvax.uwa.oz "Through Nambocour, and up the coast,
Dept. of Computer Science the grass is greener, the girls are sweeter,
University of Western Australia I did it all in the last ten summers."
CRAWLEY 6009 - Cold Chisel, "Hound dog"
------------------------------
Date: Fri, 21 Apr 89 10:57:49 EST
From: jar@void.ai.mit.edu (Jonathan Rees)
Message-Id: <8904211557.AA00047@void.ai.mit.edu>
Subject: where define is legal
Reply-To: jar@zurich.ai.mit.edu
Date: 20 Apr 89 15:54:43 EDT (Thu)
From: alms@spt.entity.com (andrew lm shalit)
(define (foo bool)
(if bool
(define (result) #true)
(define (result) #false))
(result))
When I try to run this in MacScheme, I get an error message.
I agree with the semantics, but I couldn't find anything in the R3
description of DEFINE which restricts where it may appear.
There is nothing in section 5 that could allow one to deduce that
definitions are permitted anywhere other than at top level or at the
beginning of a lambda, let, etc. body. And the expression you have
written isn't generated by the grammar of section 7.1, since (define
...) is never an <expression>.
Some implementations do permit DEFINE forms in other places, but those
implementations are extending the language.
------------------------------
Date: 21 Apr 89 07:57:25 GMT
From: chaynes@iuvax.cs.indiana.edu (Chris Haynes)
Subject: Re: where define is legal
Message-Id: <CHAYNES.89Apr21025725@iuvax.cs.indiana.edu>
Offhand, the following definition seems bogus:
(define (foo bool)
(if bool
(define (result) #true)
(define (result) #false))
(result))
And indeed, when I try to run this in MacScheme, I get an error message.
I agree with the semantics, but I couldn't find anything in the R3
description of DEFINE which restricts where it may appear.
Some people from non-scheme backgrounds might think programmatic DEFINEs
perfectly reasonable, so it's probably worth mentioning the restriction
in the language description.
In R4 and the Standard draft, section 5.2 on definitions begins:
Definitions are valid in some, but not all, contexts where expressions
are allowed. They are valid only at the top level of a <program>
and at the beginning of a <body>.
This makes the above example syntactically bogus.
------------------------------
Date: 21 Apr 89 19:02:10 GMT
From: muller@bu-cs.bu.edu (Robert Muller)
Subject: Scheme for IBM PC compatible
Message-Id: <29975@bu-cs.BU.EDU>
I'm looking for an interpreter or compiler for Scheme for an IBM PC.
Does anyone out there know of a reasonably cheap (i.e., free) version?
Thanks.
Bob Muller
------------------------------
End of Scheme Digest
********************
∂22-Apr-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #104
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Apr 89 21:32:36 PDT
Date: 23 APR 89 00:07:21 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #104
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #104 23 APR 89 00:07:21 EDT
Today's Topics:
Question with binding
package question
mailing list
where define is legal
Question with binding
Scheme for IBM PC compatible
----------------------------------------------------------------------
Date: 21 Apr 89 20:04:58 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3140@kalliope.rice.edu>
$From: Andre van Meulebrouck <vanMeule@allegheny.scrc.symbolics.com>
$ From: titan!dorai@rice.edu (Dorai Sitaram)
$ I agree with Andre that redefinition of system-defined functions could
$ infringe upon the integrity of the system. In the old Chez, one needed
$ to just type (set! cons 0) to have the whole session come tumbling
$ down like a house of cards. But then, I don't think the guy who said
$ "Eternal vigilance is the price of liberty" meant it as an argument
$ _against_ liberty.
$
$Okay. All the zeal and arguments shown for allowing the redefinition of car to
$garbage sound pretty good. And, I'm NOT religious or dogmatic about not
$allowing redefinition. (In fact, I'm religious about NOT being religious.) I
$just enjoyed the feature in MacScheme because of all those sleepless nights that
$it saved me from lots of potential inadvertent mistakes that could have made
$already sleepless nights more sleepless.
$
$Recall also, that MacScheme is a "micro" computer implementation. Perhaps what
$might be nice for "PC"s might not be universally acceptable for "large scale"
$systems.
$
$I just have one question for anyone that's in favor of redefinition.
$
$Are you saying you want redefinition-with-wild-abandon? I.e. do you NOT want
$the system to warn you and ask you: "Are you sure?"? (Admittedly there could be
$a hackerish thrill in living dangerously....safety is wimps. :-)
$
$Or, do you want the system to ask you? (Which could be annoying, especially for
$loading files.)
$
$Or, do you want the system to warn you by default, unless you set a
$global-dont-warn-me-about-redefinitions flag appropriately? (And if the latter,
$are you prepared to have zillions of such global variables for similar things in
$a BIG MOBY system?)
$
$Just curious (And by NO means intending raging controvery and/or heated
$religious debates. If I'm espousing unpopular ideas, well, I derived them from
$reading Salmon Rushdie--so he's to blame!)
$
$<Happy trails> =:0)
Your concerns are perfectly legitimate: inadvertent or misguided
redefinition can cause no end of trouble. However, an irreversible
abolition of redefinition is not only aesthetically unpleasing to
those with "hackerish thrills", it is _unnecessary_. "Redefinition
with wild abandon" is not an untam(e)able animal at all. The system
warnings you ask about are also unnecessary. Even for small pc
implementations. Why?
The reason is that you can devise your own security blanket (and sleep
tight ;-}) with the macro system that comes with any Scheme. The
declare-constant and undeclare-constant that I referred to in my
earlier posting are now simple macros. One method would be:
(defmacro (declare-constant x)
`(put 'x 'constant t))
(defmacro (undeclare-constant x)
`(put 'x 'constant nil))
(defmacro (setq x v)
`(if (get 'x 'constant)
(error "hey watch out, salman rushdie is out to set constants!")
(set! x ,v)))
The above is a very simple model (it hardly deserves the term
"hack"!). You can of course make it more watertight by avoiding use of
a global property table (make it local to the un/declare-constant and
setq macros). The use of setq as the new set! can also be avoided, by
lexically capturing the old set! (macro-)transform-function and
replacing it with the modified version. All these are peripheral to
understanding how to get a very satisfactory method of getting safe
"constant" names in a system that provides redefinition.
Anyway, the upshot of all this is that redefinition allows one to get
the best of both worlds, while condemning the system to have immutable
"constants" is an irreversible situation. Which would you choose? :-]
--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice. --Isaac Bashevis Singer
------------------------------------------------------------------------------
------------------------------
Date: 21 Apr 89 13:50:33 GMT
From: mcvax!tuvie!brock@uunet.uu.net (Inst.f.Prakt.Info 1802)
Subject: package question
Message-Id: <684@tuvie>
<I tried to post this already, but I missed>
Hi
I have a question or two to experienced Lisp/Scheme programmers about the
package mechanism.
1.) Are packages an acceptable equivalent to modules in conv. programming lang.?
2.) Do you use them for all of Your code?
3.) Are there any common problems programmers normally have when beginning
using packages?
(perhaps some of you holding courses may answer this)
4.) How do you handle I/O?
5.) Do there exists alternatives to packages. (Well OO-extensions, but are
there also simpler alternatives?)
Please answer directly to me, I'll post a summary to comp.lang.lisp.
Thanks in advance
Ulrich
(ulrich@vip.at UUCP: ...!mcvax!tuvie!vip!ulrich)
------------------------------
Date: 22 Apr 89 03:02:06 GMT
From: mimos!rangkom!napi@uunet.uu.net (Mohd Hanafiah b. Abdullah)
Subject: mailing list
Message-Id: <177@rangkom.MY>
Please include me in the mailing list. Thank you.
------------------------------
Date: 21 Apr 89 18:26:23 GMT
From: killer!pollux!ti-csl!m2!gateley@eddie.mit.edu (John Gateley)
Subject: Re: where define is legal
Message-Id: <75453@ti-csl.csc.ti.com>
In article <8904201554.AA13117@spt.entity.com> alms@spt.entity.COM (andrew lm shalit) writes:
>(define (foo bool)
> (if bool
> (define (result) #true)
> (define (result) #false))
> (result))
From the R↑3S: Section 5.2
"Definitions are valid in some, but not all, contexts where
expressions are allowed. They are valid only at the top level of
a <program> and, in some implementations, at the beginning of
a <body>.
Section 5.2.1 describes top level definitions, and section 5.2.2 describes
internal definitions.
The above code can be rewritten as:
(define result nil) ; dummy value for the variable result.
(define (foo bool)
(if bool
(set! result (lambda () #true))
(set! result (lambda () #false)))
(result))
You can use a local variable for result if you want.
John
gateley@tilde.csc.ti.com
p.s. Hi Eric.
------------------------------
Date: Sat, 22 Apr 89 09:10:29 -0500
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8904221410.AA12294@chamartin.AI.MIT.EDU>
Subject: Re: Question with binding
Reply-To: jinx@zurich.ai.mit.edu
I just have one question for anyone that's in favor of redefinition.
Are you saying you want redefinition-with-wild-abandon? I.e. do
you NOT want the system to warn you and ask you: "Are you sure?"?
(Admittedly there could be a hackerish thrill in living
dangerously....safety is wimps. :-)
Or, do you want the system to ask you? (Which could be annoying,
especially for loading files.)
Or, do you want the system to warn you by default, unless you set
a global-dont-warn-me-about-redefinitions flag appropriately?
(And if the latter, are you prepared to have zillions of such
global variables for similar things in a BIG MOBY system?)
There are other possibilities besides global switches and annoying
warnings.
In MIT Scheme and T there are first class environments, called locales
in T, where incremental (top level) definition is legal. Definition
in these environments affects only them and their "children", but
affects no other first class environments. Systems can be structured
in such a way that defining in the "user initial" environment does not
affect system code at all, but affects all the user code "loaded"
there. Thus the user can get whatever definition of CAR s/he wants
while the system continues using whatever else it wants.
If you want to "redefine" something for the system as well, you have
to do a little more work, since you first have to find what binding
(or bindings) affect the system, and then assign it (them) to the
desired value. Since doing this unadvertently is very unlikely, there
is no need for warnings or switches.
I find that this scenario provides a reasonable degree of system
security against unintentional damage, while providing significant
power to knowledgeable users.
Unfortunately R3RS does not provide any notion of multiple first class
environments or top levels, so it is inconvenient to write an R3RS
portable system that has the above behavior.
------------------------------
Date: 22 Apr 89 02:37:10 GMT
From: mailrus!wasatch!cs.utexas.edu!natinst!bigtex!nueces!chari@ames.arpa (Chris Whatley)
Subject: Re: Scheme for IBM PC compatible
Message-Id: <270@nueces.UUCP>
In article <29975@bu-cs.BU.EDU>, muller@bu-cs.BU.EDU (Robert Muller) writes:
> I'm looking for an interpreter or compiler for Scheme for an IBM PC.
> Does anyone out there know of a reasonably cheap (i.e., free) version?
I'm posting this since it might be of general interest.
Xscheme, the Scheme equivalent of Xlisp is available from
tut.cis.ohio-state.edu by ftp and from osu-cis.uucp by
uucp. It is /pub/Xscheme.tar on tut. It make properly on
pc's and Unixes and is writeen in C.
Chris
--
Chris Whatley | "dish... crab fingers...
!bigtex!nueces!chari@cs.utexas.edu | dish of crab fingers..."
chari@walt.cc.utexas.edu |
1607 Nueces,Austin TX 78723 - 512/453-4238 | (that'll teach you)
------------------------------
End of Scheme Digest
********************
∂23-Apr-89 0150 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Why the interest
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Apr 89 01:50:11 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Apr 89 04:44:29 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA12703@chamartin.AI.MIT.EDU>; Sun, 23 Apr 89 03:44:39 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24196; Sun, 23 Apr 89 01:44:08 -0700
Date: Sun, 23 Apr 89 01:44:08 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904230844.AA24196@polya.Stanford.EDU>
To: rrrs-authors@chamartin.AI.MIT.EDU
Subject: Why the interest
Somone sent me mail asking what has suddenly sparked my interest in
Scheme, and if I was doing an implementation.
The answer is yes, I am doing an implementation, partly to understand
the issues in implementing a language with first-class functions and
continuations, and partly because having looked at it from a number of
angles, I find Scheme a marvelously well-executed and thought-out
language, and would like to base a book I am writing on it.
Most of the "difficulties" I see in the current language, given my
interests, have to do with the ability to express cues to the
implementation for efficient compilation, and I am particularly
interested in thinking about ways to express these things that do not
jeopardize the mathematical soundness of the language.
And there you have it...
Jon
∂23-Apr-89 0201 @MC.LCS.MIT.EDU:shap@polya.Stanford.EDU Rebinding of standard functions
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Apr 89 02:01:25 PDT
Received: from chamartin.AI.MIT.EDU (TCP 2212600253) by MC.LCS.MIT.EDU 23 Apr 89 04:47:37 EDT
Received: from Polya.Stanford.EDU by chamartin.AI.MIT.EDU (5.61/1.2) with SMTP
id <AA12709@chamartin.AI.MIT.EDU>; Sun, 23 Apr 89 03:47:31 -0500
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24252; Sun, 23 Apr 89 01:46:58 -0700
Date: Sun, 23 Apr 89 01:46:58 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8904230846.AA24252@polya.Stanford.EDU>
To: rrrs-authors@chamartin.AI.MIT.EDU
Subject: Rebinding of standard functions
Well, having been responsible for kicking this off, let's see if I can
divert the deluge. I apologize for the furor my ignorance has loosed...
There is merit on both sides of the arguments for and against
redefining standard functions. On the FOR side, people correctly
point out that it is extremely useful to be able to extend the
existing primitives. On the AGAINST side, people correctly point out
that this prevents efficient code generation and leads to hard-to-find
errors.
While the efficiency and [human-]correctness arguments have no bearing
on the mathematical soundness of the language, I don't think it
inappropriate to try and address these concerns if it can be done
without jeopardizing that soundness.
Some will undoubtedly point out that such hacks as
(letrec ((+ `,+)
(- `,-))
..body..)
already address the need. While this is true from a formal
standpoint, it renders debugging difficult and substantially detracts
from the readability of the code.
Perhaps the time has come, in the interest of portability, for an
attempt to be made to resolve this issue.
First, is this appropriate, and if so, what is the mechanism used to
accomplish this sort of thing in the scheme community?
I would volunteer to think about this a while and propose a solution
[AFTER reading through the archives...], but I wonder if in my
ignorance I won't stir up more problems than I resolve.
Any reactions?
Jon Shapiro
∂23-Apr-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #105
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Apr 89 21:36:46 PDT
Date: 24 APR 89 00:08:48 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #105
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #105 24 APR 89 00:08:48 EDT
Today's Topics:
Scheme for IBM PC compatible
Question with binding
----------------------------------------------------------------------
Date: 23 Apr 89 01:16:52 GMT
From: leverich@rand-unix.arpa (Brian Leverich)
Subject: Re: Scheme for IBM PC compatible
Message-Id: <1953@randvax.UUCP>
In article <29975@bu-cs.BU.EDU> muller@bu-cs.BU.EDU (Robert Muller) writes:
>I'm looking for an interpreter or compiler for Scheme for an IBM PC.
You want PC-Scheme from Texas Instruments. Retail from TI in Dallas is
about $95, and there are substantial educational discounts.
TI's implementation is very fast, has gobs of good features (including
understanding '87 chips, expanded and extended memory, etc.), suffers only a
handful of bugs, and is wonderfully documented.
Unless you're _really_ short on cash, it's not worth messing with anything
else. Good luck.
--
"Simulate it in ROSS"
Brian Leverich | U.S. Snail: 1700 Main St.
ARPAnet: leverich@rand-unix | Santa Monica, CA 90406
UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769
------------------------------
Date: 23 Apr 89 19:31:51 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: Question with binding
Message-Id: <3153@kalliope.rice.edu>
In article <3140@kalliope.rice.edu> I wrote:
$The reason is that you can devise your own security blanket (and sleep
$tight ;-}) with the macro system that comes with any Scheme. The
$declare-constant and undeclare-constant that I referred to in my
$earlier posting are now simple macros. One method would be:
$
$(defmacro (declare-constant x)
$ `(put 'x 'constant t))
$
$(defmacro (undeclare-constant x)
$ `(put 'x 'constant nil))
$
$(defmacro (setq x v)
$ `(if (get 'x 'constant)
$ (error "hey watch out, salman rushdie is out to set constants!")
$ (set! x ,v)))
All the x's above should have commas before them. I guess the constant
shuttling between the new extend-syntax (which doesn't use the
backquote system) and the old def*macro (which does) has taken its
toll.
--dorai
------------------------------------------------------------------------------
We must believe in free will. We have no choice. --Isaac Bashevis Singer
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂24-Apr-89 2130 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #106
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Apr 89 21:30:25 PDT
Date: 25 APR 89 00:09:36 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #106
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #106 25 APR 89 00:09:36 EDT
Today's Topics:
(define (foo bool... and redefinition of sys funcs
NeWS interface for CL and Scheme
macro-expansions
----------------------------------------------------------------------
Date: Mon, 24 Apr 89 13:35 GMT
From: Ian Murphy <CBWP8008%IRUCCVAX.UCC.IE@mitvma.mit.edu>
Subject: (define (foo bool... and redefinition of sys funcs
>>>
>>> (define (foo bool)
>>> (if bool
>>> (define (result) #true)
>>> (define (result) #false))
>>> (result))
>>>
The way i'd read this is:
If bool is true then define the procedure called 'result' as the value #true,
which obviously doesn't make sense, and then return the result of calling the
procedure 'result' which *should* be impossible as it's a value, not a
procedure.
Surely defining it like this is better
(define (foo bool)
(if bool
(define result #true)
(define result #false))
result)
Is this the correct way to read scheme, or am I mistaken(the above works fine
in xscheme).
Regarding the redefinition of system functions, I'd prefer to be able to
redefine them at will, BUT I think everybody wants control over their own
programs, but also without altering the workings of already defined procedures.
I think it would be best if compiled functions couldn't be altered by
redefining a function (i.e like cschemes fasloaded functions), this will allow
you to redefine, say, the display function so that it sends its output to a
file instead, for *your* program and your program only and not all the older
functions which have been, in effect, added to your version of the language.
Does this seem reasonable?
btw do many other people work with xscheme at all, its a bit limited by the pc
memory constraints but apart from that i find it to be excellent as it's so
quick to try things out in.
+-----------------------------------------------------------------------------+
|Ian Murphy | Internet : IAN@VAX1.UCC.IE |
|Dept. Computer Science | ARPA : IAN@IRUCCVAX.BITNET |
|University College Cork, | janet : EARN%IRL.HEA.UCC.IRUCCVAX::IAN |
|Ireland. | Voice : "IAN!!!" |
+-----------------------------------------------------------------------------+
------------------------------
Date: 24 Apr 89 19:11:56 GMT
From: mcvax!kth!draken!tut!jh@uunet.uu.net (Hein{nen Juha)
Subject: NeWS interface for CL and Scheme
Message-Id: <JH.89Apr24211156@korppi.tut.fi>
In article <1086@cantuar.UUCP> greg@cantuar.UUCP (G. Ewing) writes:
Bob Sutterfield (bob@allosaur.cis.ohio-state.edu) writes:
>What interpretive language would you like to use to interact with your
>windows?
Scheme.
This may not be what you have in mind, but we have written a program
called lps that takes as input a cps source file and produces Scheme
or CL interface procedures that allow NeWS procedures to be called
from Scheme or CL in the same way as from C.
Our lps currently supports Allegro CL and pseudoscheme (by Jonathan
Rees) that runs on top of it. Adding support for other CLs or Schemes
that have a foreign function interface should be quite
straightforward.
If there is enough interest we might make the package available for
anonymous ftp although no documentation has been produced yet.
--
-- Juha Heinanen, Tampere Univ. of Technology, Finland
jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
------------------------------
Date: Mon, 24 Apr 89 13:45:20 edt
From: Roland Zito-wolf <rjz%cs.brandeis.edu@RELAY.CS.NET>
Subject: macro-expansions
I am looking for esxamples of creative/complex macro usage in
LISP or SCHEME systems, with which to evaluate the
differences in various macro proposals for
SCHEME (expansion-passing style, syntactic closures,
and hygienic macro expansion).
Pointers and examples are welcome. Reply to:
Roland J. Zito-wolf (aka Roy)
Dept. of Computer Science, Ford Hall Room 121
Brandeis University
Waltham, Mass 02254-9110
617-736-2728
RJZ@CS.BRANDEIS.EDU or
RJZ%CS.BRANDEIS.EDU@RELAY.CS.NET
------------------------------
End of Scheme Digest
********************
∂25-Apr-89 2156 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #107
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 25 Apr 89 21:56:18 PDT
Date: 26 APR 89 00:10:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #107
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #107 26 APR 89 00:10:13 EDT
Today's Topics:
Scheme Digest #105
NeWS interface for CL and Scheme
Scheme Digest #106
Scheme Digest #106
----------------------------------------------------------------------
Date: Tue, 25 Apr 89 11:17 GMT
From: Ian Murphy <CBWP8008%IRUCCVAX.UCC.IE@mitvma.mit.edu>
Subject: RE: Scheme Digest #105
oops, made a mistake with my interpretation of the program yesterday,
I thought that
(define (foo bool)
(if bool
(define (result) #t)
(define (result) #f))
(result))
meant define the procedure result as the value #t/#f. My mistake was in
thinking #t/#f were values which couldn't evaluate (procedural thinking), in
fact (define (result) #t) is merely syntactic sugar for
(define result (lambda() #t))
Which, as most of you know only too well,is the lambda func which
evaluates '#t', which of course returns #t.
stupid mistake, too many years of pascal warps your way of thinking :-)
+-----------------------------------------------------------------------------+
|Ian Murphy (↑v↑) | Internet : IAN@VAX1.UCC.IE |
|Dept. Computer Science | ARPA : IAN@IRUCCVAX.BITNET |
|University College Cork, | janet : EARN%IRL.HEA.UCC.IRUCCVAX::IAN |
|Ireland. | Voice : "IAN!!!" |
+-----------------------------------------------------------------------------+
------------------------------
Date: 25 Apr 89 03:25:00 GMT
From: stung@iuvax.cs.indiana.edu
Subject: Re: NeWS interface for CL and Scheme
Message-Id: <56700004@iuvax>
I am interested in your lps program.
I would appreciate if you can make it available through anonymous ftp.
Simon Tung
stung@iuvax.cs.indiana.edu
------------------------------
Date: Tue, 25 Apr 89 12:11 EDT
From: Mark A. Sheldon <death@ZERMATT.LCS.MIT.EDU>
Subject: Scheme Digest #106
Message-ID: <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>
One crucial problem with DEFINEs placed willy-nilly in programs arises from
DEFINE's being an environment mutator. Consider this modification to our
standing example:
(define (foo bool)
(if bool
(define (result) #t)
'do-nothing
(result)))
Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
Restricting DEFINEs to beginnings of blocks allows us to think of a block
of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
that don't implement these blocks as a LETREC). If Scheme is a statically
scoped language, then this sort of DEFINE is anathema. If Scheme is to
support dynamic scoping, then I think FLUID-LET is cleaner because I don't
have to think about environment mutation.
Top level DEFINEs don't bother me so much because I think of the top level
as a debugger.
-Mark A. Sheldon
------------------------------
Date: 25 Apr 89 16:11:00 GMT
From: ZERMATT.LCS.MIT.EDU!death@bloom-beacon.mit.edu (Mark A. Sheldon)
Subject: Scheme Digest #106
Message-Id: <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>
One crucial problem with DEFINEs placed willy-nilly in programs arises from
DEFINE's being an environment mutator. Consider this modification to our
standing example:
(define (foo bool)
(if bool
(define (result) #t)
'do-nothing
(result)))
Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
Restricting DEFINEs to beginnings of blocks allows us to think of a block
of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
that don't implement these blocks as a LETREC). If Scheme is a statically
scoped language, then this sort of DEFINE is anathema. If Scheme is to
support dynamic scoping, then I think FLUID-LET is cleaner because I don't
have to think about environment mutation.
Top level DEFINEs don't bother me so much because I think of the top level
as a debugger.
-Mark A. Sheldon
------------------------------
End of Scheme Digest
********************
∂29-Apr-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #108
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Apr 89 21:40:15 PDT
Date: 30 APR 89 00:12:01 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #108
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #108 30 APR 89 00:12:01 EDT
Today's Topics:
Add to your copy of biblio.
----------------------------------------------------------------------
Date: 28 Apr 89 13:47:35 GMT
From: mnetor!utzoo!yunexus!oz@uunet.uu.net (Ozan Yigit)
Subject: Add to your copy of biblio.
Message-Id: <1729@yunexus.UUCP>
%A Steven R. Vegdahl
%A Uwe F. Pleban
%T The Runtime Environment for Screme, a Scheme Implementation
on the 88000
%J Proceedings of the Third International Conference on Architectural
Support for Programming Languages and Operating Systems
%C Boston, Mass.
%D April 1989
%P 172-182
--
oz
--
use the source, luke !! Usenet: oz@nexus.yorku.ca
uh... we forgot to tell you... ......!uunet!utai!yunexus!oz
it is unintelligible, but hey, you Bitnet: oz@[yulibra|yuyetti]
got it, for free (!). Phonet: +1 416 736-5257x3976
------------------------------
End of Scheme Digest
********************
∂30-Apr-89 2149 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #109
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 30 Apr 89 21:49:31 PDT
Date: 1 MAY 89 00:12:50 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #109
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #109 1 MAY 89 00:12:50 EDT
Today's Topics:
semantics of DEFINE
----------------------------------------------------------------------
Date: 30 Apr 89 20:39:25 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: semantics of DEFINE
Message-Id: <59021@yale-celray.yale.UUCP>
In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT
(Mark A. Sheldon) writes:
>Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
>Restricting DEFINEs to beginnings of blocks allows us to think of a block
>of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
>that don't implement these blocks as a LETREC). If Scheme is a statically
>scoped language, then this sort of DEFINE is anathema. If Scheme is to
>support dynamic scoping, then I think FLUID-LET is cleaner because I don't
>have to think about environment mutation.
A while ago I posted the suggestion that non-top-level DEFINEs do the same
thing as top-level DEFINEs, ie, side effect the top level. This allows
top-level definitions to scope over lexically bound variables, which cannot be
done in any other way (as of now a single procedure can scope over variables,
but such variables cannot be shared by procedures); having non-top-level
DEFINEs side effect the local lexical environment is the same as LETREC
(perhaps nested) and thus doesn't add any functionality. This interpretation
is the one adopted by the current version of T (although it's not an explicit
decision on the part of the T designers) and I believe is the interpretation
used by most LISP dialects. The ability to have global procedures scope over
variables reduces the number of unneeded global variables, allows hiding of
internal representations, and (almost definitely) adds alot to the efficiency
of accessing these variables.
Most of the responses that I got said either like "well, Abelson and Sussman
used the 'local' interpretation, so we really should stick to it" or "well,
local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does
anyone have other (theoretical or functional) reasons for this decision??
Bruce Krulwich
------------------------------
End of Scheme Digest
********************
∂01-May-89 2142 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #110
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 1 May 89 21:42:23 PDT
Date: 2 MAY 89 00:13:38 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #110
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #110 2 MAY 89 00:13:38 EDT
Today's Topics:
semantics of DEFINE
semantics of DEFINE
scoops sources
----------------------------------------------------------------------
Date: Mon, 1 May 89 08:36:20 PDT
From: mkatz@sesame.Stanford.EDU (Morris Katz)
Message-Id: <8905011536.AA12423@sesame.Stanford.EDU>
Subject: semantics of DEFINE
Date: 30 Apr 89 20:39:25 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT
(Mark A. Sheldon) writes:
>Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
>Restricting DEFINEs to beginnings of blocks allows us to think of a block
>of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
>that don't implement these blocks as a LETREC). If Scheme is a statically
>scoped language, then this sort of DEFINE is anathema. If Scheme is to
>support dynamic scoping, then I think FLUID-LET is cleaner because I don't
>have to think about environment mutation.
A while ago I posted the suggestion that non-top-level DEFINEs do the same
thing as top-level DEFINEs, ie, side effect the top level. This allows
top-level definitions to scope over lexically bound variables, which cannot be
done in any other way (as of now a single procedure can scope over variables,
but such variables cannot be shared by procedures); having non-top-level
DEFINEs side effect the local lexical environment is the same as LETREC
(perhaps nested) and thus doesn't add any functionality. This interpretation
is the one adopted by the current version of T (although it's not an explicit
decision on the part of the T designers) and I believe is the interpretation
used by most LISP dialects. The ability to have global procedures scope over
variables reduces the number of unneeded global variables, allows hiding of
internal representations, and (almost definitely) adds alot to the efficiency
of accessing these variables.
Most of the responses that I got said either like "well, Abelson and Sussman
used the 'local' interpretation, so we really should stick to it" or "well,
local non-top-level DEFINEs add fewer parentheses than nesting LETRECs." Does
anyone have other (theoretical or functional) reasons for this decision??
Bruce Krulwich
Some systems may not have the concept of A top level environment, so this
proposal restricts Scheme in an important way that should be recognized. If
one has a system that has first-class environments, then a top level
environment may not exist or may be a dynamic, rather than a static, property
of a piece of executing code. I would far prefer to see local defined removed
from Scheme than have them given the proposed semantics.
Morry Katz
katz@polya.stanford.edu
------------------------------
Subject: semantics of DEFINE
Message-Id: <8905011321.AA03861@spt.entity.com>
Date: 1 May 89 13:21:40 EDT (Mon)
From: alms@spt.entity.com (andrew lm shalit)
Date: 30 Apr 89 20:39:25 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT
(Mark A. Sheldon) writes:
. . .
A while ago I posted the suggestion that non-top-level DEFINEs do
the same thing as top-level DEFINEs, ie, side effect the top level.
. . .
Most of the responses that I got said either like "well, Abelson
and Sussman used the 'local' interpretation, so we really should
stick to it" or "well, local non-top-level DEFINEs add fewer
parentheses than nesting LETRECs." Does anyone have other
(theoretical or functional) reasons for this decision??
How about a general aversion to the notion of "top-level environment"? When
you introduce first-class environments, and programming tools for using
them, the notion of "top-level" starts to change. Just how it changes
depends on how the environments and programming tools are designed.
Do you have a problem with the following, aside from the general aversion
to SET! ?
(define frob nil)
(let ((x (mumble1))
(y (mumble2)))
(dset! frob (lambda (z)
(list x y z))))
------------------------------
Date: Tue, 02 May 89 00:30:17 MEZ
From: Gerhard Eckel <V4110DAA%AWIUNI11.BITNET@mitvma.mit.edu>
Subject: scoops sources
Hello,
is there anybody in the SCHEME community who could *mail* to me
(unfortunately I don't have access on ftp) the source code of SCOOPS as it is
running on PCScheme? I received the CSCHEME version of SCOOPS via this list
recently but I use PCScheme and I don't want to convert it back.
Unfortunately PCScheme comes without the source code.
Thank you very much in advance!
+------------------------------+---------------------------------------------+
: Gerhard ECKEL c/o Austrian Academy of Sciences, Dept. Sound :
: Hernalser Haupstrasse 164/17 : Liebiggasse 5, A-1010 Vienna, AUSTRIA :
: A-1170 Vienna, AUSTRIA : Tel.: +43 222 43 00 27 30 :
: Tel.: +43 222 46 10 404 : E-mail: V4110DAA@AWIUNI11.BITNET :
+------------------------------+---------------------------------------------+
------------------------------
End of Scheme Digest
********************
∂02-May-89 2207 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #111
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 2 May 89 22:06:57 PDT
Date: 3 MAY 89 00:14:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #111
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #111 3 MAY 89 00:14:16 EDT
Today's Topics:
SoftEng or CS Graduate Program Search
Cscheme via ftp now?
semantics of DEFINE
NeWS interface for CL and Scheme available
PC-Scheme SCOOPS source
----------------------------------------------------------------------
Date: 1 May 89 23:09:58 GMT
From: unmvax!ncar!umigw!umiami!slores@bloom-beacon.mit.edu (Stanislaw L. Olejniczak)
Subject: SoftEng or CS Graduate Program Search
Message-Id: <610@umiami.miami.edu>
I would very much appreciate, on my and many other prospective
graduate students' behalf, your comments on graduate software
engineering programs. I have been reading brochures from various
schools, collected various rankings and read a couple books about
graduate programs in software engineering or computer science.
What I am asking for in this message are personal opinions,
observations and comments.
Which school and department do you think is a good place to study
Software Engineering or Computer Science with Software
Engineering emphasis? Why do you think a particular department
is a good place to spend a couple years getting a Master's, and
later, a Ph.D.? What are its strength? What are its weaknesses?
Where do the graduates go? What kind of research is being
conducted? Who (if not yourself) is a good person to contact
there? What are other comments you would like to make that I
have not asked about? All comments you will send will be
appreciated.
Let me apologize for posting this message again, and for posting
it this time to numerous newsgroups. When I have initially
posted this request, I have offered to send summaries to any
interested person. I have received several dozens of requests
for the summaries. I have received a small handful of replies on
the subject. After waiting now a considerable, for Newsnet,
time, I have decided I did not post it to the right groups; or
all the right people did not get to see this. Thus, this second,
and final, attempt.
To those who had previously replied, my many thanks. For those
who had requested or will request summaries, I will post them to
you after I feel reasonably certain I have received all replies
to this second posting. To those who will reply, many, many
thanks, from me and from the numerous prospective graduate
students who will embark on more successful graduate studies
thanks to the time you take off your busy schedules to advise.
P.S. If you are so kind as to send your comments but would NOT
want be identified in the summary, please let me know.
--
----
Stan Olejniczak Internet: slores@umiami.miami.edu
University of Miami UUCP: {uunet!gould}!umbio!solejni
Miami, Florida, USA BITNET: SLORES@UMIAMI
Voice: (305)-547-6571 FAX:305-547-6412
My opinions cannot possibly represent the views of anyone else!
------------------------------
Date: 1 May 89 17:47:29 GMT
From: bunny!cayman!art@husc6.harvard.edu (Art Mellor)
Subject: Cscheme via ftp now?
Message-Id: <2771@cayman.COM>
Now that prep is gone, where can one ftp Cscheme from?
art@cayman.com
------------------------------
Date: 2 May 89 14:06:32 GMT
From: Ram-Ashwin@yale-zoo.arpa (Ashwin Ram)
Subject: Re: semantics of DEFINE
Message-Id: <59114@yale-celray.yale.UUCP>
In article <8905011321.AA03861@spt.entity.com>, alms@spt.entity.COM (andrew lm shalit) writes:
> Date: 30 Apr 89 20:39:25 GMT
> From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
>
> A while ago I posted the suggestion that non-top-level DEFINEs do
> the same thing as top-level DEFINEs, ie, side effect the top level.
> . . .
> Most of the responses that I got said either like "well, Abelson
> and Sussman used the 'local' interpretation, so we really should
> stick to it" or "well, local non-top-level DEFINEs add fewer
> parentheses than nesting LETRECs." Does anyone have other
> (theoretical or functional) reasons for this decision??
>
> How about a general aversion to the notion of "top-level environment"? When
> you introduce first-class environments, and programming tools for using
> them, the notion of "top-level" starts to change. Just how it changes
> depends on how the environments and programming tools are designed.
This is a good argument against DEFINE in general, not against DEFINEs within
LETs in particular. A top-level DEFINE always assumes that you want to
side-effect the "top-level environment". What you're really saying is that
DEFINE should take an extra argument, which would explicitly specify the
environment in which the definition should take place.
T does provide such a function, called *DEFINE. DEFINE is merely a
convenient syntax for doing a *DEFINE in the environment that the startup
REPL works in, called USER-ENV. The REPL-ENV can be changed as desired.
To get back to the original point, it seems perfectly reasonable to allow
*DEFINEs to be nested within LETs, which would create a definition in the
environment (which is explicitly specified as an argument to the *DEFINE).
The definition is evaluated (and therefore closed) within the lexical
environment of the LET, as any other form would be.
Given that DEFINE is merely a convenient syntax for *DEFINE in the REPL-ENV,
it seems consistent to let a DEFINE with a LET be a convenient syntax for a
*DEFINE within that LET with the REPL-ENV explicitly specified as the
environment for the definition.
-- Ashwin.
------------------------------
Date: 2 May 89 08:15:48 GMT
From: mcvax!kth!draken!tut!jh@uunet.uu.net (Hein{nen Juha)
Subject: NeWS interface for CL and Scheme available
Message-Id: <JH.89May2101548@tikka.tut.fi>
A software package that takes as input a cps source file and produces
Scheme or CL interface procedures that allow NeWS procedures to be
called from Scheme or CL in the same way as from C is now available
for anonymous ftp from tumtum.cs.umd.edu (128.8.128.49) under the name
lps.tar.Z.
Our package currently supports Allegro CL and pseudoscheme (by
Jonathan Rees) that runs on top of it. Adding support for other CLs
or Schemes that have a foreign function interface should be quite
straightforward.
--
-- Juha Heinanen, Tampere Univ. of Technology, Finland
jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)
------------------------------
Date: 2 May 89 21:19:42 GMT
From: mailrus!jarvis.csri.toronto.edu!ephemeral.ai.toronto.edu!bradb@ohio-state.arpa (Brad Brown)
Subject: PC-Scheme SCOOPS source
Message-Id: <89May2.171945edt.10773@ephemeral.ai.toronto.edu>
Is there anyone out there who can tell me how to get the SCOOPS sources
for PC-SCHEME? I can do ftp or mail...
BTW, I'm interested in implementing my own OO shell for Scheme (for
playing around and general interest, not to compete with SCOOPS :-)
and I'm very curious about how to provide access to instance and
class variables. I'd like to be able to have instance and class
variables in their own environments, and be able to write methods
that access the variables (by name) in the proper environment.
I'm having a lot of trouble getting methods that can access the
variables in the proper environement. Does anyone have any tips?
(I'm not an expert Scheme user and working with environments is
very new (and confusing) to me...)
Thanks,
(-: Brad Brown :-)
bradb@ai.toronto.edu
------------------------------
End of Scheme Digest
********************
∂03-May-89 2136 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #112
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 3 May 89 21:36:29 PDT
Date: 4 MAY 89 00:00:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #112
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #112 4 MAY 89 00:00:30 EDT
Today's Topics:
Scheme Digest #111
semantics of DEFINE
Common Lisp on Scheme?
Cscheme via ftp now?
top level definitions
Common Lisp on Scheme?
----------------------------------------------------------------------
Date: Wed, 3 May 89 04:50:30 -0400
From: jinx@chamartin.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8905030850.AA21221@chamartin.AI.MIT.EDU>
Subject: Scheme Digest #111
Reply-To: jinx@zurich.ai.mit.edu
In article <8905011321.AA03861@spt.entity.com>, alms@spt.entity.COM (andrew lm shalit) writes:
> Date: 30 Apr 89 20:39:25 GMT
> From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
>
> A while ago I posted the suggestion that non-top-level DEFINEs do
> the same thing as top-level DEFINEs, ie, side effect the top level.
> . . .
> Most of the responses that I got said either like "well, Abelson
> and Sussman used the 'local' interpretation, so we really should
> stick to it" or "well, local non-top-level DEFINEs add fewer
> parentheses than nesting LETRECs." Does anyone have other
> (theoretical or functional) reasons for this decision??
>
> How about a general aversion to the notion of "top-level environment"? When
> you introduce first-class environments, and programming tools for using
> them, the notion of "top-level" starts to change. Just how it changes
> depends on how the environments and programming tools are designed.
This is a good argument against DEFINE in general, not against DEFINEs within
LETs in particular. A top-level DEFINE always assumes that you want to
side-effect the "top-level environment". What you're really saying is that
DEFINE should take an extra argument, which would explicitly specify the
environment in which the definition should take place.
The side effect in top level DEFINE is a debugging utility and purely
a consequence of interactive development systems. There is a static
way to think about top level DEFINE that eliminates this side effect:
Assume that instead of having a system with a read eval print loop, a
loader, and DEFINE modifying the read-eval-print environment or
environment of loading, we have a static compiler which reads all
modules together and then wraps a single LET around the concatenation
of all of them. Top level DEFINE now has consistent semantics with
internal DEFINE, since the LET with DEFINEs can be rewritten as a
LETREC, and there is no side effect of environments.
T does provide such a function, called *DEFINE. DEFINE is merely a
convenient syntax for doing a *DEFINE in the environment that the startup
REPL works in, called USER-ENV. The REPL-ENV can be changed as desired.
I don't think this is quite right. I believe that top level DEFINE in
T affects the loading environment, not the REPL environment. They are
the same if you give load only a file name argument. This is what top
level DEFINE does in MIT Scheme as well. You can explain the meaning
of top level DEFINE by postulating a new special form, called
THE-ENVIRONMENT, which returns the evaluation environment of the form.
Top level DEFINE would then expand into
(*DEFINE (THE-ENVIRONMENT) '<name> <value>)
To get back to the original point, it seems perfectly reasonable to allow
*DEFINEs to be nested within LETs, which would create a definition in the
environment (which is explicitly specified as an argument to the *DEFINE).
The definition is evaluated (and therefore closed) within the lexical
environment of the LET, as any other form would be.
It is perfectly reasonable, but has undesirable consequences when used
pervasively. We (at MIT) found that this "unsrestricted export" style
resulted in wired-in code, namely code that knew too much about the
shape of the environment about where it would be loaded, and could not
easily be reused.
Given that DEFINE is merely a convenient syntax for *DEFINE in the REPL-ENV,
it seems consistent to let a DEFINE with a LET be a convenient syntax for a
*DEFINE within that LET with the REPL-ENV explicitly specified as the
environment for the definition.
Unfortunately your interpretation is not correct. However, we can
make the interpretation that I have suggested above consistent merely
by stipulating that (THE-ENVIRONMENT) should "work" in all binding
contours, not merely top level environments. DEFINE would now expand
consistently (both top level and internal) as suggested above.
Using THE-ENVIRONMENT consistenly explains the behavior of all DEFINEs
as long as you restrict your internal definitions to valid LETREC
internal bindings and ignore CWCC, which also presents problems for
LETREC.
Local internal DEFINEs came from a variety of linguistic and
functional criteria in the design of MIT Scheme. The main linguistic
argument is that the notion of a top level is strange, and
distingushing it from internal levels is even stranger. We can get
rid of this distinction in two different ways, each accomplished by
one of the models suggested above: The global static compiler model
makes top level (and its definitions) behave exactly like the body of
a LET (and its definitions), but does not allow for interactive
development. Using THE-ENVIRONMENT makes internal contours (and
definitions therein) behave exactly like top level (with its
definitions), but presents some implementation and semantics problems.
Your suggestion for DEFINE forces the notion of top level or read eval
print loop into the language, and I think that would be a mistake. I
consider read eval print loops and "top levels" to be an environment
design issue, not something to be specified in the language.
------------------------------
Date: Wed, 03 May 89 10:33:55 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: semantics of DEFINE
Message-ID: <890503-103409-9762@Xerox>
Too many people are referring to DEFINE as a form that ``side-effects the
top-level environment'' for me to keep out of the fray. In the current
(unreleased) draft of the Scheme specification, R↑(3.95)RS, the following
definitions appear (my wording):
-- A program is a mixed sequence of definitions and expressions.
-- The meaning of a program P is the same that that of the following
expression:
((lambda (I*) P') <undefined> ...)
where I* is the set of variables defined in P (i.e., appearing as the CADR
of a DEFINE form), P' is the sequence of expressions obtained by replacing
each definition in P with the corresponding assignment, and <undefined> is
an expression producing some useless value.
More informally, to execute a program, you wrap it in a big LET binding all
of the defined variables to useless values, change the DEFINEs to SET!s,
and evaluate that expression.
Note, please: no mutation of any environment takes place.
I believe that too many people base their understanding of the semantics of
Scheme on a read-eval-print loop model or on the low-level details of
particular (or perhaps all) implementations. It seems to me irrelevant
that I might use side-effects to resolve the separate compilation (or just
separate loading) of files of code with the semantics given above. The
semantics of DEFINE, and therefore the most accurate way to conceptualize
its meaning, has no mention of mutation.
Of course, this little diatribe has no direct bearing on the meaning of
internal DEFINEs. Personally, I'd rather they had the same meaning (as
given above) as top-level ones. The meaning in terms of LETREC has always
struck me as gratuitously incompatible, and frequently inconvenient as
well. If you're going to use the same name, you should give it the same
semantics...
Pavel
------------------------------
Date: Wed, 3 May 89 14:23:51 -0700
From: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Message-Id: <8905032123.AA18408@polya.Stanford.EDU>
Subject: Common Lisp on Scheme?
What with the Scheme implementation that is built on Common Lisp, it
occurs to me to ask if anyone has implemented a Common Lisp on Scheme?
Jon
------------------------------
Date: 3 May 89 02:33:26 GMT
From: sun-barr!cs.utexas.edu!milano!bigtex!nueces!chari@ames.arpa (Chris Whatley)
Subject: Re: Cscheme via ftp now?
Message-Id: <285@nueces.UUCP>
In article <2771@cayman.COM>, art@cayman.COM (Art Mellor) writes:
> Now that prep is gone, where can one ftp Cscheme from?
Try tut.cis.ohio-state.edu. (is there an echo in here?)
Chris
--
Chris Whatley | "Thank you..
!bigtex!nueces!chari@cs.utexas.edu | Ah.. Thank me!"
chari@walt.cc.utexas.edu | --Data
1607 Nueces,Austin TX 78723 - 512/453-4238 |
------------------------------
Date: 3 May 89 16:17:50 GMT
From: polya!max@labrea.stanford.edu (Max Hailperin)
Subject: top level definitions
Message-Id: <8912@polya.Stanford.EDU>
I like the wrap-it-all-with-a-let semantics for top-level definitions.
However, note that this is not in keeping with R3RS, in that it disallows
such programs as
(define pi 3.14159)
(define radius 10)
(define circumference (* 2 pi radius))
circumference
[Abelson and Sussman, p. 8], which would be legal under R3RS's set!-like
semantics for top-level definitions.
Of course, you could patch things up by switching from letrec to letrec*.
My preference is to adopt the letrec-based version as official (making the
above example not standard scheme), with the letrec*-based version as an
incouraged extension for interactive implementations (note that letrec*
is a legal implementation of letrec, as remarked in R3RS).
There is also an issue of what to do with multiple definitions of the
same variable in the same scope, which R3RS doesn't address for
internal definitions and is a bigger issue for top-level interactions.
Again, it's probably best to make any use of this feature
non-standard, with some encouraged extension for interactive
top-levels.
------------------------------
Date: 3 May 89 21:23:51 GMT
From: POLYA.STANFORD.EDU!shap@bloom-beacon.mit.edu (Jonathan S. Shapiro)
Subject: Common Lisp on Scheme?
Message-Id: <8905032123.AA18408@polya.Stanford.EDU>
What with the Scheme implementation that is built on Common Lisp, it
occurs to me to ask if anyone has implemented a Common Lisp on Scheme?
Jon
------------------------------
End of Scheme Digest
********************
∂04-May-89 2140 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #113
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 4 May 89 21:39:58 PDT
Date: 5 MAY 89 00:01:00 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #113
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #113 5 MAY 89 00:01:00 EDT
Today's Topics:
semantics of DEFINE
top level definitions
Cscheme via ftp now?
Cscheme via ftp now?
----------------------------------------------------------------------
Date: 3 May 89 17:33:55 GMT
From: XEROX.COM!Pavel.pa@bloom-beacon.mit.edu
Subject: Re: semantics of DEFINE
Message-Id: <890503-103409-9762@Xerox>
Too many people are referring to DEFINE as a form that ``side-effects the
top-level environment'' for me to keep out of the fray. In the current
(unreleased) draft of the Scheme specification, R↑(3.95)RS, the following
definitions appear (my wording):
-- A program is a mixed sequence of definitions and expressions.
-- The meaning of a program P is the same that that of the following
expression:
((lambda (I*) P') <undefined> ...)
where I* is the set of variables defined in P (i.e., appearing as the CADR
of a DEFINE form), P' is the sequence of expressions obtained by replacing
each definition in P with the corresponding assignment, and <undefined> is
an expression producing some useless value.
More informally, to execute a program, you wrap it in a big LET binding all
of the defined variables to useless values, change the DEFINEs to SET!s,
and evaluate that expression.
Note, please: no mutation of any environment takes place.
I believe that too many people base their understanding of the semantics of
Scheme on a read-eval-print loop model or on the low-level details of
particular (or perhaps all) implementations. It seems to me irrelevant
that I might use side-effects to resolve the separate compilation (or just
separate loading) of files of code with the semantics given above. The
semantics of DEFINE, and therefore the most accurate way to conceptualize
its meaning, has no mention of mutation.
Of course, this little diatribe has no direct bearing on the meaning of
internal DEFINEs. Personally, I'd rather they had the same meaning (as
given above) as top-level ones. The meaning in terms of LETREC has always
struck me as gratuitously incompatible, and frequently inconvenient as
well. If you're going to use the same name, you should give it the same
semantics...
Pavel
------------------------------
Date: 3 May 89 21:21:55 GMT
From: unicads!les@boulder.colorado.edu (Les Milash)
Subject: Re: top level definitions
Message-Id: <417@unicads.UUCP>
In article <8912@polya.Stanford.EDU> mxh@sumex-aim.Stanford.EDU (Max Hailperin) writes:
>[Abelson and Sussman, p. 8], which would be legal under R3RS's set!-like
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ sorry to be so ignorant, but what is this?
I've seen R*S's but never a book on Scheme.
(After reading about Screme on the 88K in ASPLOS III I'm getting tempted to
write one for INMOS Transputers. Any huge interest in this out there?
Imagine the potential: "the embedded symbolic computer". For a microwave
that can tell you WHY weenies take 2 minutes, or a dashboard that can
debate the wisdom of using seatbelts AND WIN.
Can anybody point me at thoughts about Schemes on multiprocessors (i suspect
Scheme is a great language for multiprocessors but I don't really know the
details) or just an overview of Scheme (i suspect that it's "Lisp without
X or Y or Z" which gives you "Lisp with some additional magic powers").
My goal is to have a nice language for programming a single
processor, and running bunches of those, but perhaps there are some slick
things permitting parallel evaluation of subexpressions by multple
processors etc.)
any other tips for a rank beginner?
(be nice, i'm just a fresh convert from the C world, i just got
sick of having to do in my programs what Scheme does for me in
the language.)
------------------------------
Date: 4 May 89 10:32:26 GMT
From: otter!gjh@hplabs.hp.com (Graham Higgins)
Subject: Re: Cscheme via ftp now?
Message-Id: <6260001@otter.hpl.hp.com>
The question came ...
++ > Now that prep is gone, where can one ftp Cscheme from?
++ Try tut.cis.ohio-state.edu. (is there an echo in here?)
Thanks Chris Whatley --- could you also post the internet address,
tut.cis.ohio-state.edu doesn't appear in my hosts table.
Cheers,
Graham
======
------------------------------------------------------------------
Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060
Information Systems Centre | gray@hpl.hp.co.uk
Bristol | gray%hplb.uucp@ukc.ac.uk
U.K. | gray@hplb.hpl.hp.com
------------------------------
Date: 4 May 89 14:05:26 GMT
From: pacific.mps.ohio-state.edu!verber@ohio-state.arpa (Mark A. Verber)
Subject: Re: Cscheme via ftp now?
Message-Id: <189@pacific.mps.ohio-state.edu>
CScheme is on tut.cis.ohio-state.edu whose IP address is
128.146.8.60. I find is very strange that Tut isn't in someone's
host table since he is registered with the NIC and SOA for
ohio-state.edu. You should be running a name resolver.... or
at least a modern host table from SRI-NIC.
Mark A. Verber | There are two major products that
verber@mps.ohio-state.edu | come out of Berkeley: LSD and BSD
Physics, 174 W 18th, Cols, OH 43210 | UNIX. We don't believe this to
1-614-292-8002 | be a coincidence.
------------------------------
End of Scheme Digest
********************
∂07-May-89 2114 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #114
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 May 89 21:14:00 PDT
Date: 8 MAY 89 00:00:52 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #114
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #114 8 MAY 89 00:00:52 EDT
Today's Topics:
Please make internal DEFINE's more like top-level ones.
----------------------------------------------------------------------
Date: 5 May 89 11:41:58 GMT
From: philmtl!philabs!linus!ramsdell@uunet.uu.net (John D. Ramsdell)
Subject: Please make internal DEFINE's more like top-level ones.
Message-Id: <52382@linus.UUCP>
Pavel correctly gives the meaning of top-level definitions.
In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes:
Too many people are referring to DEFINE as a form that ``side-effects the
top-level environment'' for me to keep out of the fray. In the current
(unreleased) draft of the Scheme specification, R↑(3.95)RS, the following
definitions appear (my wording):
-- A program is a mixed sequence of definitions and expressions.
-- The meaning of a program P is the same that that of the following
expression:
((lambda (I*) P') <undefined> ...)
where I* is the set of variables defined in P (i.e., appearing as the CADR
of a DEFINE form), P' is the sequence of expressions obtained by replacing
each definition in P with the corresponding assignment, and <undefined> is
an expression producing some useless value.
Clearly, it is not a meaning preserving transformation to replace all
top-level DEFINE's by a LETREC form. At the top-level, the order in
which DEFINE's are given counts. People really write code like:
(define a 3)
(define b (* a a))
... code that uses b.
Internal DEFINE's are currently defined to be syntactic sugar for
LETREC. That is, the order in which internal DEFINE's are given does
not count. It is illegal to write the following code:
(let ()
(define a 3)
(define b (* a a))
... code that uses b).
My continuing question is why treat internal DEFINE's differently from
from top-level DEFINE's? Why not give internal DEFINE's same
semantics as given above? Those who want LETREC like semantics can
use LETREC.
John
------------------------------
End of Scheme Digest
********************
∂08-May-89 2129 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #115
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 8 May 89 21:28:54 PDT
Date: 9 MAY 89 00:00:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #115
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #115 9 MAY 89 00:00:57 EDT
Today's Topics:
semantics of DEFINE
scoops sources
semantics of DEFINE (why use it at all on the top level?)
semantics of DEFINE (why use it at all on the top level?)
----------------------------------------------------------------------
Date: 8 May 89 14:37:04 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: Re: semantics of DEFINE
Message-Id: <59840@yale-celray.yale.UUCP>
In article <890503-103409-9762@Xerox>, Pavel.pa@XEROX writes:
>Too many people are referring to DEFINE as a form that ``side-effects the
>top-level environment'' for me to keep out of the fray. In the current
>(unreleased) draft of the Scheme specification, R↑(3.95)RS, the following
>definitions appear (my wording):
>
>-- A program is a mixed sequence of definitions and expressions.
>
>-- The meaning of a program P is the same that that of the following
>expression:
> ((lambda (I*) P') <undefined> ...)
>where I* is the set of variables defined in P (i.e., appearing as the CADR
>of a DEFINE form), P' is the sequence of expressions obtained by replacing
>each definition in P with the corresponding assignment, and <undefined> is
>an expression producing some useless value.
>
>More informally, to execute a program, you wrap it in a big LET binding all
>of the defined variables to useless values, change the DEFINEs to SET!s,
>and evaluate that expression.
OK, the above makes sense for "top-level" DEFINE forms. Before recasting
my comments from before into the terminology used above, let me define two
catagories of DEFINE forms that are not handled under the above
specification:
(1) non-top-level static definitions: definitions that are made at
load/compile/etc time (ie, are static) but are not top-level.
An example of this is a DEFINE form inside a "top-level" LET
form.
(2) dynamic definitions: DEFINE forms that are executed during the
execution of another procedure. An example of this is a DEFINE
form in the body of another DEFINE form.
My claim is that both of these cases fits cleanly into the specification
given above (by Pavel). In each case the symbol being DEFINEd would be
bound in the global binding countour (shown above as a LAMBDA, essentially
a LET) and would be SET! at the point where they were to be DEFINEd. The
new specifications (using the terminology from above) would be:
A program is a sequence of expressions
The meaning of a program P is the same as that of the expression:
((lambda (I*) P') <undefined> ...)
where I* is the set of variables defined in P (ie, apearing as the
CADR of a DEFINE form anywhere in the tree coresponding to P), P'
is the sequence of expressions obtained by replacing all appearences
of the symbol DEFINE [perhaps only those where the variable DEFINE
isn't rebound] with teh symbol SET!, and <undefined> is an
expression producing some useless value.
The next question is why I think the specifications should be extended to
allow this. My answers are:
(1) It adds expressive power to the language.
(2) Other proposed specifications for non-top-level DEFINEs do
not add expressive power to the language.
(3) It is a direct and consistant extension of the semantics being
proposed (according to Pavel).
Bruce Krulwich
------------------------------
Date: 8 May 89 17:02:21 GMT
From: lambda!scp@lanl.gov (Stephen Pope)
Subject: Re: scoops sources
Message-Id: <SCP.89May8110221@raven.lanl.gov>
In article <8905012306.AA13055@BLOOM-BEACON.MIT.EDU> V4110DAA@AWIUNI11.BITNET (Gerhard Eckel) writes:
> is there anybody in the SCHEME community who could *mail* to me
>(unfortunately I don't have access on ftp) the source code of SCOOPS as it is
>running on PCScheme? I received the CSCHEME version of SCOOPS via this list
>recently but I use PCScheme and I don't want to convert it back.
>Unfortunately PCScheme comes without the source code.
I seem to have missed the distribution of the CSCHEME version of SCOOPS.
Could some kind soul mail me said package, or indicate ftp access?
Thanks,
Stephen C. Pope
Santa Fe Institute
scp@sfi.santafe.edu
------------------------------
Date: 8 May 89 10:21:47 GMT
From: mcvax!hp4nl!botter!star.cs.vu.nl!biep@uunet.uu.net (J A Biep Durieux)
Subject: Re: semantics of DEFINE (why use it at all on the top level?)
Message-Id: <2454@ski.cs.vu.nl>
In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes:
>-- A program is a mixed sequence of definitions and expressions.
>
>-- The meaning of a program P is the same as that of the following expression:
> ((lambda (I*) P') <undefined> ...)
>where I* is the set of variables defined in P (i.e., appearing as the CADR
>of a DEFINE form), P' is the sequence of expressions obtained by replacing
>each definition in P with the corresponding assignment, and <undefined> is
>an expression producing some useless value.
Then why not actually do this?
-- The scheme top-level environment has each variable bound to a unique
location. Many of these locations will be assigned the value #\undefined.
-- The user can assign other values to variable locations using "set!".
A "define" on top level will be an error, since the variable is
already bound on that level.
-- Allow the syntax "(set! (first cell) (car cell))" to mean the analogue
of the comparable "define" syntax
--
Biep. (biep@cs.vu.nl via mcvax)
Who am I to doubt the existence of God? I am
only a simple man, I already have trouble
enough doubting the existence of my neighbour!
------------------------------
Date: 9 May 89 00:41:32 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: Re: semantics of DEFINE (why use it at all on the top level?)
Message-Id: <59918@yale-celray.yale.UUCP>
In article <2454@ski.cs.vu.nl>, biep@cs (J A Biep Durieux) writes:
>In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes:
>
>>-- A program is a mixed sequence of definitions and expressions.
>>
>>--The meaning of a program P is the same as that of the expression:
>> ((lambda (I*) P') <undefined> ...)
...
>Then why not actually do this?
>
>-- The scheme top-level environment has each variable bound to a unique
> location. Many of these locations will be assigned the value
> #\undefined.
>
>-- The user can assign other values to variable locations using "set!".
> A "define" on top level will be an error, since the variable is
> already bound on that level.
First, the system has to know what symbols to bind in the global LET
contour. It would be consistant to have DEFINE always specify that a
symbol be included in this binding.
Secondly, having internal DEFINEs do local definitions is even more
redundant, since it is 100% translatable into a LETREC while DEFINE is
needed to specify what variables should be bound.
Bruce Krulwich
------------------------------
End of Scheme Digest
********************
∂09-May-89 2127 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #116
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 May 89 21:19:56 PDT
Date: 10 MAY 89 00:01:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #116
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #116 10 MAY 89 00:01:08 EDT
Today's Topics:
semantics of DEFINE (why use it at all on the top level?)
----------------------------------------------------------------------
Date: 9 May 89 01:51:12 GMT
From: Krulwich-Bruce@yale-zoo.arpa (Bruce Krulwich)
Subject: Re: semantics of DEFINE (why use it at all on the top level?)
Message-Id: <59923@yale-celray.yale.UUCP>
In article <59918@yale-celray.yale.UUCP>, I wrote:
>In article <2454@ski.cs.vu.nl>, biep@cs (J A Biep Durieux) writes:
>>In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM writes:
>>
>>>-- A program is a mixed sequence of definitions and expressions.
>>>
>>>--The meaning of a program P is the same as that of the expression:
>>> ((lambda (I*) P') <undefined> ...)
>...
>>Then why not actually do this?
>>
>>-- The scheme top-level environment has each variable bound to a unique
>> location. Many of these locations will be assigned the value
>> #\undefined.
>>
>>-- The user can assign other values to variable locations using "set!".
>> A "define" on top level will be an error, since the variable is
>> already bound on that level.
>
>First, the system has to know what symbols to bind in the global LET
>contour. It would be consistant to have DEFINE always specify that a
>symbol be included in this binding.
>
>Secondly, having internal DEFINEs do local definitions is even more
>redundant, since it is 100% translatable into a LETREC while DEFINE is
>needed to specify what variables should be bound.
Gee that last paragraph reads like gibberish. What I meant was:
Secondly, having internal DEFINEs do local definitions is even more
reduntant since this is 100% translatable into LETREC. On the other
hand, top-level DEFINEs are not 100% translatable since some specification
is needed of which variables should be in the top-level contour.
Bruce
------------------------------
End of Scheme Digest
********************
∂10-May-89 2137 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #117
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 May 89 21:37:43 PDT
Date: 11 MAY 89 00:01:29 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #117
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #117 11 MAY 89 00:01:29 EDT
Today's Topics:
SCOOPS and obsolete forms
SCOOPS and obsolete forms
SCOOPS and obsolete forms
----------------------------------------------------------------------
Date: 10 May 89 16:35:19 GMT
From: lambda!scp@lanl.gov (Stephen Pope)
Subject: SCOOPS and obsolete forms
Message-Id: <SCP.89May10103519@raven.lanl.gov>
Thanks to folks here in netland, I recently got a copy of SCOOPS
(for those still wondering where it can be found, try ftp to
linc.cis.upenn.edu (130.91.6.8). sherin@linc.cis.upenn.edu
seems to be the responsible party, though don't take this as *my*
endorsement to hound him with mail.
In any case, I found two problems in bringing scoops up under
MIT-CSCHEME:
Release 6.1.2
Microcode 10.2
Runtime 13.91
SF 3.13
First, the replacements of "syntax-table-define ..." with "add-syntax!"
et. al were unnecessary - I didn't touch my existing runtime band.
Second, SCOOPS made use of the REC special form. This was apparently
removed from the language as of R3RS. In any case, I got runtime
errors (Unbound variable NAME). It is always used in the form:
((rec name (lambda ...)) args ...)
where name needs to recursively call itself. I'm no SCHEME wizard,
but it seemed the proper equivalent was:
(let ((name (lambda ...))) (name args ...))
which appears to run just fine.
Can anybody enlighten me on the subject of REC and its demise?
Stephen Pope
Santa Fe Institute
scp@sfi.santafe.edu
------------------------------
Date: 10 May 89 19:48:35 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: SCOOPS and obsolete forms
Message-Id: <3247@kalliope.rice.edu>
In article <3246@kalliope.rice.edu> I write:
>Any REC-expression (not just in the application-context you mention
>and not just for LAMBDA-forms either) can be stated with a LETREC
>(which in its term is based on LAMBDA and SET!) as follows:
↑↑↑↑
It could be well-nigh impossible to figure out that the above is a
typo for "turn". Hence this posting. (For what it's worth, I was
thinking of term-rewriting something, and psychology did the rest.)
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
Date: 10 May 89 19:31:06 GMT
From: titan!dorai@rice.edu (Dorai Sitaram)
Subject: Re: SCOOPS and obsolete forms
Message-Id: <3246@kalliope.rice.edu>
In article <SCP.89May10103519@raven.lanl.gov> scp@raven.lanl.gov (Stephen Pope) writes:
>Second, SCOOPS made use of the REC special form. This was apparently
>removed from the language as of R3RS. In any case, I got runtime
>errors (Unbound variable NAME). It is always used in the form:
>
> ((rec name (lambda ...)) args ...)
>
>where name needs to recursively call itself. I'm no SCHEME wizard,
>but it seemed the proper equivalent was:
>
> (let ((name (lambda ...))) (name args ...))
>
>which appears to run just fine.
>
>Can anybody enlighten me on the subject of REC and its demise?
Your equivalent should have a LETREC rather than a LET.
Any REC-expression (not just in the application-context you mention
and not just for LAMBDA-forms either) can be stated with a LETREC
(which in its term is based on LAMBDA and SET!) as follows:
(rec name exp) == (letrec ([name exp]) name)
A possible reason for not mentioning REC as "essential syntax" in R3RS
could be that the corresponding LETREC-equivalent is quite as
readable. LETREC, of course, has more claim to the status of
"essential syntax" since, in contrast to REC, it can also introduce
several mutually recursive bindings.
It is probably stretching it a bit to think of REC's omission from
R3RS in such tragic terms as "demise". Any basic macro facility can
resurrect it for you.
--dorai
------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
------------------------------------------------------------------------------
------------------------------
End of Scheme Digest
********************
∂12-May-89 2121 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #118
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 May 89 21:21:12 PDT
Date: 13 MAY 89 00:01:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #118
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #118 13 MAY 89 00:01:59 EDT
Today's Topics:
Xscheme, object functions
----------------------------------------------------------------------
Date: 12 May 89 21:50:29 GMT
From: mccarrol@topaz.rutgers.edu (Mark C. Carroll <mccarrol@topaz.rutgers.edu>)
Subject: Xscheme, object functions
Message-Id: <May.12.17.50.20.1989.4278@topaz.rutgers.edu>
I've just obtained a copy of David Betz's Xscheme system. It claims
to be "An Object-oriented Scheme".
The documentation completely ignores the Object Oriented features
of the language. (They get less than one paragraph, describing
the syntax of a message pass.)
I've managed to hack out the method of describing a Class creation,
by referring to the documentation of Xlisp. What I've come
up with is:
] (define newclass (Class 'new '(instance vars) '(class vars)))
To define the class, and
] (newclass 'answer 'msgname '(args) '(method code))
to define methods. However, no amount of hacking seems to be
telling me how to access the instance variables, or the class
variables.
Defining a method:
] (newclass 'answer 'what '() '((environment-bindings)
] (the-environment)))
yields ((self . #<object....>)), where .... is the object number,
so the instance variables are not in the environment of the
method. Where are they? How can I access them?
If Mr. Betz is reading this, I have a question for him: Why, on
earth, did you design an object oriented variant of scheme, and
then totally neglect to tell anyone how to use the objects?
<MC>
--
=| Mark Craig Carroll: <MC> |=
=| mccarrol@topaz.rutgers.edu,...!rutgers!topaz!mccarrol |=
=| "Your only obligation in any lifetime is to be true to yourself" |=
=| -Richard Bach,_Illusions_ |=
------------------------------
End of Scheme Digest
********************
∂13-May-89 2115 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #119
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 May 89 21:15:41 PDT
Date: 14 MAY 89 00:02:04 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #119
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #119 14 MAY 89 00:02:04 EDT
Today's Topics:
PC Scheme
Whereis scheme now that prep.ai.mit.edu is gone?
Scheme Digest #118
----------------------------------------------------------------------
Date: 12 May 89 13:47:21 GMT
From: cs.dal.ca!aucs!880716a@uunet.uu.net (Dave Astels)
Subject: PC Scheme
Message-Id: <1871@aucs.UUCP>
Hello. I a budding AI programmer/researcher (Natural Language/Cognition).
I am currently using Xlisp for my work. I have used version 1.6 with success.
I recently got version 2.0 (which is much better) but it doesn't leave me
enough free memory to develope reasonable sized programs. I am using an IBM
PC clone with 640K. I am considering buying a LISP system. PC Scheme is in
my price range (I'm a student), and I am wondering if anyone has any advice
in this matter. I am not familiar with Scheme. How close to Common LISP is
it? Whould there be much problem porting from PC Scheme to Common LISP?
How does it work on a 640K PC (I am planning to get an EMS memory card in the
future). The emacs-like editor sounds nice, what is the developement
environment like? Any advice and opinions would be appriciated. Also, is
there any reasonable alternatives in the same price range?
Thanks in advance.
-Dave
------------------------------
Date: 13 May 89 05:44:21 GMT
From: cunixc!micky@columbia.edu (Micky Liu)
Subject: Whereis scheme now that prep.ai.mit.edu is gone?
Message-Id: <1504@cunixc.cc.columbia.edu>
The title says it all... I'm looking to bring scheme up on a Convex
C-210 and haven't been able to locate current sources... The last
that I looked it was on prep, but that was a loooong time ago...
Thanx,
Micky Liu
arpa: micky@cunixc.cc.columbia.edu
uucp: ...!rutgers!columbia!cunixc!micky
bitnet: malua@cuvmc
------------------------------
From: <monyet@ATHENA.MIT.EDU>
Message-Id: <8905140029.AA04228@M11-111-2.MIT.EDU>
Subject: Re: Scheme Digest #118
Date: Sat, 13 May 89 20:29:11 EDT
Please unsubscribe me from the mailing list of scheme digest.
Thank you.
--- Hanson(monyet@athena.mit.edu)
------------------------------
End of Scheme Digest
********************
∂14-May-89 2132 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #120
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 May 89 21:32:19 PDT
Date: 15 MAY 89 00:02:12 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #120
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #120 15 MAY 89 00:02:12 EDT
Today's Topics:
What's your favorite macro?
----------------------------------------------------------------------
Subject: What's your favorite macro?
Reply-to: bcp@cs.cmu.edu
Date: Sun, 14 May 89 20:59:24 EDT
Message-ID: <27218.611197164@PROOF.ERGO.CS.CMU.EDU>
From: Benjamin.Pierce@PROOF.ERGO.CS.CMU.EDU
I'm interested in examples or applications that clearly demonstrate
the utility of macros as a language extension mechanism.
In particular, I'd like to know about useful macros with the following
properties:
1) They make "significant" use of the macro definition mechanism (this
is to rule out kinds of notational extensions that could be handled
just as well by a simpler mechanism).
2) They cannot be implemented as functions (this rules out uses of
macros to improve efficiency of programs without increasing the
expressive power of the language).
3) They provide features or constructs that would NOT be a desirable
addition to the base language (this rules out macros that "should"
be language features rather than macros, e.g. delayed evaluation,
polymorphic types, records, exceptions, ... [I know some of these
are debatable!]).
Pointers to previous discussions or research papers also gratefully
accepted.
Benli
------------------------------
End of Scheme Digest
********************
∂15-May-89 2120 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #121
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 May 89 21:20:28 PDT
Date: 16 MAY 89 00:02:22 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #121
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #121 16 MAY 89 00:02:22 EDT
Today's Topics:
scoops & xscheme
----------------------------------------------------------------------
Date: Tue, 16 May 89 01:36:12 MEZ
From: Gerhard Eckel <V4110DAA%AWIUNI11.BITNET@mitvma.mit.edu>
Subject: scoops & xscheme
Hello,
I've posted a request for scoops sources to this list recently. I read a
redistribution of this list from a machine in Finland which apparently missed
the digests 108 - 113 and 115. Since I can't find them in the archives there
I don't know if anyone answered my query and so I need to repeat my question.
If there are no news about scoops maybe somebody could send the digests I
missed anyway.
Something else: since some weeks I use XScheme and I had similar problems
as Marc Craig Carroll (Digest #118), and others:
XScheme - Version 0.16
> (define env (let ((var1 1)) (the-environment)))
env
> (environment-bindings env)
((var1 . 1))
> (eval '(define var2 2) env)
var2
> (environment-bindings env)
((var1 . 1))
> var2
2
> (environment-bindings (the-environment))
()
When I look how environments are implemented I can understand this
behaviour but is this still Scheme? Nevertheless I find XScheme an
interesting implementation which is particulary useful for me because I can
easily entend it (I use it for controlling a DSP to do sound processing). I
would like to get in touch with other people using XScheme so that we can
exchange bug fixes (I fixed some weird ones already) and communicate about
and coordinate further development. I tried to reach David Betz but didn't
succeed yet (is this still the address where to reach him:
'zinn!mispmag!dbetz@decvax.dec.com' ? - if you are listening David, please
contact me!!!) I am ready to organize (moderate) something like a XScheme
users group - who is interested and could give me some hints how to do it?
Regards, Gerhard
+------------------------------+---------------------------------------------+
: Gerhard ECKEL c/o Austrian Academy of Sciences, Dept. Sound :
: Hernalser Haupstrasse 164/17 : Liebiggasse 5, A-1010 Vienna, AUSTRIA :
: A-1170 Vienna, AUSTRIA : Tel.: +43 222 43 00 27 30 :
: Tel.: +43 222 46 10 404 : E-mail: V4110DAA@AWIUNI11.BITNET :
+------------------------------+---------------------------------------------+
P.S.: for scoops, remember: I've no access to ftp ...
------------------------------
End of Scheme Digest
********************
∂16-May-89 2122 Scheme-REQUEST@MC.LCS.MIT.EDU Scheme Digest #122
Received: from MC.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 May 89 21:22:49 PDT
Date: 17 MAY 89 00:02:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #122
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Scheme Digest #122 17 MAY 89 00:02:37 EDT
Today's Topics:
Location of Scheme -- Again...
----------------------------------------------------------------------
Date: 16 May 89 07:31:27 GMT
From: cunixc!micky@columbia.edu (Micky Liu)
Subject: Location of Scheme -- Again...
Message-Id: <1515@cunixc.cc.columbia.edu>
I wish to thank all of you who replied to my initial query and I'd
like to clarify some of the information that has been sent to me...
Okay, prep.ai.mit.edu isn't gone, but it certainly was not replaced
completely. The scheme distribution id is no longer functioning (it
wasn't such a good idea really anyway...) and there is no trace of
scheme anywhere in the public directories.
I was also pointed to wheaties.ai.mit.edu, and I don't see the dist
there, but some scheme code for labs for a class perhaps?
The one place that I did find it was at zurich.ai.mit.edu, but have so
far been unsuccessful at retrieving it. The poor little HP9000
doesn't really like to have it's ftpd work that hard...
Any other sites that I can try at 3:30AM?
Thanx!
Micky Liu
arpa: micky@cunixc.cc.columbia.edu
uucp: ...!rutgers!columbia!cunixc!micky
bitnet: malua@cuvmc
------------------------------
End of Scheme Digest
********************